Permanence & retention

Under ESPR a published passport is a long-term obligation. Once a product is on the market, Art. 9(2)(i) requires its passport to stay available for a period the delegated act sets, “at least the expected lifetime of a specific product”; ESPR itself fixes no number. Under Art. 10(4) the operator must also make a back-up copy available through a “digital product passport service provider”, so the passport survives even if the operator does not.

A node enforces these guarantees in its code. The operator does not have to switch them on, and cannot switch them off.

A published passport is kept permanently and can never be deleted. This page is about how it stays permanent.

Publishing locks a passport

When a passport is published, a retention lock is set on it, and it is never cleared. A locked passport can still change state: it can be suspended during a recall, or retired. Its content can no longer be edited. Only a draft can change; once a passport is signed and published, it is fixed.

There is no delete

The node’s storage interface has no delete operation. A published passport cannot be removed through the node, whatever the database underneath would allow and whoever operates the node. As a second safeguard, the database itself rejects the change (see Operating a node securely).

History is append-only

Every transition (created, published, suspended, retired) is written to an audit trail when it happens. Entries are only ever added, never rewritten or deleted, so years later a passport’s history still shows what happened and in what order.

Retiring is a state, not an ending

A passport can be retired, and a product’s end of life can be declared on its passport. Both are terminal states. Both keep the passport read-only but resolvable, because the regulation’s record-keeping period runs longer than the product’s life. Neither is a deletion. See A passport’s lifecycle.

Archiving is a different thing, and it runs the whole time

Retired is where a passport’s publication life ends. Archiving is what happens while a passport is still live: every time its content changes, the version it replaces is kept, whole, for as long as the passport exists. The node’s operator can ask what a passport said at an earlier moment and get that version back.

This is what EN 18221:2026 clause 4.2 asks for, one of the six standards the Commission cited in Implementing Decision (EU) 2026/1736. The two words were once the same word here, which made the difference easy to miss: a system can retire records faithfully and still keep no history at all. Odal Node does both, and calls them by different names.

Keeping the printed address working

The QR code on a product encodes a web address on the operator’s resolver, and that address has to keep working for the whole retention period, possibly long after the product was made. A code already printed keeps resolving after its passport is corrected or replaced. The address itself stays alive only as long as the operator’s domain does. How a node’s addresses are assigned and kept stable over the full retention period is an open design question we have not settled yet.

Readable when the node is not

A node can copy each published passport’s signed public view to a separate, public object-storage bucket, with a signed time bound saying how long that copy is valid. A CDN or bucket website serves it at a stable path while the node is unreachable, and odal snapshot verify checks the time bound without the node. See Proof files and verification.

Back-up copy

A node can also copy every passport version to private object storage (any S3-compatible service), kept apart from the public snapshot bucket. That copy is optional today, and a node without one says so in its trust posture. It holds copies, not a history: unlike the archive above, it cannot return the version that was current at a given moment.

Article 10(4)’s back-up copy, held by a digital product passport service provider so that a passport survives an operator’s insolvency or shutdown, is a separate obligation on the operator; Art. 11(e) requires the passport to stay available through insolvency, liquidation or cessation of activity. The node does not provide that service. Whoever does has less to keep because of the proof-bound model: the signed passport and its history, not a large production dataset.