# Qualification Review (QR) Report

| Field | Value |
|---|---|
| **Document** | Qualification Review (QR) Report — milestone review record (incl. anticipated TRR/TRB) |
| **DRD ref** | ECSS-E-ST-40C Rev.1, Annex P/Q (review plan & content) + ECSS-M-ST-10-01C (organization and conduct of reviews); QR objectives & success criteria per SReVP (RD-2) <6>/<7>; ECSS-Q-ST-80C Rev.2 |
| **Container** | Management File (MGT) — `compliance/` |
| **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** | QR |
| **Status** | Issued at QR |

> This is the **milestone review record of the Software Qualification Review (QR)** of the
> `msi-processor` software configuration item. It records the QR objectives, the QR **data package**
> reviewed, the consolidated **verification & validation evidence**, the **SPR/NCR** and **RID** status,
> the assessment of the **QR success (exit) criteria** defined in the Software Review Plan (SReVP, RD-2)
> <6>/<7>, the **action items** carried to the Acceptance Review (AR), and the **review conclusion**. It
> is the QR counterpart of the SRR/PDR/CDR milestone records and is produced per SReVP <7>.4 ("review
> report" = milestone review record). The QR folds in the **anticipated Test Readiness Review / Test
> Review Board (TRR/TRB)** objectives (SReVP <4.1>/<6>). The configuration under review is the `main`
> baseline at commit **d140599** (latest `main` pipeline **30730** = success). The footprint is tailored
> to a **Category C, single-developer** ground-segment processor whose **code is public but whose raw
> `L0` data and instrument calibration are private** (RD-4 SRS <5.1>/<5.8>) — the policy that scopes what
> QR can prove publicly versus what is deferred to AR on operator data.

**DRD clause coverage.** Where this QR Report satisfies each review-report / Annex P–Q content item:

| Review-report content (SReVP RD-2 <6>/<7>; Annex P/Q) | This document |
|---|---|
| Review identification, objectives, level of formalism (SReVP <6> QR; anticipated TRR/TRB) | <1>, <4> |
| Applicable / reference documents | <2> |
| Terms, definitions, abbreviations | <3> |
| Data package subject to review (SReVP <10>, QR row) | <5> |
| Review minutes / consolidated verification evidence (SReVP <7>.4) | <6> |
| SPR/NCR status (SReVP <6> QR; <7>.2b/c) | <7> |
| RID status metric + dispositioned RIDs (SReVP <13>; <7>.4) | <8> |
| Review success (exit) criteria assessment + conclusion (SReVP <7>.2/<7>.3) | <9>, <11> |
| Actions raised / carried forward (SReVP <7>.4; <9>) | <10> |

---

## <1> Introduction

**Purpose.** This QR Report assesses whether `msi-processor` has been **implemented, integrated and
qualified against its technical specification** (the SRS, RD-4) such that the project may be authorised
to proceed to the Acceptance Review (AR). It records the objective evidence supporting that decision and
the actions that remain open.

**Software under review.** `msi-processor` is a generic, sensor-agnostic high-resolution **pushbroom MSI
ground processor** that transforms downlinked private RAW (`L0`) into calibrated, orthorectified and
atmospherically corrected products up to **`L2A`**, built on the ESA EOPF CPM (`EOProcessingUnit` /
`EOProduct` / `EOZarrStore`, Zarr persistence; `eopf == 2.8.1`, Python 3.11). It is an **integration and
ECSS-productisation** effort over existing algorithm heritage (RD-1 §1; SRF RD-19), not new-algorithm
research.

**Life-cycle position.** SRR, PDR and CDR are closed and baselined to `main`; implementation was
authorised at CDR exit (RD-1 §5.1). This QR is the qualification gate: the eight processing units are
implemented and CI-green on `main`, and the QR data package (<5>) consolidates the verification and
validation evidence produced by executing the V&V Plan (RD-8) and the SUITP (RD-10).

**Content.** Clause <2> lists the applicable/reference documents; <3> adds QR-specific terms; <4> records
the QR objectives (quoting SReVP <6>) and the anticipated TRR/TRB; <5> inventories the QR data package by
compliance path; <6> consolidates the verification & validation summary; <7> records SPR/NCR status; <8>
records RID disposition; <9> assesses the four SReVP QR exit criteria; <10> lists the action items carried
to AR; <11> states the conclusion.

---

## <2> Applicable and reference documents

### Applicable documents (AD)

| Id | Document | Reference |
|---|---|---|
| AD-1 | ECSS Space engineering — Software (Annex P/Q reviews; Annex I/J V&V; Annex K SUITP; Annex M SVR) | ECSS-E-ST-40C Rev.1 (30 April 2025) |
| AD-2 | ECSS Space product assurance — Software (§6.2.6.1 quality verification; §6.3.5 testing/validation) | ECSS-Q-ST-80C Rev.2 |
| AD-3 | ECSS Space project management — Organization and conduct of reviews | ECSS-M-ST-10-01C |
| AD-4 | ECSS Configuration and information management | ECSS-M-ST-40C |
| AD-5 | EOPF CPM — Product Structure & Format Definition (PSFD) / data model | EOPF CPM docs (`eopf == 2.8.1`) |

### Reference documents (RD)

| Id | Document | Reference |
|---|---|---|
| RD-1 | `msi-processor` Software Development Plan (SDP) | `compliance/software-development-plan.md` |
| RD-2 | `msi-processor` Software Review Plan (SReVP) — QR objectives, success criteria, RID form | `compliance/drd/srevp-software-review-plan.md` |
| RD-3 | `msi-processor` Software Product Assurance Plan (SPAP) | `compliance/drd/spa-plan.md` |
| RD-4 | `msi-processor` Software Requirements Specification (SRS) — `REQ-*` | `compliance/drd/srs-software-requirements.md` |
| RD-5 | `msi-processor` Interface Control Document (ICD) | `compliance/drd/icd-interface-control.md` |
| RD-6 | `msi-processor` Detailed Processing Model (DPM) — `DPM-M-*` | `compliance/drd/dpm-data-processing-model.md` |
| RD-7 | `msi-processor` Algorithm Theoretical Basis Document (ATBD) — `ALG-*` | `compliance/drd/atbd-algorithm-theoretical-basis.md` |
| RD-8 | `msi-processor` V&V Plan (SVerP + SValP; three-tier scheme) | `compliance/drd/vv-plan.md` |
| RD-9 | `msi-processor` Software Design Document (SDD) — `C-*`, `IF-*` | `compliance/drd/sdd-software-design.md` |
| RD-10 | `msi-processor` SUITP (Annex K — unit/integration test specs & procedures) | `compliance/drd/suitp-unit-integration-test-plan.md` |
| RD-11 | `msi-processor` Traceability matrix (RTM) — REQ↔design↔test, bidirectional | `compliance/traceability/traceability-matrix.md` |
| RD-12 | `msi-processor` Software Verification Report (SVR, Annex M) — **QR deliverable** | `compliance/drd/vv-report.md` |
| RD-13 | `msi-processor` Software Unit & Integration Test Report (SUITR) — **QR deliverable** | `compliance/drd/suitr-unit-integration-test-report.md` |
| RD-14 | `msi-processor` Software Release Note / Document (SRN/SRelD) — **QR deliverable** | `compliance/drd/srn-software-release-note.md` |
| RD-15 | `msi-processor` Configuration Item Data List (CIDL) — **QR deliverable** | `compliance/drd/cidl-configuration-item-data-list.md` |
| RD-16 | `msi-processor` Software Configuration File (SCF) — **QR deliverable** | `compliance/drd/scf-software-configuration-file.md` |
| RD-17 | `msi-processor` Software User Manual (SUM, start) — **QR deliverable** | `docs/sum/` |
| RD-18 | `msi-processor` Risk Register | `compliance/drd/risk-register.md` |
| RD-19 | `msi-processor` Software Reuse File (SRF) | `compliance/drd/srf-software-reuse-file.md` |
| RD-20 | `msi-processor` Design Justification File (DJF) | `compliance/drd/djf-design-justification.md` |
| RD-21 | `msi-processor` Software System Specification (SSS) — `SYS-*` | `compliance/drd/sss-software-system-specification.md` |
| RD-22 | `msi-processor` Interface Requirements Document (IRD) — `REQ-IF-*` | `compliance/drd/ird-interface-requirements.md` |
| RD-23 | CI pipeline definition + verification evidence | `.gitlab-ci.yml`; `main` pipeline **30730** (commit **d140599**) |

---

## <3> Terms, definitions and abbreviated terms

The SDP §3, SRS <3>, SDD <3>, V&V Plan (RD-8) <3>, SUITP (RD-10) <3> and SReVP (RD-2) <3> glossaries apply
in full. Only terms specific to this QR record and not defined there are added.

| Term / abbr. | Definition |
|---|---|
| QR | Software Qualification Review — qualification of the software against the technical specification (SRS, RD-4) |
| TRR / TRB | Test Readiness Review / Test Review Board — E-ST-40C sub-reviews **anticipated within the QR** (SReVP <4.1>/<6>) |
| AR | Software Acceptance Review — validation against the Requirements Baseline; the next milestone |
| RB / TS | Requirements Baseline (SSS RD-21 + IRD RD-22) / Technical Specification (SRS RD-4) |
| SPR / NCR | Software Problem Report / Non-Conformance Report (SPAP RD-3 §6.5; SReVP <13>) |
| RID | Review Item Discrepancy — a finding raised against a review item (SReVP <13>) |
| SCI | Software Configuration Item — the `main` baseline of the repository |
| Tier A / B / C | The V&V-Plan three-tier scheme (RD-8 <4>): A = deterministic synthetic unit/plumbing tests in public CI (blocking); B = local real-RAW integration (non-blocking/skipped in public CI); C = reference/validation-data **numeric budget** metrics (local; reported in the SVR) |
| `[impl]` item | A documented, fail-stop **deferred algorithm body** that the operational baseline never executes; recorded as a waiver and traced in the RTM (RD-11) |
| Budget parameter | A per-profile numeric tolerance (`RAD_ACC`, `GEO_CE90`, `BAND_COREG`, `BOA_ACC`, `THRU_SCENE`, `MEM_BUDGET`) held privately (RD-4 SRS <5.1>) |
| Blocking gate | A CI job whose failure fails the pipeline (verification gate); contrast `allow_failure` (non-gating) |

---

## <4> QR objectives

The QR objectives are those defined for the QR in the SReVP (RD-2 <6>), reproduced here verbatim. The QR
is conducted as a **documented, checklist-based, asynchronous milestone review on the GitLab platform**
(SReVP <6>/<8>), with the CI verification evidence as the primary input, and **folds in the anticipated
Test Readiness Review / Test Review Board (TRR/TRB)** objectives.

**QR objectives (SReVP <6>, "QR objectives — includes anticipated TRR/TRB"):**

- Verify that the software **meets all of its specified requirements** and that verification and
  validation processes (per the V&V plan) **have completed successfully**.
- Verify that **all Requirements-Baseline and interface requirements have been validated and verified**,
  including **technical budgets** and **code coverage** (EOPF coverage gate).
- Verify that the **Software Configuration Item** under review is a **formal version under configuration
  control** (Git tag / SCF / CIDL); **release the software release document** (SRelD/SRN).
- **Confirm the test/RB-validation configuration**; **check the status of all SPRs/NCRs**; **baseline the
  validation specification against the RB**; **evaluate readiness to proceed to AR**.

**Anticipated TRR/TRB (folded into QR).** Per SReVP <4.1>/<6>, the QR also discharges the TRR/TRB intent:
confirm that the test configuration is frozen and identified (baseline commit **d140599**, pipeline
**30730**); confirm test readiness and that the executed test campaign (Tier A in CI, Tier B/C locally) is
complete and reviewed; and disposition the test results and any anomalies before authorising transition.
The assessment against these objectives is in <6> (evidence), <7> (SPR/NCR), <8> (RIDs) and <9> (exit
criteria).

---

## <5> QR data package inventory

Per SReVP <10> (QR row), the QR data package comprises the five DRD deliverables **SVR, SUITR, SRelD/SRN,
CIDL, SCF**, plus the **SUM (start)** and the **CI verification evidence**. Each is referenced below by its
compliance path; deliverables authored within this QR package or still being completed are flagged with
the corresponding action item of <10>.

| # | Deliverable | DRD / Annex | Path (compliance / repo) | Status at QR |
|---|---|---|---|---|
| 1 | **SVR** — Software Verification Report (V&V results record) | E-ST-40C Annex M; from RD-8 / RD-10 execution | `compliance/drd/vv-report.md` (RD-12) | Issued at QR — consolidates Tier A/B/C verdicts; Tier-C numeric budgets carried (AI-QR-01) |
| 2 | **SUITR** — Software Unit & Integration Test Report | E-ST-40C Annex K results; companion to SUITP (RD-10) | `compliance/drd/suitr-unit-integration-test-report.md` (RD-13) | Issued at QR with action — completion published per AI-QR-03 |
| 3 | **SRelD / SRN** — Software Release Note/Document | E-ST-40C (release); SReVP <6> QR | `compliance/drd/srn-software-release-note.md` (RD-14) | Authored in this package — states RC **v0.1.0-rc1** referenced to baseline commit **d140599**; formal Git tag is the release action (AI-QR-04) |
| 4 | **CIDL** — Configuration Item Data List | E-ST-40C / M-ST-40C config control | `compliance/drd/cidl-configuration-item-data-list.md` (RD-15) | Authored in this package — lists the SCI constituents under Git config control |
| 5 | **SCF** — Software Configuration File | E-ST-40C / M-ST-40C config control | `compliance/drd/scf-software-configuration-file.md` (RD-16) | Authored in this package — records the as-built configuration at d140599 |
| 6 | **SUM (start)** — Software User Manual | E-ST-40C Annex S (start at QR, final at AR) | `docs/sum/` (RD-17) | Start — tree exists (introduction, operations, reference, tutorials, notebooks); finalised at AR (AI-QR-03) |
| 7 | **CI verification evidence** | E-ST-40C Annex I <7.3>; SPAP RD-3 §7 | `.gitlab-ci.yml`; `main` pipeline **30730** @ **d140599** (RD-23) | Green — 9 blocking verification gates pass; artefacts (JUnit, Cobertura coverage, lint/SAST/SCA logs) |

Supporting baselined inputs reviewed alongside the data package: the SRS (RD-4), SDD (RD-9), DPM (RD-6),
ATBD (RD-7), V&V Plan (RD-8), SUITP (RD-10) and the **traceability matrix / RTM** (RD-11), plus the RID
log from the prior milestone (SReVP <10>). No private raw data or calibration is part of any review data
package or public CI (SReVP <12>; RD-4 SRS <5.1>/<5.8>).

---

## <6> Verification & validation summary

This clause consolidates the verification evidence produced by executing the V&V Plan (RD-8) and the
SUITP (RD-10) on the QR baseline (commit **d140599**, `main` pipeline **30730** = success). Detail is in
the SVR (RD-12) and SUITR (RD-13); the authoritative trace is the RTM (RD-11).

### <6.1> Implementation completeness — 8 of 8 processing units

All eight processing units are implemented on `main` and CI-green, each as a **pure framework-independent
core** + a thin `EOProcessingUnit` wrapper + a per-unit computing-model JSON (RD-9; RD-4 REQ-D-03):

| Unit | Product level | Notes |
|---|---|---|
| `l0_decode` | `L1A` | open-container sample layout on the public path |
| `radiometric` | `L1A` | dark/NUC/BPR/saturation |
| `enhancement` | `L1B` | **MTF-compensation mandatory** (always runs); configurable denoise |
| `toa` | `L1B` | DN→radiance, optional reflectance |
| `coregistration` | `L1B → L1C` | feature-based inter-band alignment, fail-stop |
| `georeference` | `L1C` | GCP reference-image refinement on the operational path |
| `atmospheric` | `L2A` | new design; TOA→BOA, scene class + masks |
| `pansharpen` | optional post-`L2A` derivative | `simple_mean` operational |

The design realised is **21 design components (`C-*`)**, **11 DPM modules (`DPM-M-*`)** and **33 algorithms
(`ALG-*`)** (RD-9, RD-6, RD-7).

### <6.2> Test campaign — 248 test cases

The test suite was pytest-collected on the CPM environment (`eopf == 2.8.1`, Python 3.11). **238 test
functions** (some parametrised) are collected as **248 test cases**: **246 unit** (244 passed, **2
xfailed**) + **2 integration** (2 passed).

| Module (test functions) | Count |
|---|---|
| `l0_decode` | 22 |
| `radiometric` | 21 |
| `enhancement` | 35 |
| `toa` | 24 |
| `coregistration` | 23 |
| `georeference` | 27 |
| `atmospheric` | 35 |
| `pansharpen` | 29 |
| `common` (types + metrics) | 15 |
| `sensors` (profile) | 7 |
| **Total test functions** | **238** |

- **Unit (Tier A):** 246 cases — **244 passed, 2 xfailed**. The **2 xfailed** are in
  `tests/ut/computing/test_georeference_core.py` and **intentionally verify the `orthorectify` `[impl]`
  fail-stop** (they are expected failures, not defects).
- **Integration (Tier A CI-chain):** 2 cases in `tests/it/computing/test_full_chain.py` — the full
  `L0c → L2A` chain and the chain-with-pansharpen, wiring **all 8 units** on one synthetic feature-rich
  scene, both passing. This integration campaign **surfaced and fixed a real defect**: `AtmosphericUnit`
  was dropping the `L1C` geolocation grid from `L2A`; fixed by conditions passthrough (now part of the
  baseline at d140599). This is positive evidence that integration testing is materially exercising the
  chain, not merely smoke-testing it.

### <6.3> CI verification gates — 9 blocking gates green

On `main` pipeline **30730** the **nine blocking verification/quality gates** are all green (preceded by
the `validate-variables` precondition guard, which checks the mandatory pipeline variables):

| Gate (CI job) | Method | Verifies |
|---|---|---|
| `linter` (flake8) | I | style/lint (PEP 8) |
| `docker-linter` (hadolint) | I | Dockerfile lint |
| `formater` (black + isort) | I | format conformance |
| `typing` (mypy) | I | static type contracts |
| `unit-tests` (pytest `-m unit` + coverage Cobertura) | T | functional correctness + **code-coverage gate** (≥ 70 % new code, REQ-Q-02) |
| `security` (bandit) | I/T | SAST (Python security defects) |
| `deps-sec` (pip-audit, isolated venv) | I | dependency CVEs |
| `build-package` | T/I | wheel build |
| `sphinx-build` | I/T | docs build (autodoc wired in `docs/conf.py`) |

**5 `allow_failure` jobs** are justified and **not gating** (SReVP <8>; RD-8 <5.7>): `docs-cov`
(docstr-coverage, informational), `complexity` (xenon, advisory), `sonarqube` (external service),
`integration-tests` (now passing, but Dask-gateway/S3 absent on the shell runner → non-blocking until a
K8s runner; AI-QR-02), and `deliver-image` (kaniko has no container runtime on the shell runner). The
`deps-sec` gate carries a **documented ignore-list** — PYSEC-2026-248/249 and CVE-2026-48817/48818
(eopf-transitive `starlette 1.0.1`, unfixable while `eopf == 2.8.1` is pinned; revisit on an eopf bump,
AI-QR-04).

### <6.4> Requirements verification — 100 requirements, 91 verified at QR, 9 deferred to AR

The SRS (RD-4 <5>) defines **100 requirements** across sixteen categories (REQ-F functional, REQ-P
performance, REQ-I interface, REQ-O operational, REQ-R resource, REQ-D design, REQ-S security, REQ-PORT
portability, REQ-Q quality, REQ-REL reliability, REQ-M maintainability, REQ-SAF safety, REQ-DEL delivery,
REQ-DAT data, REQ-HF human-factors, REQ-AD adaptation). All carry a verification method (T/A/I/R) and are
traced in the RTM (RD-11) with **bidirectional closure and no orphans**.

- **91 of 100 requirements are verified at QR** (85 Verified + 6 Verified with a tested `[impl]`
  fail-stop; Tier A in CI + Tier B locally + I/A/R static and review evidence), per the V&V Plan
  requirement→method→tier map (RD-8 <14>) and the RTM (RD-11); **9 are deferred to AR** (Tier-C
  numeric-budget verdict).
- **The 9 deferred requirements are the 5 performance/accuracy budgets REQ-P-01..05** — `RAD_ACC`
  radiometric accuracy, `GEO_CE90` + `BAND_COREG` geolocation/co-registration, `BOA_ACC` surface
  reflectance, `THRU_SCENE` throughput, `MEM_BUDGET` peak memory — **plus the 4 budget-coupled
  requirements REQ-F-COR-02, REQ-F-GEO-03, REQ-F-PAN-02 and REQ-Q-03** (RTM G-2). All nine are verified
  **by analysis/design and the algorithm V&V** at QR. Their **Tier-C numeric budget validation is
  WITHHELD at QR**: it requires the operator's **private real RAW + calibration data** (data policy, SSS
  RD-21 <5.1>), which is never present in public CI. The numeric budget closure is a **documented QR open
  item carried to AR**, where it is validated on operator data (AI-QR-01). **This is the single most
  important stated limitation of this QR.**

