Risk Register#


Document	Risk Register
DRD	No dedicated DRD — risk attributes per ECSS-M-ST-80C (risk management); contributes to SDP §4.5
Container	Management File (MGT)
Project	`msi-processor` — generic high-resolution MSI data processor
Configuration item	`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	SRR
Status	Draft for SRR

This Risk Register is the software engineering function’s contribution to project risk management (SDP §4.5). It records, assesses and tracks the risks of the msi-processor project using the ECSS-M-ST-80C risk attributes (likelihood A–E, severity 1–5, risk index/magnitude, treatment, owner, status, trend). It is established at SRR and reviewed at every subsequent milestone (PDR, CDR, QR, AR). The scope is the software engineering risks of a Category C, single-developer ground-segment processor; it is proportionate to that footprint and does not duplicate the project-level (programmatic) risk management of the ipf group.

<1> Introduction#

The purpose of this register is to identify the risks that can affect the correct, on-time and standards-conformant delivery of msi-processor, to assess their likelihood and severity, to record the treatment (mitigation) and the responsible owner, and to track their evolution across the life cycle. Risk management for this project is operational, not bureaucratic: each risk that is rated High has a concrete mitigation action tracked in GitLab, and the register is re-assessed at each review.

The risks below derive from the project’s defining constraints (recorded in SDP §4.3): the eopf == 2.8.1 pin against an SDE build image tagged latest; a CI shell executor with no container runtime, Dask gateway or S3; a public code / private data policy that forbids raw and calibration data from CI; and a single-developer organisation in which verification independence must be achieved by tooling rather than by separate staff.

<2> Applicable and reference documents#

Risk management follows ECSS-M-ST-80C (Space project management — Risk management) for the attribute set and scoring approach, and ECSS-M-ST-10C Rev.1 (AD-3) for the programmatic context. The full applicable/reference document list is in SDP §2; the documents directly relevant here are:

Ref	Document
AD-3	ECSS-M-ST-10C Rev.1 — Project planning and implementation
—	ECSS-M-ST-80C — Risk management (attribute set / scoring scheme)
RD-1	EOPF SDE — User Manual & Guidelines (build image, runner)
RD-2	EOPF CPM documentation (`eopf == 2.8.1`)
SDP	Software Development Plan — §4.3 (constraints), §4.5 (risk management), §4.7 (staffing)

<3> Risk management process#

The process implements the ECSS-M-ST-80C cycle, tailored to a single-developer Category C project:

Identification — risks are captured from the project constraints, the engineering plan and milestone reviews. Each risk is recorded as a GitLab issue with the ~Risk label (issue template Risk.md) and mirrored in this register.
Assessment — each risk is scored for likelihood (A–E, §4.1) and severity (1–5, §4.2); the risk index/magnitude (Low / Medium / High) is read from the matrix in §4.3, taking existing controls into account.
Decision & treatment — a treatment strategy is selected (ECSS-M-ST-80C): Reduce (mitigate), Accept (tolerate a constraint), Watch (monitor), Avoid or Transfer. Risks rated High must have at least one linked mitigation action (~Action issue); actions for Medium/Low risks are recommended, not mandatory.
Monitoring & control — the register is reviewed at every milestone (SRR → PDR → CDR → QR → AR). Each review updates likelihood/severity, status and trend, and adds or closes risks. Change control is via merge request, consistent with SDP §4.6.

<4> Scoring scheme#

<4.1> Likelihood (A–E)#

Score	Level	Interpretation for this project
E	Maximum	Near-certain to occur within the project life cycle
D	High	Likely to occur
C	Medium	May occur
B	Low	Unlikely but credible
A	Minimum	Very unlikely

<4.2> Severity of consequences (1–5)#

The scale combines the technical/quality, schedule/cost and confidentiality consequence domains. Note the Category C classification (SDP §5.6): a software failure of msi-processor produces only degraded or incorrect data products, recoverable by reprocessing — i.e. its technical severity does not exceed Major (3). Higher scores (4–5) are reserved for project consequences that are not software-failure consequences: loss of the core capability/schedule (4) and irreversible disclosure of private data (5).

Score	Level	Interpretation
5	Catastrophic	Project failure, or irreversible disclosure of private raw/calibration data
4	Critical	Core processing capability blocked; major rework; significant schedule slip
3	Major	Degraded/incorrect data products or a verification gap; recoverable by reprocessing
2	Significant	Limited, localised impact; minor rework
1	Negligible	Minimal impact

<4.3> Risk index / magnitude matrix#

The risk index is the magnitude read from the severity × likelihood matrix (L = Low, M = Medium, H = High):

Severity \ Likelihood	A	B	C	D	E
5	M	H	H	H	H
4	M	M	H	H	H
3	L	M	M	H	H
2	L	L	M	M	H
1	L	L	L	M	M

Acceptance criteria: High = not acceptable; requires an active mitigation action and is reported at the next review. Medium = acceptable while monitored and mitigated. Low = acceptable; monitored only.

<5> Risk register#

Likelihood (L) and severity (S) columns give the current assessed value (with existing controls applied); the strategy tag and text give the treatment. Owners are project roles (§6) — all held by the single project owner per SDP §4.7. Trend is measured against the previous review; at this first (SRR) baseline all entries are New (N).

ID	Risk (area)	L	S	Index	Mitigation / treatment	Owner	Status	Trend
R-01	`eopf==2.8.1` pin vs SDE build-image drift. The CPM build image is tagged `latest`; an SDE upgrade can desynchronise the pinned `eopf` from the image and break builds/CI.	C	3	M	Reduce — pin to image digest where the SDE allows; CPM access isolated behind a thin wrapper (R-05); CI smoke test against the pinned env; monitor RD-1 release notes; any forced `eopf` bump handled as a controlled change (MR + re-baseline).	Eng	Monitored	N
R-02	Shell-runner limitations block automated verification. The CI shell executor has no container runtime, Dask gateway or S3, so integration/distributed/object-store verification cannot run in public CI.	D	3	H	Accept + Reduce — affected jobs set `allow_failure: true` (non-blocking); equivalent verification performed locally with evidence recorded in the SVR (`compliance/drd/vv-report.md`); migration to a Kubernetes/Dask-gateway runner tracked as an action.	V&V	Accepted	N
R-03	Private-data-only verification, no public reference (L0→L1). Raw L0 and calibration are private; there is no public reference product and no second verifier, so radiometric/geometric correctness cannot be independently checked in CI.	C	4	H	Reduce — deterministic synthetic fixtures (non-sensitive) drive golden tests in public CI; local numerical verification on real data with checksummed reference outputs logged in the SVR; cross-check against an open reference processor (e.g. SNAP/ESA L1) where a comparable product exists; independence via automated gates + documented review checklists (SRevP).	V&V	Open	N
R-04	Instrument calibration availability/quality. Missing, late or low-quality calibration ADFs (gain/offset, dark, flat-field) prevent or corrupt radiometric correction; flat-field defects can produce subtly wrong L1.	B	4	M	Reduce — acquire calibration ADFs early; ADF sanity checks (range, NaN, dead-pixel maps) before use; synthetic calibration ADFs for unit/pipeline tests; record calibration provenance/version in product metadata and the SCF.	Eng	Open	N
R-05	CPM API stability. EOPF CPM (`EOProcessingUnit`/`EOProduct`) interfaces evolve across `eopf` versions; an API change could invalidate the design.	B	3	M	Reduce — pin `eopf==2.8.1`; concentrate CPM usage in a thin PU wrapper/adapter (per SDD) so the core is framework-agnostic; integration tests bound to the pinned API; review the CPM changelog before any upgrade.	Eng	Mitigated	N
R-06	Atmospheric L2 is genuinely new development. Unlike L0→L1 (algorithm heritage via SRF), L2 atmospheric correction has no prior heritage, raising correctness and schedule uncertainty.	D	3	H	Reduce — author the L2 ATBD at PDR (`docs/atbd/`); base L2 on an established radiative-transfer model / LUT (e.g. 6S, libRadtran) rather than a novel algorithm; prototype early and schedule L2 as the final increment; define explicit L2 acceptance criteria in the SValP with schedule margin.	Eng	Open	N
R-07	Public-code / private-data (or secret) leakage. Accidental commit of raw data, calibration or credentials to the public repository is irreversible disclosure.	B	5	H	Reduce — data/calibration never committed (enforced `.gitignore`); pre-commit secret/data scanning (`gitleaks`/`detect-secrets`); CI `bandit` + `trivy`; MR checklist item “no data/secrets”; private data kept outside the repository tree.	PA	Mitigated	N
R-08	Single-developer bus factor / verification independence. One person holds all knowledge and all roles; unavailability halts the project, and verification independence is tooling-based only.	C	3	M	Reduce — documentation-first (all design, decisions and rationale auditable in Git); public repo lowers the pickup barrier; automated quality gates + explicit review checklists substitute for a second verifier; SemVer + GitLab issues for continuity (SMP-light).	PM	Open	N
R-09	Geometric-correction auxiliary data. Orthorectification depends on DEM and orbit/attitude (and GCPs); poor availability or accuracy degrades geolocation.	C	3	M	Reduce — use open auxiliary data (Copernicus DEM, public orbit/attitude) where possible; document aux-data sources and accuracy in the DPM/ICD; bound geolocation residuals against GCPs; expose aux-data accuracy in product quality metadata.	Eng	Open	N
R-10	EOPF Zarr product-format conformance. Output Zarr that does not conform to EOPF `EOProduct` conventions reduces interoperability.	B	2	L	Watch — validate outputs against the CPM `EOProduct` schema / EOPF product conventions (RD-2); add a conformance test in CI.	Eng	Open	N
R-11	Schedule/scope risk of the documentation-first plan. A single developer carrying SRR→AR with a five-milestone documentation tree may slip, especially around the new L2 work (R-06).	C	2	M	Reduce — Category C tailoring keeps the footprint small (merged V&V docs, light DRDs per SDP §5.5.2); milestone + issue tracking; documentation-first reduces late rework; L2 scheduled as the final increment.	PM	Open	N

<6> Risk owners#

All roles are held by the single project owner (SDP §4.7); the role attribution below shows under which discipline each risk is managed, supporting the tooling-based separation of duties.

Owner code	Role
Eng	Software engineering (design, implementation, data/algorithm integration)
PA	Software product assurance (security, configuration, data policy)
V&V	Verification & validation
PM	Project management (schedule, scope, continuity)

<7> Summary and top exposures#

Risk profile at SRR: 4 High, 6 Medium, 1 Low (11 risks).
Top exposures (High):
- R-02 — shell-runner verification gap: the top operational risk; accepted as a known constraint and compensated by local verification + allow_failure, pending a Kubernetes runner.
- R-03 — private-data-only / no public reference: the top assurance risk; the binding challenge for verification independence and auditable correctness of L0→L1.
- R-06 — new L2 development: the top technical/schedule risk; the only stage without algorithm heritage.
- R-07 — data/secret leakage: low likelihood but catastrophic severity (irreversible); kept High by severity and held down by preventive controls.
Watch items: R-01 (build-image drift) and R-04 (calibration) can escalate quickly if the SDE image or the calibration supply changes; both are monitored at each review.

<8> Tooling and traceability#

Risks are maintained both here (authoritative, baselined per review) and as GitLab issues:

Each risk is a GitLab issue labelled ~Risk (template .gitlab/issue_templates/Risk.md), carrying the rating label ~Risk::Rating::{Low|Medium|High}.
High-rated risks (R-02, R-03, R-06, R-07) carry at least one linked mitigation ~Action issue (/relate), per the issue template and §3.
The GitLab template’s simplified 3×3 scheme (Probability 1–3 × Severity 1–3 → Low/Medium/ High) maps onto this register’s ECSS 5×5 scheme as follows: the Index column (§4.3) is authoritative, and the GitLab Rating label mirrors it band-for-band (Low/Medium/High).
Mitigation evidence (test runs, local verification, scan results) is recorded against the SVR (compliance/drd/vv-report.md) and the CI pipeline status (SDP §4.6).

<9> Review and maintenance#

The register is re-assessed at every milestone review (SRR, PDR, CDR, QR, AR). Each review: updates L/S, Index, Status and Trend; opens risks for newly identified exposures (notably new L2/atmospheric risks expected at PDR/CDR); and closes risks whose conditions no longer apply. Status values: Open (no controls yet), Mitigated (controls in place, residual acceptable), Accepted (tolerated constraint), Monitored (watched, no action due), Closed. Trend values: N (new), ↑ (worsening), → (stable), ↓ (improving).

End of Risk Register. Risk attributes per ECSS-M-ST-80C; contributes to SDP §4.5.