Design Justification File (DJF) — Design Justification

Design Justification File (DJF) — Design Justification#

Field	Value
Document	DJF — Design Justification (design rationale, trade-offs, make-or-buy and feasibility record)
DRD ref	ECSS-E-ST-40C Rev.1 §4.2.4 / §4.2.5 (DJF concept); ECSS-M-ST-10-01C (review/justification concept); design-level summary of Annex F <6>
Container	Design Justification File (DJF) — `compliance/drd/`
Project	`msi-processor` (gitlab.eopf.copernicus.eu/ipf/msi-processor)
Software criticality	Category C (ECSS-Q-ST-80C Rev.2 / ECSS-E-ST-40C Annex R)
Baselined at	CDR
Status	Draft for CDR

What this document is. Per ECSS-E-ST-40C Rev.1 §4.2.4/§4.2.5 the Design Justification File (DJF) records “the result of all significant trade-offs, feasibility analyses, make-or-buy decisions and supporting technical assessments” and “the rationale for important design choices, and analysis and test data that show that the design meets all requirements.” The DJF is a file (a container), not a single DRD; its constituents — SRevP (Annex P), SVerP/SValP/SUITP (Annexes I/J/K), SVR (Annex M), SRF (Annex N) and the V&V evidence — are separate documents (RD-2..RD-7). This document is the head of the DJF: it consolidates the design justification proper (the key design decisions, their alternatives, trade-offs, make-or-buy and feasibility rationale) and points to the constituents that carry the verification/test data. It is the companion to, and does not duplicate, the SDD (RD-1), which states what the design is; this DJF states why. Every decision traces to its driving REQ-* (SRS, RD-8), risk (R-*, Risk Register RD-5) and design element (C-*, SDD RD-1). Tailored Category C / single-developer: the footprint is the decision record, not a multi-volume trade study.

<1> Introduction#

Purpose. This document gives the engineering justification for the baselined design of msi-processor, a generic high-resolution pushbroom multispectral imager (MSI) ground-segment processor transforming downlinked RAW Level-0 (L0c) into calibrated, orthorectified, atmospherically corrected products up to Level-2 (L2A), built on the EOPF CPM (eopf == 2.8.1). It captures the significant design decisions, the alternatives considered, and the trade-offs, make-or-buy and feasibility analyses that led to the architecture and detailed design recorded in the SDD (RD-1).

Objective. To make the design auditable: a reviewer (CDR) can see, for each load-bearing choice, the driving requirement/risk, the options weighed, why the chosen option was selected, and the cost accepted — and can confirm that the design as a whole is shown to meet the requirements (clause <8>) and that Category C levies no special criticality measures beyond those provided (clause <9>).

Content. Clause <2> lists applicable/reference documents; <3> adds decision-specific terms; <4> states the justification approach and the decision-record format. Clause <5> is the core: the key design decisions and trade-offs (DEC-*). Clause <6> is the make-or-buy / reuse decision summary; <7> the feasibility analyses and supporting technical assessments; <8> the demonstration that the design meets the requirements; <9> the critical-software-component measures justification (closing SDD <6.3>); <10> the design decisions deferred to implementation ([impl] open points) and their resolution criteria; <11> the DJF constituents and references.

Reason for preparation. msi-processor is an integration and ECSS-productisation effort: the processing algorithms exist as prior work (RD-9) and the runtime is the EOPF CPM. The design therefore turns on a small number of high-leverage integration decisions (platform, version pin, sensor-agnosticism, core/wrapper split, reuse-vs-new). The DJF exists to record those decisions and their rationale at CDR, before implementation (SDP WP-5) is authorised, so that the design freeze is defensible.

<2> Applicable and reference documents#

Applicable documents (AD)#

Id	Document	Reference
AD-1	ECSS Space engineering — Software	ECSS-E-ST-40C Rev.1 (30 April 2025)
AD-2	ECSS Space product assurance — Software product assurance	ECSS-Q-ST-80C Rev.2 (30 April 2025)
AD-3	ECSS Space project management — Organization and conduct of reviews	ECSS-M-ST-10-01C
AD-4	EOPF CPM — common data model / processing-unit framework	EOPF CPM docs (`eopf == 2.8.1`)

Reference documents (RD)#

Id	Document	Reference
RD-1	`msi-processor` Software Design Document (SDD, detailed/CDR) — `C-*`	`compliance/drd/sdd-software-design.md`
RD-2	`msi-processor` Software Review Plan (SRevP) — DJF constituent	`compliance/drd/srevp-software-review-plan.md`
RD-3	`msi-processor` V&V plan (SVerP + SValP + SUITP merged) — DJF constituent	`compliance/drd/vv-plan.md`
RD-4	`msi-processor` Software Verification Report (SVR) — DJF constituent (QR)	`compliance/drd/vv-report.md`
RD-5	`msi-processor` Risk Register — `R-*`	`compliance/drd/risk-register.md`
RD-6	`msi-processor` Software Reuse File (SRF) — DJF constituent	`compliance/drd/srf-software-reuse-file.md`
RD-7	`msi-processor` Traceability matrix (forward/backward, design→test)	`compliance/traceability/traceability-matrix.md`
RD-8	`msi-processor` Software Requirements Specification (SRS) — `REQ-*`	`compliance/drd/srs-software-requirements.md`
RD-9	Prior work — multispectral pushbroom preprocessing pipeline (`level_0`, `level_1`, `band_coreg`, `georeferencing_v1`, `pansharp`, `metrics_ips`)	via RD-6
RD-10	`msi-processor` Detailed Processing Model (DPM) — `DPM-*`	`compliance/drd/dpm-data-processing-model.md`
RD-11	`msi-processor` Algorithm Theoretical Basis Document (ATBD) — `ALG-*`	`compliance/drd/atbd-algorithm-theoretical-basis.md`
RD-12	`msi-processor` Software Development Plan (SDP)	`compliance/software-development-plan.md`
RD-13	`msi-processor` SSS / IRD / ICD — `SYS-`, `REQ-IF-`, `ICD-IF-*`	`compliance/drd/{sss-…,ird-…,icd-…}.md`

<3> Terms, definitions and abbreviated terms#

The SDP <3>, SRS <3>, SDD <3> and Risk Register glossaries apply in full. Only decision-record-specific terms are added here.

