# Software Configuration File (SCF)

| Field | Value |
|---|---|
| **Document** | SCF — Software Configuration File (as-built configuration record of the SCI) |
| **DRD ref** | ECSS-E-ST-40C Rev.1 (software configuration management activities; Software Configuration File / as-built record); ECSS-M-ST-40C Rev.1 (configuration and information management — CIDL/SCF); ECSS-Q-ST-80C Rev.2 (software configuration management) |
| **Container** | Configuration management records — `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** | QR |
| **Status** | Issued at QR |

> This Software Configuration File records the **as-built configuration baseline** of the single
> Software Configuration Item (SCI) `msi_processor` at the **Qualification Review (QR)**. It is the
> physical-configuration companion of the Configuration Item Data List (RD-17, CIDL) and the Software
> Release Note (RD-16, SRN/SRelD): the CIDL enumerates *which* items make up the SCI, the SRN declares
> the *released* version, and this SCF freezes the *exact build, runtime environment, verification
> toolchain and CI execution environment* against which the QR verification evidence (RD-11, SVR) was
> produced — so that the baseline is reconstructible and the validation configuration is confirmed
> (SReVP RD-12 QR exit criterion (c)/(d)). It is **descriptive, not normative**: it states what is, not
> what shall be; the binding requirements live in the SRS (RD-4) and the development/CM rules in the SDP
> (RD-1) and SPAP (RD-13). The QR configuration baseline is `main` at commit **d140599** (pipeline
> **30730** = success). No Git tag exists yet; the release action that stamps the tag and uploads the
> package is taken at the release decision (see <4.3>, <9.3>). 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>).

**DRD clause coverage.** Where this SCF records each expected configuration-management / as-built
content element (ECSS-E-ST-40C Rev.1 CM; ECSS-M-ST-40C Rev.1 SCF/CIDL):

| Expected content | Topic | This document |
|---|---|---|
| SCI identification | Name, repository, criticality | <4.1> |
| Configuration baseline | Commit, branch, pipeline of record | <4.2> |
| Version identification | Dynamic version mechanism; QR release candidate | <4.3> |
| As-built build system | Backend, build invocation, packaging standards | <5.1> |
| As-built source structure | Package layout; processing units | <5.2> |
| Built artefacts | Wheel, documentation package, container image | <5.3> |
| Pinned runtime environment | Python, declared dependencies, resolved closure | <6.1>..<6.3> |
| Dependency-CVE exceptions | Justified `pip-audit` ignore-list | <6.4> |
| Verification toolchain configuration | Tool inventory + pinned configs; pre-commit | <7.1>, <7.2> |
| CI/CD execution environment | CI image, runner, gate configuration | <8.1>, <8.2> |
| Configuration control & status accounting | Control procedure; baseline accounting; CIDL/SRN link | <9.1>..<9.3> |
| Open configuration items | QR deferrals and open items carried to AR | <10> |

---

## <1> Introduction

**Purpose.** This SCF identifies and freezes the as-built configuration of the SCI `msi_processor` at
QR. It captures the configuration data needed to (a) reproduce the exact build, (b) re-create the
pinned runtime and verification environment, and (c) confirm that the configuration under which the
QR verification/validation campaign (RD-8 V&V Plan, RD-10 SUITP, RD-11 SVR) was run is the configuration
being qualified. It thereby supports SReVP RD-12 QR exit criteria (c) "the SCI is a formal version
under configuration control" and (d) "confirm test/RB-validation configuration".

**Objective.** Per the ECSS configuration-management process (ECSS-E-ST-40C Rev.1; ECSS-M-ST-40C
Rev.1) and ECSS-Q-ST-80C Rev.2, the SCF records: the SCI identification and naming (<4>); the
as-built physical configuration — build system, source structure and produced artefacts (<5>); the
pinned runtime environment, eopf closure and dependency-CVE exception list (<6>); the verification
toolchain and its pinned configurations (<7>); the CI/CD execution environment, runner and gate
configuration (<8>); the configuration-control and status-accounting record for this baseline (<9>);
and the open configuration items deferred to AR (<10>).

**Content.** Clauses <2>/<3> give the document references and terms. Clause <4> is the SCI
identification and the configuration baseline of record. Clauses <5>–<8> are the as-built record
proper (build, runtime, toolchain, CI). Clause <9> is the configuration control/status-accounting
section and the relationship to the CIDL (RD-17) and SRN (RD-16). Clause <10> lists the open items.

**Reason for preparation.** The SCF is a QR data-package deliverable (RD-1 SDP §5.2; SReVP RD-12). It
is produced light (Category C, single-developer) but completely, because the configuration baseline is
the object on which the qualification verdict is taken. All values in this file are **read from the
baselined source tree at commit d140599** (`pyproject.toml`, `.gitlab-ci.yml`, `.flake8`, `.mypy.ini`,
`bandit.yml`, `.hadolint.yml`, `.pre-commit-config.yaml`, `docs/conf.py`, `Dockerfile`), not asserted
from memory.

---

## <2> Applicable and reference documents

### Applicable documents (AD)

| Id | Document | Reference |
|---|---|---|
| AD-1 | ECSS Space engineering — Software (software configuration management activities; SCF / as-built record) | ECSS-E-ST-40C Rev.1 (30 April 2025) |
| AD-2 | ECSS Configuration and information management (configuration management; CIDL / SCF concept) | ECSS-M-ST-40C Rev.1 |
| AD-3 | ECSS Space product assurance — Software (software configuration management requirements) | ECSS-Q-ST-80C Rev.2 |
| AD-4 | EOPF CPM — Product Structure & Format Definition / data model and runtime | EOPF CPM docs (`eopf == 2.8.1`) |
| AD-5 | Python packaging standards — PEP 517 (build-backend interface), PEP 518/PEP 621 (build-system & project metadata) | python.org PEPs |

### 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) | `compliance/drd/sss-software-system-specification.md` |
| RD-3 | `msi-processor` Interface Requirements Document (IRD) | `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) | `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) | `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 (unit/integration test specifications & procedures) | `compliance/drd/suitp-unit-integration-test-plan.md` |
| RD-11 | `msi-processor` Software Verification Report (SVR) | `compliance/drd/vv-report.md` (QR) |
| RD-12 | `msi-processor` Software Review Plan (SReVP) | `compliance/drd/srevp-software-review-plan.md` |
| RD-13 | `msi-processor` Software Product Assurance Plan (SPAP) | `compliance/drd/spa-plan.md` |
| RD-14 | `msi-processor` Software Reuse File (SRF) | `compliance/drd/srf-software-reuse-file.md` |
| RD-15 | `msi-processor` Requirements Traceability Matrix (RTM) | `compliance/traceability/traceability-matrix.md` |
| RD-16 | `msi-processor` Software Release Note (SRN / SRelD) | `docs/srn.md` + GitLab Releases |
| RD-17 | `msi-processor` Configuration Item Data List (CIDL) | `docs/cidl.md` |
| RD-18 | `msi-processor` Risk Register | `compliance/drd/risk-register.md` |

