EN 18221 clause 4.2 version archiving is absent, and our 'archive' means something else

[LKSNDRTMLKV]

1. 🚨 "Archive" means two different things, and the collision hides a gap

POST /api/v1/dpp/{dppId}/archive — "permanently archive a published or suspended passport" after retention expiry — sets a terminal lifecycle status. That is what "archive" means in this codebase.

EN 18221:2026 (Digital product passport — Data storage, archiving and data persistence, one of the six standards cited by Commission Implementing Decision (EU) 2026/1736) uses the word for something else entirely: the retention of historical versions of a passport that is still live.

Anyone mapping our surface to that standard by name would tick the box. The box is not ticked.

2. What clause 4.2 actually asks for

In our own words, not the standard's:

• archiving begins at the first change to the initial passport — not at publish, and not at end of life;
• archived versions are held by both the back-up service provider and the creator (or a main provider acting for it);
• all archived versions persist for the passport's lifetime;
• all changes are archived, save those a product-specific rule exempts — real-time sensor data is the example the standard gives;
• archived attributes carry the same access restrictions as the live ones;
• the version as it stood at a given point in time is retrievable by authenticated, authorised actors.

3. What we have instead

An append-only audit trail — repo_audit, enforced by an ODAL_AUDIT trigger that rejects mutation at the database. Closest in spirit, and genuinely good, but an audit trail records that something changed. It does not reconstitute the passport as it stood at time T, which is the clause's actual requirement.

Continuity snapshots — which fire on publish, and on the status changes that leave the public tier. Publish-triggered, not change-triggered, and they carry the rendered public view rather than the full record. dpp-types/src/snapshot.rs already invokes EN 18221 in its module doc — written against an assumption about the standard, before anyone had read it. The posture it describes is right; it is not the same obligation as clause 4.2.

Verdict: non-conformant on the evidence. Not "probably fine" — the mechanism the clause describes is not present.

4. Clause 4.3 has a requirement we have not designed for

The back-up provider must hold the most recent version and all required historical versions, with the same access restrictions as the original; the passport is available to specifically authorised users from the back-up for its lifetime; and — the one worth reading twice —

general access via the back-up becomes available once the economic operator is no longer active on the market.

That is a concrete, implementable mechanism for the ESPR Art. 11(e) availability-after-insolvency requirement, and it is more specific than anything in the current design. Our continuity tier keeps a passport reachable when the node is down. It does not model a change of audience on operator cessation — access widening, not merely persisting.

This is a design input as much as a conformance finding.

5. ⚠️ Clause 4.5 cannot be assessed at all yet

Replication to the back-up provider must cover the passport and all changes, at a frequency sufficient to minimise data loss — the standard names a Recovery Point Objective as the way to express it. It must be possible via a standardised lifecycle API per EN 18222:2026, and must run over a data exchange protocol per EN 18216:2026.

Neither standard is on hand, so clause 4.5 conformance is not assessable, not merely unassessed.

⚠️ And a property of the standard rather than of us: EN 18221's normative references include EN 18239 and EN 18246, both of which are undated because they are still under preparation. Clause 4.2's integrity requirement points at EN 18246. Full conformance with EN 18221 is therefore not presently achievable by anyone. Worth knowing before any outward conformance claim.

6. ✅ The good news, and it is substantial

EN 18221's Annex ZA maps its clauses to ESPR essential requirements, and for Art. 10(4) it records that the presumption covers only the technical aspects of the back-up — not the existence of the back-up as such.

So the standard itself separates does the mechanism conform from who may lawfully operate it (ESPR Art. 2(32)'s independent-third-party requirement), and supplies only the first.

That means the continuity work can proceed as a technical conformance exercise without first resolving the service-provider question. Those have been treated as one blocked decision; they are two, and the standard is the citable basis for separating them.

What this issue asks for

1. Disambiguate the word. Either rename the lifecycle endpoint/status or document the collision prominently where someone comparing us to EN 18221 will see it.
2. Decide whether to build version archiving to clause 4.2's shape, and whether the append-only audit trail is the substrate for it.
3. Design the cessation-triggered access widening of clause 4.3, or record a deliberate decision not to.
4. Acquire EN 18216 and EN 18222 before any clause 4.5 work — they gate it normatively.

Per-surface verdicts and the full clause-by-clause mapping were recorded separately; everything needed to act on this issue is restated above, so no other document is required to work it.

[LKSNDRTMLKV]

The evidence dossier is where this gap becomes visible to an authority

Reviewing the dossier's design against what it owes a reader, the clause 4.2 gap has a concrete downstream consequence worth recording here rather than as a separate issue.

A dossier is a snapshot of now. It carries the passport's current full and public views with their signatures, the audit trail, the transfer chain, the component graph and — as of #322 — the qualified seal with its binding, issuer and evidenced level. Every one of those describes the passport as it stands when the dossier was generated.

So an authority asking "what did this passport say on 14 March 2027?" cannot be answered by handing them a dossier. It cannot be answered by generating one then either: assemble_dossier reads the live passport row. The audit trail travels inside the dossier and records that fields changed, which is not the same as reconstituting the record.

That is exactly the distinction this issue draws — and the dossier is the surface where it stops being abstract, because the dossier is the artefact that gets handed over.

Two things that follow for whoever picks this up

Version archiving and dossier generation are the same feature seen twice. If historical versions become retrievable, generate_evidence should take an as-at parameter, and DossierManifest should record which version it describes rather than implying "current". Building the storage without that leaves the evidence surface still unable to use it.

content_hashes already commits to every member, so a dossier over a historical version needs no format change — only a different set of members and a manifest that says which point in time it covers. The format was built for this; nothing about it assumes the present.

What is not a gap, checked while looking

Recording these so the next reader does not re-investigate:

• the passport's own jwsSignature and publicJwsSignature are verified, via full_view_signature and public_view_signature — they are built through a helper rather than inline, which makes them easy to miss when scanning check names;
• the report's trust_anchor_note already states that verification is anchored to the dossier's embedded DID-document snapshot, with its date, so a reader is not left assuming a live resolution;
• did_builder retains rotated-but-not-revoked keys as additional verification methods, so a key rotation does not invalidate previously published passports. Revoked keys are excluded deliberately.