Term / abbr.	Definition
DDF / DJF	Design Definition File (the what — SDD + code) / Design Justification File (the why — this record + V&V evidence), ECSS-E-ST-40C §4.2
`DEC-nn`	A recorded design decision in clause <5>, with options, trade-off, decision and rationale
Make-or-buy	The reuse vs new-development decision for a component (ECSS-E-ST-40C §4.2.4; “buy” = reuse/COTS/heritage)
Trade-off	Comparison of design options against the driving requirements/risks, yielding the selected option
`[impl]`	A design decision whose body is legitimately finalised during implementation (post-CDR); its interface and selection criteria are fixed at CDR (see <10>)
Driver	The `REQ-` and/or `R-` that motivates and constrains a decision

<4> Design justification approach#

<4.1> What the DJF records and where#

Per ECSS-E-ST-40C §4.2.4/§4.2.5 the DJF accumulates two kinds of content across the life cycle:

Decision rationale (trade-offs, feasibility, make-or-buy, supporting assessments) — produced in the requirements/architecture (PDR) and design/implementation (CDR) processes. This document is its consolidation (clauses <5>–<7>, <9>, <10>).
Analysis and test data showing the design meets the requirements — produced by verification and validation. These live in the DJF constituents (RD-2..RD-4, RD-6): the SRevP (review approach), the merged V&V plan (verification/validation/unit-integration test design), the SVR (verification results, QR) and the SRF (reuse analysis). Clause <8> binds the design to those constituents; clause <11> maps the file.

At CDR the “design-meets-requirements” evidence is the requirements→design→test traceability (SDD <6>, RD-7) plus the test design (SUITP in RD-3); the executed test results (SVR, RD-4) are added to the DJF at QR/AR. This document is therefore complete for CDR and is updated as evidence accrues.

<4.2> Decision-record format#

Each decision in <5> is recorded as:

DEC-nn — title.
Context / drivers — the problem and the driving REQ-* / risk R-*.
Options — a trade table Option | Pros | Cons, with the selected option marked (chosen).
Decision & rationale — the selected option and why it wins against the drivers.
Consequences / cost accepted — the disadvantage knowingly taken on, and any mitigation.
Trace — design element(s) C-* (SDD), and the requirements/risks satisfied or bounded.

<4.3> Traceability of decisions#

Every DEC-* references upstream REQ-* (RD-8) and, where the decision treats a risk, the risk R-* (RD-5); and downstream the design element C-* and the SDD clause that realises it (RD-1, principally SDD <4.7> trade-offs, <5.3> development types and <6.3> critical-component measures). The decision-to-risk cross-reference is summarised in <5.15>. No decision is recorded without at least one driver; no Category C “special measure” is claimed beyond those in <9>.

<5> Key design decisions and trade-offs#

The decisions below are ordered from the most architecture-defining (platform, version, sensor-agnosticism, core/wrapper) to the supporting choices. They expand and justify the trade-offs summarised in SDD <4.7>7.

<5.1> DEC-01 — Build on the EOPF CPM vs a standalone framework (make-or-buy)#

Context / drivers. The processor must produce EO-standard, interoperable, cloud-native products and integrate into the EO ground segment. Drivers: REQ-D-01 (CPM PU architecture), REQ-D-06 (reuse only sanctioned components; product I/O only through CPM abstractions), REQ-D-09 (open Zarr/CF/STAC output), REQ-I-05/06 (triggering, URI I/O), REQ-F-PRD-01 (EOProduct/Zarr). Risk: R-05 (CPM API stability), R-10 (product-format conformance).

Option	Pros	Cons
EOPF CPM (`EOProcessingUnit`/`EOProduct`/`EOZarrStore`) (chosen)	EO-native product model, Zarr/store abstraction and triggering for free; interoperable by construction; aligns with the EOPF SDE/CI; no framework to maintain	Couples the runtime to an external, evolving framework (R-05) and to a pinned version (DEC-02)
Standalone bespoke framework	Full control of the runtime/format; no external coupling	Re-implements product model, I/O, store mapping, triggering, provenance — large new development against REQ-D-06/-09; loses interoperability and EOPF alignment; higher long-term maintenance
Generic workflow engine (e.g. Airflow/Snakemake) + custom product model	Mature orchestration	Still needs a bespoke EO product/format layer; not EO-native; off-pattern for the EOPF ground segment

Decision & rationale. Adopt the EOPF CPM. It directly satisfies REQ-D-01/-06/-09 and REQ-F-PRD-01, gives interoperability and the store/triggering machinery as reuse, and is the sanctioned platform of the host ground segment. A bespoke framework would be a large new development squarely against the project’s “reuse over reinvention” objective (SDP <4.1>3) and Category C footprint.

Consequences / cost accepted. External coupling to the CPM and its version (R-05, treated by DEC-02 and DEC-04). Mitigation: the coupling is confined to the thin Wrappers and the C-COM-* services; the Cores are CPM-free (DEC-04), so a framework change re-touches only the adapters.

Trace. Whole architecture; C-COMPUTING, C-COM-PRODUCT, C-COM-IO, C-COM-ORC. REQ-D-01/-06/-09, REQ-F-PRD-01, REQ-I-05/06; R-05, R-10.

<5.2> DEC-02 — Pin `eopf == 2.8.1` vs track 3.x / the `latest` template#

Context / drivers. The CPM must be at a fixed, reproducible version. Drivers: REQ-R-03 (run on Python 3.11 + eopf == 2.8.1), REQ-REL-01/F-DEP-02 (reproducibility), REQ-M-03 (governed version-bump procedure). Risk: R-01 (pin vs SDE build-image latest drift), R-05 (API stability).

Option	Pros	Cons
Pin `eopf == 2.8.1` (chosen)	Deterministic, reproducible builds; one fixed API surface to design and test against; matches the SDE `cpm-build-environment` at design time; bump is a controlled, V&V-gated change (REQ-M-03)	Can desynchronise from an SDE image tagged `latest` (R-01); deliberately forgoes newer 3.x features until a planned bump
Track CPM 3.x / newest template	Latest features and fixes; closer to upstream direction	Moving target during a documentation-first design; API churn (R-05) would repeatedly invalidate the SDD before code exists; not reproducible
Float to image `latest` (no pin)	Always matches the build image	Non-reproducible builds; silent breakage; incompatible with REQ-REL-01/REQ-R-03