---

## <3> Terms, definitions and abbreviated terms

The SDP §3, SSS <3> and SRS <3> glossaries apply in full. Only terms specific to configuration
management are listed.

| Term / abbr. | Definition |
|---|---|
| SCI | Software Configuration Item — the single deliverable software item `msi_processor` |
| SCF | Software Configuration File — this document; the as-built physical-configuration record |
| CIDL | Configuration Item Data List — the enumeration of the items constituting the SCI (RD-17) |
| SRN / SRelD | Software Release Note / Software Release Document — declares the released version (RD-16) |
| Configuration baseline | A formally identified, frozen state of the SCI (here: `main` @ d140599) |
| Baseline of record | The commit + CI pipeline whose evidence underwrites the QR verdict (d140599 / pipeline 30730) |
| Build backend | The PEP 517 backend that turns the source tree into a distribution (here: `flit_core`) |
| Resolved closure | The full transitive set of installed dependencies pinned by the SDE build image |
| Gate (blocking) | A CI job whose failure fails the pipeline (no `allow_failure`) |
| `allow_failure` job | A CI job whose failure is recorded but does not gate the pipeline (justified, non-gating) |
| SDE | EOPF Software Development Environment (Studio VM; `cpm-build-environment` image) |
| QR / AR | Qualification Review / Acceptance Review |

