# Software Release Note (SRN / SRelD)

| Field | Value |
|---|---|
| **Document** | SRN — Software Release Note (Software Release Document, SRelD) |
| **DRD ref** | ECSS-E-ST-40C Rev.1 — Software Release Document (SRelD); ECSS-M-ST-40C (configuration management); ECSS-Q-ST-80C Rev.2 (software delivery, acceptance & release) |
| **Container** | Released-software documentation set — `compliance/drd/` (source); published as `docs/srn.md` |
| **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 (Qualification Review) |
| **Status** | Issued at QR |

> This document is the **Software Release Note (SRN)** — the Software Release Document (SRelD) of
> ECSS-E-ST-40C Rev.1 — for the `msi-processor` software configuration item (SCI). It identifies the
> **release candidate** proposed for qualification (version **v0.1.0-rc1**, referenced to the QR
> configuration baseline commit **`d140599`**), states its **scope** (the `L0c`→`L2A` processing chain
> plus the optional pan-sharpen derivative, **8 of 8** processing units) and **contents** (the
> `msi_processor` package modules and the ECSS document set), records the **runtime dependencies** and
> the **build/install** procedure, enumerates the **known problems and limitations** carried into the
> release, summarises the **changelog** from SRR to QR, and reports the **verification status** at the
> release point. It is a delivery/configuration record, **not** a requirements (SRS, RD-4), design
> (SDD, RD-9) or verification-results (SVR, RD-12) document; those are cross-referenced rather than
> restated. 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 companion **Software Configuration File (SCF, RD-19)** and **Configuration Item
> Data List (CIDL, RD-20)** record the SCI inventory and the controlled-document list; this SRN is
> their change/known-problems counterpart for the released version.

**DRD clause coverage.** Where this SRN satisfies each SRelD DRD clause:

| SRelD clause | Topic | This document |
|---|---|---|
| SRelD <1> | Introduction | <1> |
| (house style) | Applicable / reference documents; terms | <2>, <3> |
| SRelD <2> | Software release overview (identification, version, contents, dependencies, build/install, verification status) | <4> (<4.1>..<4.6>) |
| SRelD <3.1> | Status of the software — evolution since previous version (changelog) | <5.1> |
| SRelD <3.2> | Status of the software — known problems or limitations; status of SPRs/SCRs/waivers | <5.2> |
| SRelD <4> | Advice for use of the software configuration item | <6> |
| SRelD <5> | On-going changes | <7> |

---

## <1> Introduction

**Purpose.** This SRN announces and characterises the **qualification release candidate** of
`msi-processor`, a generic high-resolution **pushbroom multispectral imager (MSI)** ground-segment
processor that transforms downlinked RAW **Level-0 (`L0c`)** data into calibrated, enhanced,
orthorectified and atmospherically corrected products up to **Level-2A (`L2A`)** on the ESA EOPF
**Common Processor Model (CPM)** runtime (`eopf == 2.8.1`, Zarr). It provides, per the SRelD DRD: the
**version** of the release and the SCI identity under configuration control; an **overview of the
contents** (code + documents); the **status of SPRs, SCRs and software waivers/deviations (SW&D)**;
the **known problems and limitations**; and **advice for use**.

**Objective.** To give the reviewer and the receiving party (the hosting EOPF ground segment) a
single, authoritative record of *what is being released at QR, in which configuration, with which
verification evidence, and subject to which limitations* — so that the QR exit criteria (SReVP,
RD-16: SCI under configuration control + released SRelD/SRN; SPR/NCR status checked; readiness to
proceed to AR) can be assessed against an explicit release statement.

**Content.** Clause <2> lists applicable and reference documents; <3> adds release-specific terms.
Clause <4> is the **software release overview**: release identification (<4.1>), scope (<4.2>),
contents (<4.3>), runtime dependencies and environment (<4.4>), build and installation (<4.5>) and
verification status at release (<4.6>). Clause <5> is the **status of the software**: the SRR→QR
changelog (<5.1>) and the known problems/limitations with SPR/NCR/waiver status (<5.2>). Clause <6>
gives advice for use; clause <7> records the on-going (planned) evolution toward AR.