Decision & rationale. Pin to 2.8.1. A documentation-first life cycle (SDP <5.1>) baselines the SDD, ICD and computing-model JSON against a fixed CPM API; a moving target (3.x/latest) would churn the design and defeat reproducibility (REQ-REL-01, REQ-R-03). The pin is the single most volatile dependency, so it is isolated (DEC-04) and its change is governed (REQ-M-03).

Consequences / cost accepted. Possible drift from an SDE image tagged latest (R-01) and deferral of 3.x features. Mitigation (R-01): pin to image digest where the SDE allows; CI smoke test against the pinned env; monitor SDE release notes; any forced bump handled as an MR + re-baseline per REQ-M-03.

Trace. Platform-wide; C-COM-PRODUCT/IO/ORC, all Wrappers. REQ-R-03, REQ-REL-01, REQ-F-DEP-02, REQ-M-03; R-01, R-05.

<5.3> DEC-03 — Generic sensor-profile architecture vs an S2-specific (single-sensor) build#

Context / drivers. The processor is required to be sensor-agnostic, specialised by configuration, with the owner’s sensor as the first profile. Drivers: REQ-AD-01 (sensor-agnostic, profile-parametrised), REQ-AD-02 (identified/versioned profile, per-run selectable), REQ-D-04 (no hard-coded instrument constants in the core), REQ-D-07 (a new sensor = a new profile, no core change), REQ-S-01/05 (public code / private calibration never embedded). Risk: R-04 (calibration availability), R-08 (single-developer reuse leverage).

Option	Pros	Cons
Generic chain + externalised per-sensor profile + ADFs (chosen)	One code base across sensors (REQ-D-07); no instrument constants in code (REQ-D-04, REQ-S-05); calibration stays private, swappable by ADF (REQ-M-02); maximises reuse leverage for a single developer (R-08)	Up-front cost of a versioned profile schema + validation (C-COM-PROFILE, C-SENSORS); a layer of indirection
S2-specific build (hard-coded sensor)	Simplest first delivery; no schema layer	Violates REQ-AD-01/-04 and REQ-D-04/-07; bakes private calibration into code (against REQ-S-05); a second sensor is a fork
Per-sensor code forks (branch per sensor)	Sensor code can diverge freely	N copies to maintain; divergence and drift; antithetical to single-developer maintainability (R-08) and to REQ-D-07

Decision & rationale. Adopt the generic profile architecture. It is a hard requirement set (REQ-AD-01..04, REQ-D-04/-07) and the only option that keeps private calibration out of public code (REQ-S-01/05) by holding it in profile-referenced ADFs. For a single developer it also maximises reuse: each new sensor is data, not code (R-08). The owner’s sensor is simply the first instantiated profile (REQ-AD-02), proving the mechanism.

Consequences / cost accepted. A schema + validation layer (C-COM-PROFILE) and ADF-binding discipline (C-COM-ADF, C-SENSORS). Accepted as a one-time investment that pays back at the second profile; validated at CDR/QR by a second (synthetic) profile run (REQ-D-07 verification, SRS <7>).

Trace. C-SENSORS, C-COM-PROFILE, C-COM-ADF, C-COM-CONFIG. REQ-AD-01..04, REQ-D-04/-07, REQ-S-01/05, REQ-M-02; R-04, R-08.

<5.4> DEC-04 — Pure-core + thin-PU (wrapper) pattern vs algorithm-in-PU#

Context / drivers. Algorithm code must be testable, portable and isolated from the framework. Drivers: REQ-D-03 (pure, unit-testable core + thin PU wrapper), REQ-D-04 (minimise critical components; bounded complexity), REQ-M-04 (per-stage modularity), REQ-PORT-03 (run on a local/CI shell path without the full runtime). Risk: R-05 (CPM API stability — isolate the blast radius).

Option	Pros	Cons
Pure Core (no CPM) + thin `EOProcessingUnit` Wrapper (chosen)	Cores unit-testable and numerically verifiable without the CPM runtime (REQ-D-03, REQ-PORT-03); CPM coupling confined to the thin adapter, so an API/version change re-touches only wrappers (R-05, REQ-M-04); bounded complexity in CPM-facing code (REQ-D-04)	A small adapter per stage and a stable Core↔Wrapper contract (IF-CORE-01) to maintain
Algorithm directly inside the `EOProcessingUnit`	No adapter layer; fewer files	Numerics entangled with the CPM — cannot unit-test off-platform; every CPM change reaches the algorithm (R-05); larger critical surface (against REQ-D-04)

Decision & rationale. Adopt pure-core + thin-wrapper. It is the design pattern mandated by REQ-D-03 and the SDP design method (<5.3>), and it is the structural mitigation for the two biggest integration risks: CPM coupling (R-05) is fenced into the wrapper, and the numerics become independently verifiable (REQ-D-03), which is essential given private-data-only verification (R-03, DEC-13). It also minimises the critical-component surface (REQ-D-04, clause <9>).

Consequences / cost accepted. One adapter per stage and the BandStack/IF-CORE-01 contract. Accepted; the wrapper is templated (SDD <5.4.1>) so the per-stage cost is small.

Trace. Every C-PU-* (core+unit); IF-CORE-01. REQ-D-03/-04, REQ-M-04, REQ-PORT-03; R-05, R-03.

<5.5> DEC-05 — Reuse the prior-work algorithms vs rewrite from scratch (make-or-buy)#

Context / drivers. The L0→L1 algorithm mathematics already exists as prior work (RD-9). Drivers: SDP <4.1>3 (reuse over reinvention), REQ-D-06 (reused-software constraints), the Category C / single-developer footprint. Risk: R-08 (bus factor / leverage). Governed by the SRF (RD-6, Annex N).

Option	Pros	Cons
Reuse-adapt heritage Cores (RD-9) behind IF-CORE-01 (chosen)	Largest schedule/effort saving; algorithms already exercised; matches “integration not research” framing; SRF-governed (RD-6)	Heritage code must be refactored to the pure-Core contract and brought to ECSS/CI quality (typing, complexity, tests)
Rewrite all stages from scratch	Clean-room code to the new conventions	Discards proven algorithm work; large effort for a single developer (R-08); no correctness benefit at Category C
Adopt a third-party L0→L1 toolkit wholesale	Off-the-shelf	No sensor-agnostic, profile-driven, NDA-respecting fit; would still need heavy adaptation; weaker control of the numerics