---

## <4> Software Configuration Item identification

### <4.1> SCI identity and naming

| Attribute | Value |
|---|---|
| SCI name (distribution) | `msi-processor` |
| Python import package | `msi_processor` |
| Repository | `gitlab.eopf.copernicus.eu/ipf/msi-processor` (GitLab group `ipf`) |
| Authors / vendor | `AstroCan17` / ESA (`pyproject.toml`, Dockerfile OCI `vendor` label) |
| Licence | Apache-2.0 (`LICENSE`; `pyproject.toml` `license = {file = "LICENSE"}`) |
| Software criticality | Category C (ECSS-Q-ST-80C Rev.2 / ECSS-E-ST-40C Annex R) |
| Distribution policy | `Private :: Do Not Upload` classifier; published only to the project's GitLab package registry (not public PyPI) |
| `requires-python` | `>= 3.11` |

The SCI is a **single software item** (one Python distribution producing one importable package). The
distribution name uses the hyphen form (`msi-processor`) and the import package the underscore form
(`msi_processor`); both denote the same SCI.

### <4.2> Configuration baseline of record

| Attribute | Value |
|---|---|
| Baseline branch | `main` |
| Baseline commit (short) | `d140599` |
| Baseline commit (full SHA-1) | `d140599293ac083dc3da04e63e645da54b8f0b5b` |
| Baseline commit subject | `Merge branch 'test/integration-chain' into 'main'` |
| CI pipeline of record | `30730` — **success** |
| VCS | Git on GitLab; changes to `main` only via reviewed Merge Requests (SPAP RD-13 §6.5) |

This is the configuration baselined at QR. The QR verification evidence (RD-11 SVR), the V&V campaign
(RD-8/RD-10) and all numbers in this SCF refer to this commit and this pipeline.

### <4.3> Version identification and QR release candidate

The distribution version is **dynamic** (`pyproject.toml` `dynamic = ["version", "description"]`,
`flit_core` backend): `flit_core` resolves the version and summary from the package module
`msi_processor/__init__.py` at build time. The as-built tree at d140599 carries the template default
`__version__ = "0.0.1"` in that module.

The **proposed QR release-candidate version is `v0.1.0-rc1`**, referenced to baseline commit d140599.
Per the release strategy (RD-1 SDP; RD-16 SRN), creating the Git tag and uploading the package is the
**release action taken at the release decision** (AR / release gate), not at QR authoring: **no Git
tag exists yet** at QR. The SRN (RD-16) states the release candidate and the baseline commit; the SCF
records the as-built version mechanism and the proposed RC. When the tag is created, the
`deliver-package` and `upload-documentation`/`pages` jobs (tag-gated, <8.2>) publish the wheel and the
versioned documentation, and `__version__` is set to the release value as part of that action.

---

## <5> As-built physical configuration

### <5.1> Build system (PEP 517)

| Attribute | Value (`pyproject.toml`) |
|---|---|
| Build backend | `flit_core.buildapi` |
| Build-system requires | `flit_core >= 3.2, < 4` |
| Metadata standard | PEP 621 (`[project]` table); PEP 517 build interface |
| Dynamic fields | `version`, `description` (resolved from `msi_processor.__init__`) |
| Wheel build (CI `build-package`) | `pip wheel -w dist --no-deps .` |
| Tag-gated upload (CI `deliver-package`) | `twine upload` to the project GitLab PyPI registry (`rules: if $CI_COMMIT_TAG`) |

The build is dependency-free at wheel time (`--no-deps`); the runtime closure (<6>) is resolved at
install time against the pinned `eopf` stack.

### <5.2> As-built source structure

The SCI source tree (`msi_processor/`) at d140599:

| Path | Role |
|---|---|
| `msi_processor/__init__.py` | Package root; carries `__version__` (dynamic-version source) |
| `msi_processor/common/types.py`, `common/metrics.py` | Shared types and the QA-metrics module (SNR/RMSE/PSNR/MSE/variance) |
| `msi_processor/sensors/profile.py` | Sensor-profile model (sensor-agnostic externalisation) |
| `msi_processor/exceptions/` | Specific error/warning classes |
| `msi_processor/computing/<unit>/` | The eight processing units (pure core + `EOProcessingUnit` wrapper + computing-model JSON) |
| `tests/ut/`, `tests/it/` | Unit (Tier A) and integration (Tier B) test suites |