---

## <7> SPR/NCR status

Per the QR objective "check the status of all SPRs/NCRs" (SReVP <6>; success criterion <7>.2):

- **No SPR/NCR is open** against the QR baseline. The blocking CI gates are green, the unit and
  integration campaigns pass (the 2 xfailed are expected fail-stop verifications, not defects), and the
  one defect surfaced during integration (the `L2A` geolocation-grid drop, <6.2>) was **fixed and closed**
  in the baseline (d140599).
- **The six `[impl]` deferral items are recorded waivers, not defects.** Each is **fail-stop** by design,
  is traced in the RTM (RD-11) as a recorded waiver (G-1/G-6), and **the operational baseline never
  executes them** (the public/operational path uses the documented alternatives):

  | # | `[impl]` item | Algorithm | Disposition / operational alternative |
  |---|---|---|---|
  | 1 | `l0_decode.decode_source_packets` | ALG-L0-DEC | sensor-private on-wire source-packet decode/decompression; public path consumes the documented open-container sample layout |
  | 2 | `georeference.orbit_state` | ALG-GEO-ORBIT | ephemeris/orbit propagation; CDR-target (GPL TLE path dropped) |
  | 3 | `georeference.orthorectify` | ALG-GEO-ORTHO | rigorous collinearity / DEM line-of-sight (needs sensor-private viewing model), CDR-target; operational `L1C` uses GCP reference-image refinement; **2 xfail tests verify the fail-stop** |
  | 4 | `atmospheric.retrieve_atmospheric_parameters` | ALG-ATM-PAR | image-based AOT/water-vapour retrieval |
  | 5 | `atmospheric.resolve_rt_lut` | ALG-ATM-RT | radiative-transfer engine LUT build |
  | 6 | `atmospheric.classify_scene_ml` | ALG-ATM-SCM | ML scene-classifier refinement |

  Additionally, the pansharpen **component-substitution fusion methods** (brovey/gs/ihs/atrous) are
  deferred; only `simple_mean` is operational. These deferrals are by design, recorded, and do not
  constitute open problem reports.