Decision & rationale. Reuse-adapt the heritage Cores. The project is explicitly an integration/ productisation of existing algorithms (SDP <1>); reuse is the dominant lever for a single developer (R-08) and is consistent with REQ-D-06. The adaptation cost (pure-Core refactor + ECSS quality) is exactly the productisation work the project exists to do. Each reused stage is declared in the SRF with its development type (reuse-adapt, SDD <5.3>).

Consequences / cost accepted. Heritage code is refactored to IF-CORE-01 and raised to the CI quality gates (SDP <5.4>). Accepted; tracked per stage in the SRF (RD-6).

Trace. C-PU-L0/RAD/ENH/TOA/COR/GEO/PAN/QA (reuse-adapt, RD-9). REQ-D-06, SDP <4.1>3; R-08; SRF RD-6.

<5.6> DEC-06 — Atmospheric L2 as new development vs reuse (make-or-buy) + RT-engine basis#

Context / drivers. Unlike L0→L1, L2 atmospheric correction has no prior heritage. Drivers: REQ-F-ATM-01..04 (AOT/WV retrieval, TOA→BOA, scene classification + masks), REQ-P (BOA accuracy budget). Risk: R-06 (new L2 development — top technical/schedule risk). Basis: DPM-M-ATM (RD-10), ALG-ATM-* (RD-11).

Option	Pros	Cons
New development on an established RT model / LUT (e.g. 6S / libRadtran), interface-first (chosen)	Builds on a proven radiative-transfer basis rather than a novel algorithm (R-06); designed against DPM/ATBD so the rest of the chain is unaffected; explicit L2 acceptance criteria and schedule margin	Genuinely new code and verification; the only non-reused Core; RT engine + scene classifier still to be down-selected ([impl])
Reuse a heritage L2 module	Would save effort	None exists in RD-9 — not available
Wholesale third-party L2 processor (e.g. Sen2Cor-class)	Mature for one sensor	Sensor-specific, not profile-driven/sensor-agnostic; heavy to retrofit; weak fit to the generic chain (DEC-03)
Skip/defer L2 (stop at L1C)	Removes the top risk	Fails the L0→L2 scope (SSS/SRS); not acceptable

Decision & rationale. Develop L2 as new code, but on an established RT/LUT basis rather than a novel algorithm, and interface-first against DPM-M-ATM/ALG-ATM-* so the L0→L1C chain is decoupled from L2 maturity. This is the explicit mitigation of R-06: reduce algorithmic novelty, isolate the blast radius, schedule L2 last with margin, and pin L2 acceptance criteria in the SValP (RD-3).

Consequences / cost accepted. New Core + verification, and an open down-select of the RT engine and scene classifier (deferred decision, <10> DEC-D1). Accepted and risk-tracked (R-06); the C-PU-ATM interface is fixed at CDR so the chain proceeds regardless of the engine choice.

Trace. C-PU-ATM (new); DPM-M-ATM, ALG-ATM-*. REQ-F-ATM-01..04, REQ-P (BOA); R-06.

<5.7> DEC-07 — One PU per stage with optional stages toggleable vs fused mega-stages#

Context / drivers. The chain must support level breakpoints, re-runnable sub-chains and independent verification, with one stage (pan-sharpen) optional and per-stage sub-steps profile-configurable. Drivers: REQ-F-ORC-01 (run a level / sub-chain / full chain), REQ-REL-02 (re-run at breakpoint granularity), REQ-M-04 (modularity), REQ-F-ENH-03 (enhancement stage always runs; denoise method profile-selectable), DPM-BKP-* (level breakpoints).

Option	Pros	Cons
One PU per processing stage, optional stage toggleable (chosen)	Level breakpoints `L1A/B/C/L2A`; independent per-stage verification and re-run; the one optional stage (pan-sharpen) is default-off while the mandatory enhancement stage always runs with its denoise method profile-selectable (REQ-F-ENH-03); clean requirement allocation	More inter-PU `EOProduct` hand-offs
Fused mega-stages (e.g. one L0→L1C unit)	Fewer hand-offs; less I/O	No intermediate breakpoints; can’t verify or re-run a single correction; poor allocation/traceability; the optional stage can’t be cleanly toggled and per-stage sub-steps can’t be cleanly configured

Decision & rationale. One PU per stage. Granularity is what makes the chain verifiable, re-runnable (REQ-REL-02, REQ-F-ORC-01) and cleanly traceable (one stage → one DPM module → its REQ-F-*); it is the only clean way to keep the optional pan-sharpen stage default-off until validated, and to let a mandatory stage’s sub-steps be profile-selectable (e.g. the enhancement stage always runs MTF compensation / PSF deconvolution while its denoise method is profile-selectable, REQ-F-ENH-03).

Consequences / cost accepted. More inter-PU hand-offs; mitigated by lazy Zarr I/O (DEC-09) so hand-offs are cheap. Accepted.

Trace. C-COMPUTING (nine stages), C-COM-ORC. REQ-F-ORC-01, REQ-REL-02, REQ-M-04, REQ-F-ENH-03; DPM-BKP-*.

<5.8> DEC-08 — Chunked, optionally Dask-distributed execution vs whole-product in memory#

Context / drivers. Memory must be bounded independently of product size, with optional horizontal scaling, but must also run on a plain CI/local host. Drivers: REQ-F-ORC-02 (block processing + optional Dask), REQ-P-04/05 (throughput / bounded memory), REQ-R-04 (scale out), REQ-PORT-03 (sequential single process for CI/local). Risk: R-02 (shell runner has no Dask gateway).

Option	Pros	Cons
Block/tile (+halo) Cores, sequential or Dask, identical Cores (chosen)	Peak memory set by block size, not product size (REQ-P-05); horizontal scaling when Dask present (REQ-R-04); same Cores run sequentially on the shell runner/local (REQ-PORT-03, R-02)	Tiling + halo handling in spatially-coupled stages (georeference, coregistration, enhancement)
Whole-product in memory	Simplest Cores; no tiling	Memory scales with product size — fails REQ-P-05/REQ-R-04 on large scenes; no scale-out
Dask-only (mandatory)	Uniform distributed model	Cannot run on the CI shell runner (no Dask gateway, R-02); breaks REQ-PORT-03

Decision & rationale. Block-based Cores with a dual sequential/Dask strategy sharing identical Cores. Only the block mapping (C-COM-CHUNK) differs between modes, so memory is bounded (REQ-P-05) and the same code runs on the constrained CI shell runner sequentially (REQ-PORT-03, R-02) and scales out on Dask where available (REQ-R-04).

