CIRPASS and the Passport Data Model

A recurring question from engineering teams is which schema a Digital Product Passport uses. The answer is unsatisfying and worth understanding properly, because the way it is unsatisfying tells you how to build safely.

Regulation (EU) 2024/1781 does not name a format. It requires that passports be based on open standards, be interoperable, and be machine-readable, structured and searchable. The specifics are delegated to European standardisation.

Why the regulation avoids naming a schema

Fixing a data format in legislation guarantees it will be out of date before it applies. Standards revise on a cycle measured in years; regulation revises on a cycle measured in parliamentary terms.

Delegating to standardisation also allows the model to differ by product group where it genuinely must, while keeping a common core. A battery passport and a construction product passport share identity and provenance structures and diverge entirely on domain attributes.

What CIRPASS produced

CIRPASS was an EU-funded preparatory initiative that set out to answer what a cross-sector passport data model would need to contain and how the system architecture would work. Its output is groundwork rather than a binding specification.

The substantive contributions were a common vocabulary for passport concepts, an architecture separating identification, data storage and access from one another, and a set of cross-sector data requirements distinguishing what every passport needs from what specific product groups add.

That separation of concerns is the part with immediate practical value. It is why a resolver is a distinct component from a data store, and why access control belongs to the serving layer rather than to the format.

JTC 24 is where it becomes standard

CEN-CENELEC Joint Technical Committee 24 is the body developing the European standards for Digital Product Passports. Its work is what delegated acts will ultimately reference.

The practical consequence for anyone building now is that some detail remains open. That is uncomfortable and it is not a reason to wait, because the parts most likely to be settled in a way you would not predict are the least expensive to change.

What interoperability actually demands

Interoperability is easy to claim and specific to test. Three questions separate a passport that interoperates from one that merely exports.

• Can another system read it without bespoke work? Standard identifiers and vocabularies rather than internal codes that require a mapping document.
• Can a claim be verified without contacting you? Signed credentials resolved through a published key, not a database lookup against your API.
• Can the data be moved intact? A full export in standard formats, including the provenance and credentials, not a flattened spreadsheet of current values.

The third is the one worth testing during vendor evaluation rather than after. Portability that has not been exercised is a claim, and the point at which you discover otherwise is the point at which you have the least ability to act on it.

How product groups extend the core

The cross-sector model is deliberately thin. It covers what every passport needs — identity, the economic operator, conformity, and the access rules — and stops there.

Everything distinguishing a battery from a bedsheet sits in a product-group extension defined by that group’s delegated act. State of health, fibre composition and declaration of performance are all extension attributes, and none of them belong in a common core that every product group would otherwise have to carry as empty fields.

For implementation this means the core is stable and the extensions arrive on the delegated act timetable, which is a considerably more manageable pattern than waiting for one complete specification covering every sector at once.

Designing to survive the standard

The approach that ages well is to separate the attribute layer from the representation layer, so that a change in how data is expressed does not require re-collecting it.

Companies that stored a compliance conclusion rather than the underlying attribute with its provenance will have to repeat supplier work when the model is finalised. Companies that stored the attribute will have a mapping exercise.