The eight processing units and their output levels (RD-9 SDD, RD-6 DPM):

| Unit (`computing/<unit>`) | Level | Note |
|---|---|---|
| `l0_decode` | L1A | Level-0 → L1A decode |
| `radiometric` | L1A | Radiometric correction |
| `enhancement` | L1B | MTF compensation mandatory (always applied) |
| `toa` | L1B | TOA radiance/reflectance |
| `coregistration` | L1B → L1C | Inter-band co-registration |
| `georeference` | L1C | Geolocation / geocoding |
| `atmospheric` | L2A | Surface-reflectance retrieval |
| `pansharpen` | post-L2A | Optional derivative (`simple_mean` operational) |

### <5.3> Built artefacts

| Artefact | Produced by | Notes |
|---|---|---|
| Python wheel | `build-package` (`pip wheel`) | Blocking gate; tag-gated upload to GitLab PyPI registry by `deliver-package` |
| Documentation package | `sphinx-build` → `upload-documentation` → `pages` | `msi-processor-docs.tar.gz`; Sphinx autodoc; versioned via GitLab Pages (main/tag only) |
| Container image | `Dockerfile` (multi-stage), built by `deliver-image` (kaniko) | Build stage `python:3.11.7-bullseye`; runtime base `registry.eopf.copernicus.eu/sde/dask-container-images/dask-scheduler-worker:latest`; OCI labels carry `revision = $CI_COMMIT_SHA`. **Non-blocking** on the shell runner (no container runtime; see <8>) |

The image installs the SCI with the `cluster-plugin` extra (`pip install .[cluster-plugin]`) and is the
Dask runtime for distributed execution. The wheel is the primary deliverable; the image and docs are
auxiliary delivery artefacts.

---

## <6> Pinned runtime environment configuration

### <6.1> Python runtime

| Attribute | Value |
|---|---|
| Language | Python, `requires-python >= 3.11`; target/classifier 3.11 (CPython) |
| Build-stage interpreter (Docker) | `python:3.11.7-bullseye` |
| Tool target version | `black` `target-version = py311`; `mypy` `python_version = 3.11`; SonarQube `sonar.python.version = 3.11` |

### <6.2> Declared runtime dependencies

Declared in `pyproject.toml` `[project].dependencies`:

| Dependency | Pin / constraint | Reason (as documented in `pyproject.toml`) |
|---|---|---|
| `eopf` | `== 2.8.1` | **Hard pin** to the EOPF CPM version in the SDE `cpm-build-environment` image (same pin as the sibling `eo-data-embedding` project) |
| `opencv-python-headless` | `>= 4.8` | Genuine runtime dependency of coregistration / pan-sharpening (SIFT/FLANN/RANSAC/`warpPerspective`); headless wheel (no display on CI/target); ships PEP 561 stubs so `mypy` resolves `cv2` natively |
| `rasterio` | `>= 1.3` | GDAL/PROJ binding for the georeference affine geotransform + reprojection (`ALG-GEO-RESAMP`); already an `eopf` transitive, declared explicitly because imported directly; no PEP 561 stubs (see `.mypy.ini` overrides) |

Optional-dependency groups (all sourced from the matching `eopf[...] >= 1.5.0` extra, so the tool
versions track the pinned CPM stack): `cluster-plugin`, `tests`, `linter`, `typing`, `formatter`,
`security`, `notebook`, `doc` (+ `sphinxcontrib-mermaid`), `complexity`, `doc-cov`, `dev`.

### <6.3> Resolved dependency closure and SDE image

The runtime closure is **resolved and pinned by the SDE build image**
`registry.eopf.copernicus.eu/sde/cpm-build-environment:latest`, which ships the `eopf == 2.8.1` CPM
stack. In CI, the `security` job records the resolved closure as an artefact
(`pip freeze > requirements.txt`), and `deps-sec` re-resolves the project's own closure in an isolated
virtual environment (`.audit-venv`) and freezes it (`audit-requirements.txt`, excluding the
first-party `msi-processor`) as the CVE-scan target. The closure is therefore an externally controlled
configuration item: it is fixed for as long as `eopf == 2.8.1` is pinned, and is only allowed to change
through a deliberate eopf bump (REQ-M-03), which re-runs the full V&V before re-baselining (RD-8 §<5.6>).