Consequences / cost accepted. Tiling/halo logic in the spatial PUs (the design’s hot-spots, georeference/atmospheric per SDD <4.6>). Accepted; these are the priority chunking/Dask validation targets.

Trace. C-COM-CHUNK, spatial C-PU-*. REQ-F-ORC-02, REQ-P-04/05, REQ-R-04, REQ-PORT-03; R-02.

<5.9> DEC-09 — `EOProduct`/Zarr-exclusive open I/O vs custom or legacy formats#

Context / drivers. Outputs must be cloud-native, open and CPM-native; I/O only through CPM abstractions. Drivers: REQ-D-09 (Zarr + CF/STAC/GeoZarr metadata), REQ-D-06 (I/O only via CPM), REQ-F-PRD-01 (EOProduct/Zarr), REQ-I-06/PORT-02 (URI/store transparency). Risk: R-10 (format conformance), R-01/R-05 (coupling to pinned CPM).

Option	Pros	Cons
`EOProduct` + Zarr (CF/STAC/GeoZarr) via `EOZarrStore` only (chosen)	Cloud-native, chunk-aligned with DEC-08, open and vendor-independent (REQ-D-09); CPM-native (REQ-D-06); URI/store transparency local/POSIX/S3 (REQ-PORT-02)	Bound to the pinned CPM I/O API (R-01/R-05)
GeoTIFF / NetCDF outputs	Familiar, widely supported tooling	Not chunk/cloud-native at scale; off the EOPF product model (REQ-D-06/-09); extra conversion layer
Custom binary format	Full control	Not open/interoperable; reinvents the product model; against REQ-D-06/-09

Decision & rationale. Zarr EOProduct exclusively, through EOZarrStore. It satisfies REQ-D-06/-09 and REQ-F-PRD-01 directly, is the natural persistence for the block model (DEC-08), and is open and readable independently of this software (long-lifetime, SDD <4.5>).

Consequences / cost accepted. I/O bound to the pinned CPM (R-01/R-05; mitigated by DEC-02/-04). Output conformance checked in CI against the EOProduct schema (R-10 mitigation).

Trace. C-COM-PRODUCT, C-COM-IO. REQ-D-06/-09, REQ-F-PRD-01, REQ-I-06, REQ-PORT-02; R-10, R-01, R-05.

<5.10> DEC-10 — Fail-stop recovery vs in-run retry / redundancy#

Context / drivers. Define the recovery policy for a ground, reprocessable, Category C processor. Drivers: REQ-F-DEP-01 (fail-stop, no partial/misleading product), REQ-REL-02 (re-runnable at breakpoints), REQ-SAF-01 (residual hazard = product-data integrity). CPM triggering__error_policy: FAIL_FAST.

Option	Pros	Cons
Fail-stop: typed error at PU boundary → non-zero exit, no partial product; re-run at breakpoint (chosen)	No partial/misleading product is ever published (REQ-F-DEP-01, REQ-SAF-01); simple, deterministic, auditable; matches a reprocessable ground context	A transient failure aborts the run (re-run required) — acceptable for batch ground processing
In-run retry / fallback	Could ride through transient faults	Hides faults; risks publishing degraded data as nominal; complexity unjustified at Category C
Redundancy / N-version	Fault tolerance	Not warranted at Category C (clause <9>); large cost; no safety/mission driver

Decision & rationale. Fail-stop. For a reprocessable ground processor whose residual hazard is product-data integrity (REQ-SAF-01), the correct failure mode is to stop and publish nothing, not to mask the fault. The PU boundary is the fault-containment region (typed MsiProcessorError → flagged, reported failure); re-run granularity comes from the breakpoints (DEC-07).

Consequences / cost accepted. A failed run must be re-run; acceptable for batch processing. Observational deviations (QA metric out of tolerance) are warnings, not exceptions, so they do not abort the run.

Trace. C-COM-ORC (fail-stop), all Cores (typed errors). REQ-F-DEP-01, REQ-REL-02, REQ-SAF-01.

<5.11> DEC-11 — Pure-Python 3.11 on CPU vs native extensions / GPU acceleration#

Context / drivers. Choose the implementation substrate against portability, long lifetime and the CI constraint. Drivers: REQ-R-01 (x86-64 Linux multi-core CPU, no GPU required), REQ-R-03 (Python 3.11 + pinned stack), REQ-PORT-01/02 (relocatable SDE↔local), REQ-D-09/long-lifetime (SDD <4.5>).

Option	Pros	Cons
Pure Python 3.11 + portable array libs (numpy/xarray), CPU only (chosen)	No native build/toolchain; relocatable SDE↔local (REQ-PORT-01/02); long-lifetime, low platform assumption (SDD <4.5>); horizontal scaling via Dask (DEC-08) covers throughput	Per-element Python is slower than native/GPU for some kernels
Native (C/Cython) extensions	Faster hot kernels	Build/portability burden; harder to relocate and maintain (single developer); off REQ-R-01
GPU acceleration	Fast for some stages	Requires GPU hardware/runtime — against REQ-R-01 (no GPU required); not available on the CI host; portability/lifetime cost

Decision & rationale. Pure Python 3.11 on CPU. REQ-R-01 explicitly does not require a GPU; portability and long lifetime (REQ-PORT, SDD <4.5>) outweigh raw single-node speed, and throughput is met by horizontal scaling (Dask, DEC-08) rather than native/GPU acceleration. The vectorised numpy/xarray kernels are adequate within the block model.

Consequences / cost accepted. Some kernels slower than a native/GPU build; accepted and addressed by chunking/parallelism. A future hot-spot can be optimised behind IF-CORE-01 without disturbing the chain.

Trace. Architecture-wide; Cores, C-COM-CHUNK. REQ-R-01/-03, REQ-PORT-01/02; SDD <4.5>.

<5.12> DEC-12 — Determinism via profile-fixed seeds vs free RNG#

Context / drivers. Output must be reproducible for a fixed input/ADF/profile/processor, but some kernels are stochastic (RANSAC in coregistration/geolocation). Drivers: REQ-F-DEP-02 / REQ-REL-01 (reproducibility), REQ-D-05 (numerics/tolerances). Basis: ATBD <6>.