---

## <8> RID disposition

The QR review group conducted an **internal adversarial review** of the QR data package (<5>) against the
SReVP QR checklist (RD-2 <6>/<7>), with independence supplied by the automated CI gates and the explicit
review checklists (SReVP <11>). RIDs were recorded as GitLab issues / MR comments per the SReVP RID form
(RD-2 <13>, `RID-QR-<nnn>`).

- **All RIDs raised at the QR board were dispositioned** (Accepted / Partially accepted / Rejected) with
  rationale per SReVP <13>.
- RIDs accepted with rework required **before AR** were **converted into the action items of <10>** and
  assigned as GitLab issues against the QR/AR milestone; editorial and document-gap RIDs were dispositioned
  to the same action set (SUITR/SUM completion, formal tagging).
- The **RID status metric** (opened / dispositioned / closed) is recorded in the QR milestone summary
  issue and satisfies success criteria SReVP <7>.2(c)/(d). No RID remains undispositioned; therefore no
  RID blocks the QR conclusion.

---

## <9> Exit-criteria assessment

Assessment of the four QR success (exit) criteria of the SReVP (RD-2 <6> QR / <7>.2), with a per-criterion
verdict.

| # | QR exit criterion (SReVP) | Evidence | Verdict |
|---|---|---|---|
| **(a)** | Software meets all specified requirements; V&V per the V&V plan completed successfully | 8/8 units implemented and CI-green; 248 test cases (244 passed + 2 expected xfail + 2 integration passed); Tier A V&V complete (<6.1>–<6.3>); 91/100 requirements verified at QR, 9 deferred to AR (the 5 REQ-P budgets + REQ-F-COR-02, REQ-F-GEO-03, REQ-F-PAN-02, REQ-Q-03) verified by analysis with numeric closure deferred | **Pass with action** (AI-QR-01) |
| **(b)** | All RB + interface requirements verified, incl. technical budgets and code-coverage gate | RTM (RD-11) bidirectional, no orphans; interface requirements (REQ-I, IRD RD-22) verified; **code-coverage gate green** (unit-tests job, ≥ 70 % new code, REQ-Q-02); **technical budgets (REQ-P-01..05) numeric closure withheld at QR** (private operator data), verified by analysis/algorithm-V&V | **Pass with action** (AI-QR-01) |
| **(c)** | SCI is a formal version under configuration control (Git tag / SCF / CIDL); SRelD/SRN released | SCI baseline under Git config control at **d140599**; **SCF (RD-16), CIDL (RD-15) and SRN/SRelD (RD-14) authored in this package**; **no Git tag exists yet** — the **v0.1.0-rc1** RC is stated by the SRN referenced to d140599, and the formal tag is the release action at the release decision (AR) | **Pass with action** (AI-QR-04) |
| **(d)** | Confirm test/RB-validation configuration; check SPR/NCR status; baseline validation spec vs RB; evaluate readiness for AR | Test/validation configuration frozen and identified (d140599 / pipeline 30730); **no SPR/NCR open** (<7>); the validation specification (V&V Plan RD-8 + SUITP RD-10) is baselined against the RB (SSS RD-21 + IRD RD-22); readiness to proceed to AR confirmed with the carried actions | **Pass** |