**Reason for preparation.** `msi-processor` is an **integration and ECSS-productisation** effort
(RD-1 §1): mature processing algorithms (RD-14 prior work; RD-7 ATBD) are productised on the EOPF CPM
and verified, rather than researched anew. The lifecycle has passed **SRR, PDR and CDR** (all
baselined to `main`); **this package is the QR (Qualification Review)** data package, and this SRN is
its release statement. The SRN is the parent of the formal tagging/delivery action taken at the
**release decision** (AR), and the change/known-problems source for the SCF (RD-19) and CIDL (RD-20).

---

## <2> Applicable and reference documents

### Applicable documents (AD)

| Id | Document | Reference |
|---|---|---|
| AD-1 | ECSS Space engineering — Software (Software Release Document; Annex F SDD; Annex I/J V&V; Annex K SUITP; Annex M SVR) | ECSS-E-ST-40C Rev.1 (30 April 2025) |
| AD-2 | ECSS Space configuration and information management | ECSS-M-ST-40C Rev.1 |
| AD-3 | ECSS Space product assurance — Software (delivery, acceptance & release; product quality) | ECSS-Q-ST-80C Rev.2 |
| AD-4 | 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 System Specification (SSS) — `SYS-*` | `compliance/drd/sss-software-system-specification.md` |
| RD-3 | `msi-processor` Interface Requirements Document (IRD) — `REQ-IF-*` | `compliance/drd/ird-interface-requirements.md` |
| RD-4 | `msi-processor` Software Requirements Specification (SRS) — `REQ-*` | `compliance/drd/srs-software-requirements.md` |
| RD-5 | `msi-processor` Interface Control Document (ICD) — `ICD-IF-*` | `compliance/drd/icd-interface-control.md` |
| RD-6 | `msi-processor` Detailed Processing Model (DPM) — `DPM-M-*`, `DPM-PRM/ADF/BKP-*` | `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 merged) | `compliance/drd/vv-plan.md` |
| RD-9 | `msi-processor` Software Design Document (SDD, detailed/CDR) — `C-*`, `IF-*` | `compliance/drd/sdd-software-design.md` |
| RD-10 | `msi-processor` Software Reuse File (SRF) | `compliance/drd/srf-software-reuse-file.md` |
| RD-11 | `msi-processor` Traceability matrix (RTM; REQ↔design↔test) | `compliance/traceability/traceability-matrix.md` |
| RD-12 | `msi-processor` Software Verification Report (SVR, Annex M) — V&V results record | `compliance/drd/vv-report.md` (QR) |
| RD-13 | `msi-processor` Risk Register | `compliance/drd/risk-register.md` |
| RD-14 | Prior work — multispectral pushbroom preprocessing pipeline (`level_0`, `level_1`, `band_coreg`, `georeferencing_v1`, `pansharp`, `metrics_ips`) | see SRF (RD-10) |
| RD-15 | EOPF CPM API documentation (`EOProduct`, `EOProcessingUnit`, `EOZarrStore`, triggering) | EOPF CPM (`eopf == 2.8.1`) |
| RD-16 | `msi-processor` Software Review Plan (SReVP) | `compliance/drd/srevp-software-review-plan.md` |
| RD-17 | `msi-processor` Software Product Assurance Plan (SPAP) | `compliance/drd/spa-plan.md` |
| RD-18 | `msi-processor` SUITP (Annex K — unit/integration test specs & procedures) | `compliance/drd/suitp-unit-integration-test-plan.md` |
| RD-19 | `msi-processor` Software Configuration File (SCF) | `docs/scf.md` |
| RD-20 | `msi-processor` Configuration Item Data List (CIDL) | `docs/cidl.md` |
| RD-21 | `msi-processor` Software User Manual (SUM, start) | `docs/sum/` |
| RD-22 | `msi-processor` Software Installation Manual (SIM) | `docs/sim.md` |

---

## <3> Terms, definitions and abbreviated terms

The SDP §3, SSS <3>, SRS <3>, SDD <3> and V&V Plan <3> glossaries apply in full. Only terms specific
to this SRN and not defined there are added.

| Term / abbr. | Definition |
|---|---|
| SCI | Software Configuration Item — the released `msi-processor` software and its baselined documentation |
| SRN / SRelD | Software Release Note / Software Release Document (this document) |
| SCF | Software Configuration File (RD-19) — SCI inventory and composition |
| CIDL | Configuration Item Data List (RD-20) — the list of controlled documents for the SCI |
| RC | Release candidate — a version proposed for qualification, tagged only at the release decision |
| QR / AR | Qualification Review / Acceptance Review (the milestones this SRN spans) |
| SPR | Software Problem Report (a recorded defect/anomaly) |
| SCR | Software Change Request |
| SW&D | Software Waiver and Deviation (an approved departure from a requirement/gate) |
| NCR | Non-Conformance Report |
| `[impl]` | A design body whose finalisation is legitimately deferred to (or after) implementation; here, all `[impl]` items are **fail-stop** and not on the operational baseline (SDD RD-9; see <5.2.1>) |
| Tier A / B / C | V&V three-tier scheme (RD-8 §4): A = deterministic synthetic unit tests in public CI (blocking); B = local real-RAW integration (non-blocking/skipped in public CI); C = reference/validation-data numeric budgets (local only) |
| Budget parameter | A private per-profile numeric tolerance (`RAD_ACC`, `GEO_CE90`, `BAND_COREG`, `BOA_ACC`, `THRU_SCENE`, `MEM_BUDGET`) held in the calibration store (RD-4 SRS <5.1>) |

---

## <4> Software release overview

### <4.1> Release identification

| Item | Value |
|---|---|
| Software configuration item | `msi-processor` (`msi_processor` Python package) |
| Repository | `gitlab.eopf.copernicus.eu/ipf/msi-processor` |
| **Proposed release-candidate version** | **`v0.1.0-rc1`** (qualification release candidate) |
| **QR configuration baseline commit** | **`d140599`** (`main`) |
| Baseline pipeline | CI pipeline **30730** on `main` — **success** (see <4.6>) |
| Git tag | **none yet** — applied at the release decision (see tagging policy below) |
| Branch | `main` (the SCI is the full content of `main` at the baseline commit; SCF RD-19) |
| Licence | Apache-2.0 (`LICENSE`); `pyproject.toml` declares `Private :: Do Not Upload` (not for public package indices) |

**Version mechanism.** The package version is **resolved dynamically by the flit build backend**:
`pyproject.toml` declares `dynamic = ["version", "description"]` and builds with `flit_core`
(`build-system.requires = ["flit_core >=3.2,<4"]`). The released version string is bound to the
annotated **Git tag** created at the release decision.

**Tagging policy (release action deferred).** **No Git tag exists on the QR baseline yet.** Tagging
is the formal **release action**, performed at the **AR / release decision**, not at authoring time;
this SRN therefore records the *proposed* release-candidate identity **`v0.1.0-rc1`** referenced to
the QR configuration baseline commit **`d140599`**. At the release decision an annotated tag
`v0.1.0-rc1` is created on `d140599`, the SCF (RD-19) and CIDL (RD-20) are updated to cite the tag,
and the delivery jobs publish the tagged wheel and versioned documentation. This SRN must not be read
as evidence that a tag already exists.

### <4.2> Release scope

The release delivers the complete **`L0c`→`L2A`** ground-processing chain, plus the **optional**
post-`L2A` pan-sharpen derivative — **8 of 8** processing units implemented on `main` and CI-green.
Each unit follows the SDD pattern of a **pure, framework-independent algorithmic core** + a thin
**`EOProcessingUnit` wrapper** + a **CPM computing-model JSON** (RD-9; RD-4 REQ-D-03).

| # | Processing unit | Output level | Role |
|---|---|---|---|
| 1 | `l0_decode` | L1A | Level-0 (`L0c`) decode → L1A image arrays + `EOProduct` structure |
| 2 | `radiometric` | L1A | Dark/gain/offset correction; bad-pixel & saturation handling + QA flags |
| 3 | `enhancement` | L1B | **MTF compensation (mandatory, always applied)** + denoise (per profile) |
| 4 | `toa` | L1B | DN → TOA radiance/reflectance |
| 5 | `coregistration` | L1B→L1C | Inter-band co-registration (feature matching + homography) |
| 6 | `georeference` | L1C | Geolocation / cartographic referencing (GCP reference-image refinement path) |
| 7 | `atmospheric` | L2A | Atmospheric correction → surface (BOA) reflectance |
| 8 | `pansharpen` | post-`L2A` (optional) | MS+PAN fusion derivative (operational method: `simple_mean`) |

The chain is runnable end-to-end and at breakpoints/sub-chains (RD-4 REQ-F-ORC-01) via the CPM
computing-model and triggering payloads (RD-15). The operational baseline runs the documented,
public processing path; the deferred `[impl]` bodies are never executed by it (<5.2.1>).

### <4.3> Contents of the release

**(a) Code — the `msi_processor` package.**

| Subpackage / module | Contents |
|---|---|
| `msi_processor/computing/` | The 8 processing units (`l0_decode`, `radiometric`, `enhancement`, `toa`, `coregistration`, `georeference`, `atmospheric`, `pansharpen`), each providing `core.py` (pure core), `unit.py` (`EOProcessingUnit` wrapper), `models/` (CPM computing-model JSON) and `__init__.py` |
| `msi_processor/common/` | `types.py` (shared data types) and `metrics.py` (QA metrics — SNR/RMSE/PSNR/MSE/variance, productised from `metrics_ips`, RD-14) |
| `msi_processor/sensors/` | `profile.py` (the externalised, sensor-agnostic processing **profile** — REQ-D-07, REQ-AD-01) |
| `msi_processor/exceptions/` | `errors.py` and `warnings.py` (typed error/warning classes, fail-stop support) |
| `msi_processor/__init__.py` | Package root |

This realises the **21 design components (`C-*`)**, **11 DPM modules (`DPM-M-*`)** and **33
algorithms (`ALG-*`)** of the baselined design (RD-9 / RD-6 / RD-7), allocating the **100** SRS
requirements (RD-4).

**(b) Tests.** `tests/ut/` (unit — `computing/`, `common/`, `sensors/`) and `tests/it/computing/`
(integration — full-chain), executed per the SUITP (RD-18); results in <4.6>.

**(c) Documentation set (DRD deliverables of the SCI).** The baselined ECSS documents listed in the
CIDL (RD-20): SDP (RD-1), SSS (RD-2), IRD (RD-3), SRS (RD-4), ICD (RD-5), DPM (RD-6), ATBD (RD-7),
V&V Plan (RD-8), SDD (RD-9), SRF (RD-10), traceability matrix/RTM (RD-11), SVR (RD-12), Risk Register
(RD-13), SReVP (RD-16), SPAP (RD-17), SUITP (RD-18), and the QR delivery documents **SCF (RD-19),
CIDL (RD-20), SUM (start, RD-21), SIM (RD-22)** and **this SRN**. Sphinx autodoc is wired in
`docs/conf.py` and the documentation builds in CI (job `sphinx-build`, <4.6>).

**(d) Build / CI configuration.** `pyproject.toml`, `.gitlab-ci.yml`, `Dockerfile`, and the gate
configs (`.flake8`, `.mypy.ini`, `bandit.yml`, `.coveragerc`, `.hadolint.yml`,
`.pre-commit-config.yaml`).

### <4.4> Runtime dependencies and execution environment

**Runtime dependencies** (`pyproject.toml` `[project].dependencies`):

| Dependency | Constraint | Role |
|---|---|---|
| `eopf` | **`== 2.8.1`** (pinned) | ESA EOPF CPM runtime — `EOProduct`, `EOProcessingUnit`, `EOZarrStore`, triggering (RD-15); the pin matches the SDE `cpm-build-environment` image (REQ-R-03, REQ-M-03) |
| `opencv-python-headless` | `>= 4.8` | Feature matching / homography / warping for co-registration and pan-sharpen (ALG; SDD <5.4.6>); headless wheel (no display); ships PEP 561 stubs |
| `rasterio` | `>= 1.3` | GDAL/PROJ binding for the cartographic affine geotransform + reprojection in `georeference` (ALG-GEO-RESAMP; SDD <5.4.7>); also an `eopf` transitive dependency, declared explicitly as it is imported directly |

**Interpreter.** Python **`>= 3.11`** (`requires-python = ">=3.11"`; classified for CPython 3.11).
**Optional extras:** `cluster-plugin` (`eopf[cluster-plugin] >= 1.5.0`) and `tests`
(`eopf[tests] >= 1.5.0`).

**Operational environment.** The EOPF SDE container
(`registry.eopf.copernicus.eu/sde/cpm-build-environment`, `eopf == 2.8.1`, Python 3.11) is the
reference runtime; the same code runs unchanged on an x86-64 Linux workstation (CPU-only, no GPU;
REQ-R-01) against a POSIX filesystem or an S3-compatible object store (REQ-R-02). The public CI
runner is a **single Studio VM with a SHELL executor** (no container runtime, Dask gateway or S3;
`image:` directives are ignored), which is the reason for the non-blocking jobs of <5.2.3>.

### <4.5> Build and installation

The package builds to a **wheel via the flit backend** and installs with `pip`:

- **Build:** `python -m build` (or `flit build`) → a PEP 517 wheel (CI job `build-package`, green at
  the baseline). The version is taken from the Git tag at build time (<4.1>).
- **Install (operational):** `pip install .` inside the EOPF SDE environment (or `pip install
  msi_processor-<version>-py3-none-any.whl`), which pulls `eopf == 2.8.1`,
  `opencv-python-headless >= 4.8` and `rasterio >= 1.3`. A clean `pip install` is the acceptance
  installation check (RD-4 REQ-AD-05; V&V Plan VT-8). Detailed steps are in the SIM (RD-22).
- **Install (development):** `pip install .[tests]` for the test extra; `pre-commit install` for the
  local lint/format hooks.

The package is **not** published to a public index (`pyproject.toml` carries
`Private :: Do Not Upload`); delivery is via the EOPF Git repository and the SDE-internal
artefact/registry targets at the release decision.

### <4.6> Verification status at release

The QR baseline (`d140599`) is **CI-green**: **CI pipeline 30730** on `main` succeeded. The pipeline
ran **9 blocking verification gates, preceded by the blocking `validate-variables` precondition guard**,
all green, and **five** justified `allow_failure` (non-gating) jobs:

| Blocking gate (all green on pipeline 30730) | Verifies |
|---|---|
| `validate-variables` | CI variable/precondition validation |
| `linter` (flake8) | Style / lint conformance |
| `docker-linter` (hadolint) | Dockerfile lint |
| `formater` (black + isort) | Formatting / import order |
| `typing` (mypy) | Static type contracts |
| `unit-tests` (pytest `-m unit` + coverage, Cobertura) | Tier-A unit tests + coverage gate |
| `security` (bandit) | Python SAST |
| `deps-sec` (pip-audit, isolated venv) | Dependency CVE scan (accepted findings in <5.2.4>) |
| `build-package` | Wheel build |
| `sphinx-build` | Documentation build |

**Test results (authoritative; pytest-collected on `cpm_env`, `eopf 2.8.1` / Python 3.11):**

| Test set | Cases | Result |
|---|---|---|
| Unit (`tests/ut`) | **246** | **244 passed, 2 xfailed** |
| Integration (`tests/it/computing/test_full_chain.py`) | **2** | **2 passed** |
| **Total** | **248** | **246 passed, 2 xfailed** (from **238** test functions, some parametrised) |

Per-unit unit-test counts: `l0_decode` 22, `radiometric` 21, `enhancement` 35, `toa` 24,
`coregistration` 23, `georeference` 27, `atmospheric` 35, `pansharpen` 29, `common` (types + metrics)
15, `sensors` (profile) 7. The **2 xfailed** cases are in `tests/ut/computing/test_georeference_core.py`
and intentionally verify the `orthorectify` `[impl]` fail-stop (<5.2.1>). The **2 integration** cases
(full `L0c`→`L2A` chain and chain-with-pansharpen) wire all 8 units on one synthetic feature-rich
scene; they surfaced and fixed a real defect (the `AtmosphericUnit` was dropping the L1C geolocation
grid from `L2A`; fixed by conditions passthrough — see <5.1>).

The full V&V results record is the **SVR (RD-12)**; this SRN reports status only. The Tier-C numeric
performance-budget closure is **withheld at QR** and is a documented open item carried to AR
(<5.2.2>).

---

## <5> Status of the software

### <5.1> Evolution since previous version

This is the **first release candidate** of `msi-processor`; there is **no previous released
version**. "Evolution" is therefore the milestone changelog from project start (SRR) to this QR
baseline. All of SRR, PDR and CDR were baselined to `main`.

| Milestone | Baseline established | Summary of evolution |
|---|---|---|
| **SRR** | Requirements & system baseline | SSS (`SYS-*`, RD-2), IRD (`REQ-IF-*`, RD-3) and SRS (`REQ-*`, **100** requirements, RD-4) issued; public-code / private-data policy fixed (SRS <5.1>/<5.8>) |
| **PDR** | Preliminary design + V&V approach | Architectural SDD, ICD (RD-5), DPM (RD-6), ATBD (RD-7); V&V Plan (RD-8) with the three-tier scheme baselined before detailed design |
| **CDR** | Detailed design + test contract | Detailed SDD (**21 `C-*`** components, internal interfaces, RD-9); SUITP (Annex K, RD-18); traceability matrix/RTM (RD-11) with bidirectional closure and **no orphans**; the 6 `[impl]` bodies marked for post-CDR finalisation |
| **post-CDR (implementation)** | Code on `main` | **8/8** processing units implemented (pure core + `EOProcessingUnit` wrapper + computing-model JSON each), plus `common` (types + QA metrics), the sensor `profile`, and typed exceptions; CI gates green per merge request |
| **QR (this release)** | Qualification | Full Tier-A suite green (**246** UT: 244 passed / 2 xfail) **+ 2** integration passed = **248**; CI pipeline **30730** green on `d140599`; QR data package authored (SVR, SUITR, this SRN, SUM start, CIDL, SCF, CI evidence) |

**Notable code changes consolidated into this baseline (from the `main` history):**

- **`l0_decode` unit added** (the Level-0→L1A decode unit, `C-PU-L0`), **closing the `L0c`→`L2A`
  chain at 8/8**.
- **End-to-end integration chain** (`L0c`→`L2A`, with the pan-sharpen variant) added; it surfaced and
  fixed a real defect — the `AtmosphericUnit` was **dropping the L1C geolocation grid** from the
  `L2A` product; corrected by a conditions passthrough. This is the merge that establishes the QR
  baseline (`d140599`).

### <5.2> Known problems and limitations

This release carries the following known limitations. **None** is an unresolved operational defect on
the public processing path; each is a *scoped, recorded* limitation traced in the RTM (RD-11) and/or
documented in the V&V Plan (RD-8) and SVR (RD-12).

#### <5.2.1> Deferred algorithm bodies (`[impl]`, fail-stop)

Six algorithm bodies are deferred (their finalisation requires sensor-private models/data or is a
CDR/AR-target). **All are fail-stop** (they raise rather than emit a wrong product), **all carry
recorded waivers (SW&D) traced in the RTM at G-1/G-6**, and the **operational baseline never executes
them** — the public path uses the documented alternative in each case.

| # | Unit · body | Algorithm | Reason deferred / operational alternative |
|---|---|---|---|
| 1 | `l0_decode` · `decode_source_packets` | ALG-L0-DEC | Sensor-private on-wire source-packet decode/decompression; the 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 the sensor-private viewing model (CDR-target); the operational L1C path uses **GCP reference-image refinement** instead. **2 xfail tests** verify this 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 |

In addition, the **pan-sharpen component-substitution fusion methods** (`brovey`, `gs`, `ihs`,
`atrous`) are deferred; only **`simple_mean`** is operational.

#### <5.2.2> Withheld Tier-C performance-budget validation (QR open item → AR)

The **numeric** performance-budget closure for the five performance requirements **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) is **withheld at QR**. The
Tier-C numeric validation requires the **operator's private real RAW + calibration data** (data
policy SSS <5.1>), which is never present in the public CI. At QR these requirements are verified by
**analysis/design and the algorithm V&V**; the numeric budget closure is a **documented QR OPEN ITEM
carried to AR**, where it is validated on operator data at the Acceptance Review. This is the single
most important QR limitation and is stated honestly here and in the SVR (RD-12).

#### <5.2.3> Non-blocking (`allow_failure`) CI jobs

The following CI jobs are **`allow_failure` (non-gating)** on the shell-executor runner; their status
does not gate the release. The justification is the runner's lack of a container runtime, Dask
gateway and S3 (a single Studio VM, SHELL executor).

| Job | Why non-blocking |
|---|---|
| `docs-cov` (docstr-coverage) | Informational docstring-coverage metric |
| `complexity` (xenon) | Advisory cyclomatic-complexity bound |
| `sonarqube` | External service (quality-gate adjudication) |
| `integration-tests` | Now **passing**, but Dask-gateway / S3 are absent on the shell runner; **non-blocking until a Kubernetes runner** lands |
| `deliver-image` (kaniko) | kaniko needs a container runtime that the shell runner lacks |

The **integration tests pass** at the baseline (<4.6>); they are non-gating only because the runner
cannot guarantee the real-runtime services, not because of a test failure. They become blocking once
a K8s runner replaces the shell executor (tracked in the Risk Register, RD-13).

#### <5.2.4> Dependency-security accepted findings (`deps-sec` ignore-list)

The `deps-sec` (pip-audit) gate is green with a documented, justified ignore-list:
**PYSEC-2026-248 / PYSEC-2026-249** and **CVE-2026-48817 / CVE-2026-48818**. These are
**`eopf`-transitive** advisories against **starlette 1.0.1**; they are **unfixable while
`eopf == 2.8.1` is pinned** (the pin is a hard runtime constraint, REQ-R-03/REQ-M-03). They are
**revisited on the next `eopf` bump**, which re-runs the full V&V before re-baselining (REQ-M-03).

#### <5.2.5> SPR / SCR / NCR / waiver status

| Item | Status at QR |
|---|---|
| Open SPRs (unresolved problem reports) on the operational path | **None** — the one defect found by the integration tests (L2A geolocation drop) was fixed in this baseline (<5.1>) |
| Open SCRs (change requests) blocking release | None |
| Approved SW&D (waivers/deviations) | The `[impl]` fail-stop deferrals of <5.2.1> are recorded waivers traced in the RTM (RD-11) at G-1/G-6; the Tier-C budget withholding (<5.2.2>) is a recorded open item; the `deps-sec` ignores (<5.2.4>) are recorded justifications |
| NCR status | No open non-conformances against the released configuration |

SPR/NCR status is checked as part of the QR exit criteria (SReVP, RD-16); the controlled record is
the GitLab issue tracker and the SVR (RD-12).

---

## <6> Advice for use of the software configuration item

- **Run inside the EOPF SDE / `eopf == 2.8.1` environment.** The `eopf` pin is exact; do not mix with
  another `eopf` version. Use `opencv-python-headless` (display-free) and the declared `rasterio`.
- **Operational scope.** Use the documented public processing path (the open-container `L0c` sample
  layout → `L2A`). Do **not** invoke the deferred `[impl]` bodies of <5.2.1>: they are fail-stop and
  will raise. For geolocation, the operational path is **GCP reference-image refinement**, not the
  deferred rigorous orthorectification. For pan-sharpen, use **`simple_mean`** only.
- **Accuracy budgets are not numerically qualified at QR.** Treat product accuracy/throughput/memory
  figures as **provisional** until the AR Tier-C validation on operator data (<5.2.2>). Numeric
  budgets and calibration coefficients are **private** and are supplied via the sensor profile / ADFs,
  never hard-coded.
- **Data policy.** Never commit private raw `L0`, calibration coefficients or budget thresholds; the
  CI scan enforces this (REQ-S-01/05). The released code is public; the data are not.
- **Distributed / S3 execution** (Dask-gateway, object store) is exercised locally only at QR; at
  scale it is a system-level (ground-segment) concern (V&V Plan <13>).
- **This is a release candidate (`-rc1`).** It is intended for qualification assessment and AR
  validation, not yet a final operational acceptance baseline.

---

## <7> On-going changes

Planned evolution from this QR release candidate toward AR / a final release:

- **Promote the tag** `v0.1.0-rc1` on `d140599` at the release decision, and update SCF (RD-19) /
  CIDL (RD-20) to cite it (<4.1>).
- **Close the Tier-C performance budgets** (REQ-P-01..05) on operator private RAW + calibration data
  at AR; fold the numeric verdicts (pass/fail only, private numbers withheld) into the SVR (RD-12)
  (<5.2.2>).
- **Promote `integration-tests` to blocking** once an EOPF SDE **Kubernetes** runner replaces the
  shell executor (also enables `deliver-image`/kaniko, real Dask-gateway/S3 paths) (<5.2.3>;
  Risk Register RD-13).
- **Re-evaluate the `deps-sec` ignore-list** at the next `eopf` bump; an `eopf` change triggers a full
  V&V re-run before re-baseline (REQ-M-03) (<5.2.4>).
- **`[impl]` bodies** (<5.2.1>) remain deferred targets; any future activation re-opens the relevant
  ALG-* verification and the affected REQ-* in the RTM (RD-11).
- **Complete the SUM** (RD-21) from its current start state toward full operational coverage.

Planned changes are tracked as GitLab issues against the `ipf/msi-processor` project.

---

*End of Software Release Note. Authored per ECSS-E-ST-40C Rev.1 (Software Release Document / SRelD),
ECSS-M-ST-40C (configuration management) and ECSS-Q-ST-80C Rev.2 (delivery & release), tailored for
Category C, single-developer. The proposed release candidate is `v0.1.0-rc1` at QR baseline commit
`d140599` (CI pipeline 30730 green; 248 tests — 246 passed, 2 xfail). The Git tag is applied at the
release decision. The verification-results record is the SVR (RD-12); the SCI inventory is the SCF
(RD-19) and CIDL (RD-20); the maintained traceability matrix is RD-11.*