### <6.4> Dependency-CVE exception list (justified)

`deps-sec` runs `pip-audit` against the resolved closure with a documented ignore-list. These are
**transitive** vulnerabilities introduced via the pinned `eopf == 2.8.1` stack (transitive
`starlette 1.0.1`), currently **unfixable without diverging from the SDE build image** (fix is
`starlette >= 1.1.0`):

| Ignored advisory | Component | Status |
|---|---|---|
| `PYSEC-2026-248` | `starlette 1.0.1` (eopf-transitive) | Accepted exception; revisit on eopf bump |
| `PYSEC-2026-249` | `starlette 1.0.1` (eopf-transitive) | Accepted exception; revisit on eopf bump |
| `CVE-2026-48817` | `starlette 1.0.1` (eopf-transitive) | Accepted exception; revisit on eopf bump |
| `CVE-2026-48818` | `starlette 1.0.1` (eopf-transitive) | Accepted exception; revisit on eopf bump |

The ignore-list is encoded in `.gitlab-ci.yml` (`deps-sec`: `--ignore-vuln PYSEC-2026-248 …`) with an
inline rationale and an explicit "revisit whenever the eopf pin is raised" condition. Any other HIGH/
CRITICAL finding fails the (blocking) `deps-sec` gate.

---

## <7> Verification toolchain configuration

### <7.1> Tool inventory and pinned configurations

The verification toolchain runs on the SDE `cpm-build-environment` image via the shell runner (<8>).
Tools and their as-built configuration files at d140599:

| Tool | Role | Configuration (as-built) |
|---|---|---|
| `pytest` + `coverage` | Unit tests (`-m unit`) + Cobertura/JUnit reports | `[tool.pytest.ini_options]` markers `unit`, `integration`, `need_files`; coverage → `coverage.xml`, JUnit → `TEST-pytests.xml` |
| `flake8` | Style/lint | `.flake8`: `max-line-length = 120`; `per-file-ignores` `__init__.py: F401` |
| `black` | Formatting | `[tool.black]`: `line-length = 120`, `target-version = ['py311']` (CI runs `--check --diff`) |
| `isort` | Import ordering | `[tool.isort]`: `profile = "black"` (CI runs `--check --diff`) |
| `mypy` | Static typing | `.mypy.ini`: `python_version = 3.11`; strict block for `msi_processor.*` (`disallow_untyped_defs`, `disallow_incomplete_defs`, `disallow_any_generics`, `no_implicit_reexport`, …); `ignore_missing_imports` for `fsspec`, `zarr.*`, `jinja2.*`, `rasterio`/`rasterio.*`, `affine` |
| `bandit` | SAST | `bandit.yml`: `exclude_dirs: tests/*.py`; `skips: ['B314','B405','B320','B410']` |
| `pip-audit` | Dependency CVE scan | Isolated `.audit-venv`; ignore-list per <6.4> (replaces the prior no-op `trivy` job on the shell runner) |
| `xenon` | Cyclomatic-complexity bound | `--max-average B --max-modules C --max-absolute D` (advisory) |
| `hadolint` | Dockerfile lint | Binary v`2.12.0` fetched in-job; `.hadolint.yml`: `failure-threshold: warning`, override `info` `DL3007` |
| `docstr-coverage` | Docstring density | `-F 30` (≥ 30 %), advisory |
| `sphinx` | Docs build (autodoc) | `docs/conf.py`: `sphinx.ext.autodoc`, `sphinx_autodoc_typehints`, `sphinxcontrib-mermaid` (`mermaid_version = 10.9.1`); `release` patched from branch/tag at build |
| SonarQube | Quality-gate adjudication | `sonar.python.version = 3.11`; ingests flake8/bandit/xunit/coverage reports (advisory) |