Option	Pros	Cons
Profile-fixed seeds for all stochastic kernels (chosen)	Bit-reproducible runs for a fixed quadruple (REQ-F-DEP-02, REQ-REL-01); verifiable against checksummed references (R-03); seed is profile data, not code	Seed must be carried in the profile and echoed in provenance
Free / time-based RNG	Marginally simpler	Non-reproducible outputs — breaks REQ-F-DEP-02/REQ-REL-01 and golden-test verification under private-data-only (R-03)

Decision & rationale. Fix seeds in the profile. Reproducibility is required (REQ-F-DEP-02) and is the foundation of the verification strategy under private-data-only constraints (DEC-13, R-03): golden tests need bit-stable outputs. The seed lives in the profile (data) and is recorded in provenance.

Consequences / cost accepted. Seeds carried in profile + provenance. Accepted; negligible cost.

Trace. C-PU-COR, C-PU-GEO (RANSAC), C-COM-PROV. REQ-F-DEP-02, REQ-REL-01, REQ-D-05; ATBD <6>; R-03.

<5.13> DEC-13 — Verification independence by tooling + synthetic fixtures vs (private-data, single-developer)#

Context / drivers. Code is public but raw L0 and calibration are private; there is a single developer and no second verifier and no public reference product for L0→L1. Drivers: REQ-S-01 (public code / private data), REQ-D-03 (unit-testable cores), REQ-Q-01 (quality gates). Risks: R-03 (private-data-only / no public reference — top assurance risk), R-02 (shell-runner limits), R-07 (data/secret leakage), R-08 (bus factor / independence). Mechanism defined in the SRevP (RD-2) and V&V plan (RD-3).

Option	Pros	Cons
Automated CI gates + explicit checklists + deterministic synthetic fixtures in public CI; real-data numerical verification local, summarised in the SVR (chosen)	Independence by tooling not staff (R-08); no private data ever in public CI/repo (REQ-S-01, R-07); golden tests run publicly on non-sensitive fixtures; real-data evidence captured locally (SVR, RD-4)	Real-data correctness is verified locally, not in public CI — only summaries are public
Put real data in (private) CI	Full data-path verification in CI	Risks irreversible disclosure (R-07); no private CI/runner available; against REQ-S-01
Second independent verifier	Human independence	Not available (single developer, R-08); not warranted at Category C

Decision & rationale. Achieve independence through automation + checklists + synthetic golden fixtures, with real-data numerical verification performed locally and only its summary results published in the SVR. This is the only model that satisfies REQ-S-01 (no private data in public CI, R-07), works for a single developer (R-08), and still yields auditable, reproducible verification (enabled by DEC-04 and DEC-12). Affected jobs that need a container/Dask/S3 runtime are non-blocking (allow_failure) on the shell runner (R-02) with equivalent local evidence in the SVR.

Consequences / cost accepted. Real-data correctness is locally verified, not publicly re-runnable; the SVR carries the checksummed evidence; where a comparable open product exists it is cross-checked (e.g. SNAP/ESA L1). Accepted and risk-tracked (R-02, R-03).

Trace. Verification architecture; Cores (testable, DEC-04), C-COM-PROFILE/ADF (private by URI). REQ-S-01, REQ-D-03, REQ-Q-01; R-02, R-03, R-07, R-08; SRevP RD-2, V&V plan RD-3.

<5.14> DEC-14 — Per-pixel QA bit-flag registry + provenance as the integrity mechanism#

Context / drivers. A Category C processor whose residual hazard is product-data integrity must carry localised quality and full provenance, not just pass/fail. Drivers: REQ-F-QA-01/02 (metrics + per-pixel flags), REQ-F-PRD-02 (provenance), REQ-SAF-01 (integrity). Basis: ICD <5.3.3>E (flag bits).

Option	Pros	Cons
Single per-pixel `QAFlag` bit registry (monotone OR-accumulated) + provenance metadata (chosen)	Localised, per-pixel defect tracking (loss, saturation, bad-pixel, coreg-fail, cloud/shadow); single source of truth (ICD <5.3.3>E); pairs with fail-stop as the integrity triad (DEC-10); reproducible	Bit budget must be managed (one reserved bit `[TBC@CDR]`)
Per-stage ad-hoc masks	Simple per stage	Inconsistent semantics; hard to propagate/trace; no single registry
Scene-level quality only	Cheap	Loses per-pixel locality; insufficient for integrity evidence

Decision & rationale. A single, OR-accumulated per-pixel QAFlag registry plus provenance. It gives the localised integrity evidence the hazard class demands (REQ-SAF-01), is consistent across stages (one registry, ICD <5.3.3>E), and forms the fail-stop + QA flags + provenance integrity triad of clause <9>.

Consequences / cost accepted. A managed bit budget (currently 7 defined, 1 reserved). Accepted.

Trace. C-COM-QAFLAG, C-PU-QA, C-COM-PROV. REQ-F-QA-01/02, REQ-F-PRD-02, REQ-SAF-01; ICD <5.3.3>E.

<5.15> Decision → driver/risk cross-reference#

Decision	Primary `REQ-*` drivers	Risks treated	Design `C-*`
DEC-01 EOPF CPM	D-01, D-06, D-09, F-PRD-01, I-05/06	R-05, R-10	C-COMPUTING, C-COM-PRODUCT/IO/ORC
DEC-02 `eopf==2.8.1` pin	R-03(req), REL-01, F-DEP-02, M-03	R-01, R-05	platform-wide
DEC-03 sensor-profile	AD-01..04, D-04/-07, S-01/05, M-02	R-04, R-08	C-SENSORS, C-COM-PROFILE/ADF/CONFIG
DEC-04 core+wrapper	D-03/-04, M-04, PORT-03	R-05, R-03	all C-PU-*
DEC-05 reuse algorithms	D-06, SDP <4.1>3	R-08	C-PU-L0/RAD/ENH/TOA/COR/GEO/PAN/QA
DEC-06 L2 new dev + RT basis	F-ATM-01..04, P(BOA)	R-06	C-PU-ATM
DEC-07 PU-per-stage	F-ORC-01, REL-02, M-04, F-ENH-03	—	C-COMPUTING, C-COM-ORC
DEC-08 chunk + Dask	F-ORC-02, P-04/05, R-04, PORT-03	R-02	C-COM-CHUNK, spatial C-PU-*
DEC-09 Zarr/EOProduct I/O	D-06/-09, F-PRD-01, I-06, PORT-02	R-10, R-01, R-05	C-COM-PRODUCT/IO
DEC-10 fail-stop	F-DEP-01, REL-02, SAF-01	—	C-COM-ORC, Cores
DEC-11 pure-Python/CPU	R-01/-03, PORT-01/02	—	architecture-wide
DEC-12 fixed seeds	F-DEP-02, REL-01, D-05	R-03	C-PU-COR/GEO, C-COM-PROV
DEC-13 tooling independence	S-01, D-03, Q-01	R-02, R-03, R-07, R-08	verification arch.
DEC-14 QA flags + provenance	F-QA-01/02, F-PRD-02, SAF-01	—	C-COM-QAFLAG, C-PU-QA, C-COM-PROV