**Overall exit-criteria verdict: PASS WITH ACTIONS.** The qualification objectives are met for the
software item itself; the only material reservations are the **Tier-C numeric budget validation** (private
operator data, deferred to AR) and the **formal release tagging** — both carried as explicit AR actions,
neither affecting the Category-C qualification conclusion for the software item.

---

## <10> Action items carried to AR

| Id | Action | Origin | Owner | Target |
|---|---|---|---|---|
| **AI-QR-01** | Execute **Tier-C numeric budget validation** of REQ-P-01..05 (`RAD_ACC`, `GEO_CE90`, `BAND_COREG`, `BOA_ACC`, `THRU_SCENE`, `MEM_BUDGET`) on the operator's **private RAW + calibration data**; record pass/fail verdicts (private numbers withheld) in the SVR (RD-12) | <6.4>, criteria (a)/(b) | Project owner | AR |
| **AI-QR-02** | **Promote `integration-tests` to a blocking gate** on a Kubernetes / Dask-gateway runner (currently `allow_failure` because the shell runner has no container runtime / Dask gateway / S3) | <6.3>; RD-18 risk | Project owner | AR / runner availability |
| **AI-QR-03** | **Publish SUITR completion** (RD-13) and **complete the SUM** (RD-17, start → final at AR) | <5>, RID disposition | Project owner | AR |
| **AI-QR-04** | Close the open documentation/release gaps: finalise and issue the QR deliverables and **apply the formal Git tag** (`v0.1.0-rc1` → release) at the release decision; carry the `deps-sec` ignore-list (PYSEC-2026-248/249, CVE-2026-48817/48818) for **revisit on the next `eopf` bump** | criterion (c); <6.3> | Project owner | AR / release decision |