Test-suite size of the as-built configuration (authoritative pass/fail is RD-11 SVR): **248 test
cases** — 246 unit (244 passed, 2 xfailed) + 2 integration (2 passed) — from 238 test functions. The
2 xfails are in `tests/ut/computing/test_georeference_core.py` and intentionally verify the
`orthorectify` fail-stop (see <10>).

### <7.2> Pre-commit hook pinning (`.pre-commit-config.yaml`)

Local shift-left hooks are version-pinned so developer and CI checks agree:

| Hook repo | Pinned rev |
|---|---|
| `pre-commit/pre-commit-hooks` | `v4.3.0` |
| `commitizen-tools/commitizen` (commit-msg) | `v2.20.4` |
| `psf/black` | `24.3.0` |
| `PyCQA/bandit` (config `bandit.yml`) | `1.7.5` |
| `PyCQA/flake8` | `6.0.0` |
| `PyCQA/isort` | `5.12.0` |
| `asottile/add-trailing-comma` | `v2.2.3` |

`default_language_version.python = python3.11`.

---

## <8> CI/CD execution environment

### <8.1> CI image and runner

| Attribute | Value (`.gitlab-ci.yml`) |
|---|---|
| Declared CI image | `registry.eopf.copernicus.eu/sde/cpm-build-environment:latest` (`default.image`) |
| Registered runner | A **single Studio VM with a SHELL executor** |
| Consequence | The runner **ignores `image:` directives**; jobs run directly in the SDE shell environment. Jobs needing a container runtime, Dask gateway or S3 cannot run here (see `allow_failure` jobs in <8.2>). The `docker-linter` job fetches the `hadolint` binary in-job for this reason; `deps-sec` replaced the image-dependent `trivy` job |

### <8.2> Pipeline gate configuration

**Blocking verification, build and documentation gates (nine), all green on pipeline 30730**, preceded
by the `validate-variables` pipeline-entry guard (also blocking):

| Job | Stage | Method / tool |
|---|---|---|
| `validate-variables` | unit tests | Pipeline-entry guard: required CI variables present (SQ + Dask-gateway + JupyterHub token) |
| `linter` | unit tests | `flake8` (blocking) |
| `docker-linter` | unit tests | `hadolint` v2.12.0 (blocking) |
| `formater` | unit tests | `black --check` + `isort --check` (blocking) |
| `typing` | unit tests | `mypy` (blocking) |
| `unit-tests` | unit tests | `pytest -m unit` + coverage Cobertura/JUnit (blocking) |
| `security` | unit tests | `bandit` SAST (blocking) |
| `deps-sec` | unit tests | `pip-audit` in isolated venv (blocking) |
| `build-package` | build | `pip wheel` (blocking) |
| `sphinx-build` | documentation generation | Sphinx docs build (blocking) |

**Allow-failure (non-gating) jobs (five), justified:**

| Job | Why non-blocking |
|---|---|
| `docs-cov` | `docstr-coverage` informational (≥ 30 %) |
| `complexity` | `xenon` advisory |
| `sonarqube` | External service (`sonar-scanner` image; needs `SQ_URL`/`SQ_LOGIN`) |
| `integration-tests` | Template Dask-gateway/S3 path unavailable on the shell runner (tests themselves now pass; promote to blocking on a K8s runner) |
| `deliver-image` | kaniko needs a container runtime, absent on the shell runner |

**Conditional release jobs (rules-gated, not `allow_failure`):** `deliver-package`
(`if $CI_COMMIT_TAG`) uploads the wheel to the GitLab PyPI registry; `upload-documentation` and
`pages` run on `main`/tags to publish versioned docs to GitLab Pages.

The `allow_failure`/non-blocking status of the five jobs is a **deliberate, justified configuration
choice** for the current shell-runner infrastructure (RD-8 §<4>; Risk Register RD-18), not a defect.
The `integration-tests` and `deliver-image` jobs become candidates for blocking when the SDE
Kubernetes runner replaces the shell executor.

---

## <9> Configuration control and status accounting

### <9.1> Configuration control

All configuration items (source, tests, CI pipeline, tool configs, compliance documents) are under Git
and changed **only through reviewed Merge Requests to `main`** under ECSS-M-ST-40C Rev.1 (SPAP RD-13
§6.5; RD-1 SDP §5.4). Each MR must pass the full blocking gate set (<8.2>) or carry a recorded waiver.
The repository history is the configuration-status record. Branch protection prevents direct pushes to
`main`.