<6> Make-or-buy (reuse) decisions#

ECSS-E-ST-40C §4.2.4 requires make-or-buy decisions to be recorded in the DJF; the authoritative reuse analysis (licences, versions, reuse risks) is the SRF (RD-6, Annex N). The per-component make-or-buy outcome, consistent with SDD <5.3> (development type):

Component	Make-or-buy	Basis / source
EOPF CPM runtime (`EOProcessingUnit`/`EOProduct`/`EOZarrStore`)	buy (reuse) — DEC-01	EOPF CPM `eopf==2.8.1` (AD-4)
Scientific stack (numpy, xarray, zarr, Dask, scikit-image, OpenCV, GDAL/rasterio, pywt, scikit-learn)	buy (reuse)	open-source, SRF (RD-6)
C-PU-L0/RAD/ENH/TOA/COR/GEO/PAN/QA Cores	buy then adapt (reuse-adapt) — DEC-05	prior work RD-9, via SRF
C-PU-ATM (atmospheric L2) Core	make (new development) — DEC-06	DPM-M-ATM/ALG-ATM-*; established RT/LUT basis
C-SENSORS / C-COM-* services (profile, product, io, adf, prov, qaflags, chunking, config, orchestration, cli)	make (new, over CPM/Dask) — DEC-03/-04/-08/-09	this project

Net. The project is reuse-dominated (platform + L0→L1 algorithms + scientific stack are reused); the new development is confined to the integration/services layer and the L2 atmospheric Core — which is exactly the productisation scope and the locus of the top technical risk (R-06). Licence compatibility and reuse risks are assessed in the SRF (RD-6).

<7> Feasibility analyses and supporting technical assessments#

The supporting assessments (ECSS-E-ST-40C §4.2.4) that show the chosen design is feasible within its constraints:

Memory / throughput feasibility (DEC-08). Peak per-worker memory is governed by the configured block/tile size (C-COM-CHUNK), not product size, and wall-time scales with tiles × workers (SDD <4.6>; REQ-P-04/05, REQ-R-04). georeference and atmospheric are the memory/compute hot-spots and the priority chunking/Dask validation targets. Absolute numeric budgets (MEM_BUDGET, THRU_SCENE) are per-profile private parameters verified locally (SRS <5.1>, DPM-PRM-GEN-02) and are not reproduced here.
CI / runner feasibility (DEC-08, DEC-13; R-02). The same Cores run sequentially on the EOPF SDE shell runner (no container/Dask/S3); jobs needing those runtimes are non-blocking (allow_failure) with equivalent local evidence in the SVR (RD-4). Feasible today; a Kubernetes/Dask-gateway runner is a tracked improvement, not a precondition.
Atmospheric L2 feasibility (DEC-06; R-06). Feasibility rests on building on an established radiative-transfer model / LUT (6S / libRadtran class) rather than a novel algorithm, scheduling L2 last with margin, and fixing the C-PU-ATM interface at CDR so chain integration does not wait on the engine down-select (<10> DEC-D1). Explicit L2 acceptance criteria are set in the SValP (RD-3).
Verification feasibility under private data (DEC-12, DEC-13; R-03). Deterministic synthetic fixtures make golden-test verification feasible in public CI without private data; bit-reproducibility (fixed seeds) makes checksummed references possible; real-data numerical verification is performed locally and summarised in the SVR. Where a comparable open product exists, cross-checking against an open reference processor (e.g. SNAP/ESA L1) is used.
Portability / long-lifetime feasibility (DEC-09, DEC-11). Pure Python + open Zarr + URI/store abstraction keep the only platform assumption a POSIX x86-64 Linux host and keep products readable independently of this software (SDD <4.5>; REQ-PORT-01/02, REQ-D-09).
Technical budgets / margins. Per the SRevP (RD-2 <6>) and SDP (RD-12 <5.3.8> philosophy), technical budgets (radiometric/geometric/BOA accuracy, throughput, memory) are per-profile and verified locally; the margin status is reported at each milestone. The design imposes no budget that the block model cannot meet by sizing (C-COM-CHUNK) and parallelism.

<8> Demonstration that the design meets the requirements#

The DJF must show that the design meets all requirements (ECSS-E-ST-40C §4.2.5). At CDR this is established by complete traceability plus the verification/validation design; executed results are added to the DJF at QR/AR (SVR, RD-4):

Requirement → design coverage. Every REQ-* is allocated to at least one design component, and every component traces to at least one REQ-* (no orphans, no unimplemented requirements). The forward and backward traces are in SDD <6.1>/<6.2> and the authoritative matrix RD-7; each component also links to its DPM module (DPM-M-*) and ATBD algorithm (ALG-*).
Design decision → requirement coverage. Every decision in <5> cites its driving REQ-*/R-* (<5.15>), so the rationale layer is itself traceable to the requirements it serves.
Verification/validation design. The merged V&V plan (RD-3: SVerP+SValP+SUITP) defines the unit, integration and validation test design, including the per-stage tolerances (REQ-D-05; DPM/ATBD) and the methods (Test/Inspection/Analysis/Review) recorded in the SRS verification matrix (RD-8 <7>).
Review approach. The SRevP (RD-2) defines how each milestone (incl. CDR) checks design maturity and baselines it, and how the continuous MR/CI gates supply verification independence.
Reuse adequacy. The SRF (RD-6) shows the reused components are fit, licence-compatible and reuse-risk-assessed.

Together these show, at the CDR design-freeze, that the design can meet the requirements; the SVR (RD-4) records that it does, at QR.

<9> Critical-software-component measures — justification (Annex F <6>c)#

This clause carries the detailed justification that SDD <6.3> defers to the DJF, per ECSS-Q-ST-80 §6.2.2.4 (minimising critical components) and ECSS-E-ST-40C Annex F <6>c.