The six `[impl]` deferral items (<7>) are recorded waivers traced in the RTM (RD-11 G-1/G-6), not action
items; the CDR-target bodies (`orbit_state`, `orthorectify`) remain monitored against their algorithm
plans but are not on the operational qualification path.

---

## <11> Conclusion

The Software Qualification Review of `msi-processor` is concluded **SUCCESSFUL WITH REWORK — QR PASSED WITH
ACTIONS** (SReVP <7>.3). The software is implemented (8/8 processing units), integrated and CI-green on the
`main` baseline at **commit d140599** (pipeline **30730** = success); the test campaign of **248 cases**
(244 passed + 2 expected fail-stop xfails + 2 integration passed) and the **nine blocking CI verification
gates** demonstrate qualification against the technical specification; **91 of 100 requirements are
verified at QR** and **9 are deferred to AR** — the **five REQ-P performance/accuracy budgets** plus the
four budget-coupled **REQ-F-COR-02, REQ-F-GEO-03, REQ-F-PAN-02 and REQ-Q-03** — verified by analysis with
their **Tier-C numeric closure carried to AR** on operator data. There are **no open SPRs/NCRs** (the six `[impl]` items
are recorded fail-stop waivers, never executed operationally), and all QR-board **RIDs are dispositioned**.
All four SReVP QR exit criteria are met (criteria (a), (b), (c) with the carried actions of <10>;
criterion (d) met), and the anticipated **TRR/TRB** objectives are discharged.

**Authorisation:** the project is authorised to **proceed to the Acceptance Review (AR)**, subject to the
four action items of <10> — principally the Tier-C numeric budget validation on operator data and the
formal release tagging of the release candidate **v0.1.0-rc1**.

---

*End of QR Report. Authored per ECSS-E-ST-40C Rev.1 Annex P/Q and ECSS-M-ST-10-01C, tailored for Category
C, single-developer. QR objectives and success criteria are those of the SReVP (RD-2) <6>/<7>; verification
results are in the SVR (RD-12) and SUITR (RD-13); the maintained traceability matrix is the RTM (RD-11).*