### <9.2> Configuration status accounting (this baseline)

| Item | As-built status at QR |
|---|---|
| Baseline | `main` @ d140599 (`d140599293ac083dc3da04e63e645da54b8f0b5b`) |
| CI pipeline of record | 30730 — success; 9 blocking gates green (+ `validate-variables` guard) |
| SCI version | dynamic via `flit_core`; module `__version__ = "0.0.1"` (template default); QR RC proposed `v0.1.0-rc1` |
| Git tag | none yet (created at the release action; see <4.3>) |
| Implementation completeness | 8/8 processing units implemented, CI-green |
| Test configuration | 248 cases (246 unit: 244 pass/2 xfail; 2 integration: 2 pass) — verdicts in RD-11 SVR |
| Open NCR/SPR | tracked to closure at QR/AR (SReVP RD-12; SPAP RD-13) |

### <9.3> Relationship to CIDL and SRN

This SCF is one of three coupled configuration deliverables in the QR data package:

- **CIDL (RD-17, `docs/cidl.md`)** — enumerates the configuration items that constitute the SCI
  (source modules, tests, CI, docs, compliance set) and their identification.
- **SCF (this document)** — records the as-built *physical configuration* (build, runtime, toolchain,
  CI) frozen at the baseline of record.
- **SRN / SRelD (RD-16, `docs/srn.md` + GitLab Releases)** — declares the released version
  (`v0.1.0-rc1` referenced to d140599), the contents and the open items.

The three are mutually consistent against commit d140599 and pipeline 30730.

---

## <10> Open configuration items at QR

The following are recorded as open configuration items carried to AR; they do not alter the
Category-C qualification verdict for the software item.

**(a) Numeric performance-budget validation withheld (QR open item → AR).** The Tier-C numeric
validation of `REQ-P-01..05` (`RAD_ACC`, `GEO_CE90` + `BAND_COREG`, `BOA_ACC`, `THRU_SCENE`,
`MEM_BUDGET`) requires the operator's private real RAW + calibration data (data policy SSS <5.1>) which
is never in public CI. These requirements are verified at QR by analysis/design and the algorithm
V&V; the numeric budget closure is performed on operator data at AR (RD-8 §<8.8>; RD-11 SVR). This is
the single most important QR configuration limitation.

**(b) Deferred fail-stop algorithm paths (`[impl]`).** The as-built tree contains **six deliberately
deferred, fail-stop algorithm implementations**, all recorded as waivers traced in the RTM (RD-15,
G-1/G-6); the operational baseline never executes them:

| # | Unit / algorithm | Reason |
|---|---|---|
| 1 | `l0_decode` `decode_source_packets` (`ALG-L0-DEC`) | Sensor-private on-wire forms only; the documented canonical L0 ground-decodes in `ground_decode` (REQ-F-L0-06); open-container path unchanged |
| 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); 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 pan-sharpen component-substitution fusion methods (`brovey`/`gs`/`ihs`/`atrous`) are
deferred; only `simple_mean` is operational.

**(c) CI promotion pending K8s runner.** The five `allow_failure` jobs (<8.2>) — notably
`integration-tests` and `deliver-image` — are non-blocking only because the registered runner is a
shell executor; they are candidates for promotion to blocking gates once the SDE Kubernetes runner
lands (Risk Register RD-18).

**(d) Release tag.** No Git tag exists at QR; the `v0.1.0-rc1` tag and the package/docs publication are
the release action taken at the release decision (<4.3>, <9.3>).

---

*End of Software Configuration File. Authored per ECSS-E-ST-40C Rev.1 (software configuration
management; SCF / as-built record), ECSS-M-ST-40C Rev.1 (CIDL/SCF) and ECSS-Q-ST-80C Rev.2, tailored
for Category C, single-developer. The as-built baseline of record is `main` @ d140599 (pipeline 30730 =
success). The CIDL (RD-17) enumerates the configuration items; the SRN (RD-16) declares the release
candidate `v0.1.0-rc1`; the QR verification evidence is the SVR (RD-11).*