Criticality context. msi-processor is Category C: a software failure produces only degraded or incorrect data products, recoverable by reprocessing — no safety, mission-loss or space-segment consequence (SDP <5.6>; severity ≤ Major). The residual hazard class is product-data integrity (REQ-SAF-01).

Measures provided (design, not extra mechanism). The integrity of the product is protected by design features that exist for functional reasons and double as the criticality measures:

No hard-coded instrument constants in the core (DEC-03; REQ-D-04) — a calibration error is a data fix (ADF/profile swap), not a code change, shrinking the critical code surface.
Pure-core isolation behind a tested interface (DEC-04; REQ-D-03) — numerical kernels are unit-verifiable in isolation and off-platform, with per-stage tolerances in the DPM/ATBD (REQ-D-05).
Bounded cyclomatic complexity (xenon thresholds) per core/unit; the thin-wrapper template keeps CPM-facing code trivial (REQ-D-04, REQ-Q-04).
Typed fault containment — the MsiProcessorError hierarchy makes every failure a typed, flagged, reported event at the PU boundary; no silent cross-DAG propagation (DEC-10).
Determinism / reproducibility for a fixed input/ADF/profile/processor quadruple, incl. profile-fixed RANSAC seeds (DEC-12; REQ-F-DEP-02, REQ-D-05).
Integrity triad: fail-stop + per-pixel QA flags + provenance (DEC-10, DEC-14; REQ-F-DEP-01, REQ-F-QA-02, REQ-F-PRD-02) — no partial or misleading product is ever published as complete.

Special measures deliberately NOT levied. No software-criticality-driven special measures — redundancy, watchdog, N-version programming, defensive hardware fault tolerance — are applied. The justification: such measures address safety/availability hazards (Category A/B) that do not exist here; the hazard is data integrity, which is fully addressed by detect-and-stop (fail-stop) plus localised QA and provenance, and any incorrect product is recoverable by reprocessing. Adding redundancy/N-version would add cost and complexity (against REQ-D-04 minimisation) with no risk reduction at Category C. This records and closes Annex F <6>c.

<10> Design decisions deferred to implementation (`[impl]`)#

A small set of element-level choices are legitimately finalised during implementation (post-CDR); their interfaces and selection criteria are fixed at CDR, so the design freeze holds. Each is recorded as a deferred decision with its resolution criterion and owning component.

Id	Deferred decision	Fixed at CDR	Resolution criterion (when/how decided)	Component	Driver / risk
DEC-D1	Atmospheric RT engine (6S vs libRadtran vs LUT) and scene classifier	C-PU-ATM interface, DPM-M-ATM/ALG-ATM-*	Down-select in implementation against BOA accuracy budget + L2 acceptance criteria (SValP); prototype-driven	C-PU-ATM	REQ-F-ATM-*, R-06
DEC-D2	L0 bit-codec body (packet/CRC/corruption handling beyond the zero-line rule)	`decode`/`detect_and_truncate_loss` signatures, QA semantics	Implemented against the NDA-bound sensor spec; private, profile-bound	C-PU-L0	REQ-F-L0-*, ATBD <5.1>
DEC-D3	Geolocation kernel (rigorous collinearity model internals; GCP/DEM resampling tunings)	IF-CORE-01, DPM-M-GEO/ALG-GEO-*	Implemented + tuned against GCP residual budget (CE90)	C-PU-GEO	REQ-F-GEO-*, R-09
DEC-D4	Coregistration matcher/filter tunings (SIFT/FLANN/RANSAC thresholds)	IF-CORE-01, acceptance check (match count/residual)	Tuned against the band-coregistration accuracy budget; profile-fixed seeds	C-PU-COR	REQ-F-COR-*, R-03
DEC-D5	Pan-sharpen optional-stage validation status (pan-sharpen default-off until validated); enhancement denoise method/tuning (MTF compensation / PSF deconvolution mandatory and always run; denoise method profile-selectable)	Pan-sharpen present, toggleable, default-off; enhancement stage present and mandatory (MTFC always runs)	Pan-sharpen enabled per profile only after the stage is validated (SValP); enhancement denoise method/parameters selected per sensor profile	C-PU-PAN, C-PU-ENH	REQ-F-ENH-03
DEC-D6	CPM computing-model JSON exact keys (`[TBC@CDR]` against 2.8.1)	The model contract (inputs/adfs/outputs/params/modes)	Confirmed against the pinned `eopf==2.8.1` schema at CDR finalisation	all C-PU-*	REQ-I-07, DEC-02

These are recorded so the CDR can confirm that nothing architectural is deferred — only bodies and tunings whose contracts are already fixed.

<11> DJF constituents and references#

The DJF is a file; this document is its design-justification head. Its constituents and their roles:

DJF constituent	DRD (E-40 annex)	Role in the DJF	Reference	Status
DJF — Design Justification (this document)	§4.2.4/§4.2.5 concept	Decision rationale, trade-offs, make-or-buy, feasibility, criticality-measure justification	this file	Draft for CDR
SRevP — Software Review Plan	Annex P	Review approach (incl. CDR) and continuous MR/CI review; independence model	RD-2	Baselined (SRR)
V&V plan (SVerP+SValP+SUITP)	Annexes I/J/K	Verification/validation/unit-integration test design showing the design can meet requirements	RD-3	Baselined (PDR); SUITP at CDR
SVR — Software Verification Report	Annex M	Executed verification results (added to the DJF at QR)	RD-4	At QR
SRF — Software Reuse File	Annex N	Reuse analysis, licences, reuse risks (supports the make-or-buy of <6>)	RD-6	At CDR
Traceability matrix	E-40 §5.8	Requirement→design→test closure (supports <8>)	RD-7	At CDR

This document does not restate requirements (SRS, RD-8), the design (SDD, RD-1), the algorithm mathematics (DPM RD-10 / ATBD RD-11) or the concrete interfaces (ICD, RD-13); it justifies the design those documents define, and binds each decision to its REQ-*, R-* and C-*.

End of DJF — Design Justification (CDR issue). Authored per ECSS-E-ST-40C Rev.1 §4.2.4/§4.2.5 (DJF concept) and Annex F <6>c, tailored for Category C / single-developer. Design decisions DEC-* trace to the SRS (REQ-*, RD-8), Risk Register (R-*, RD-5) and SDD (C-*, RD-1). Implementation (SDP WP-5) and the [impl]/DEC-D* deferred decisions are resolved only after CDR.