Public roadmap
What is built, what is blocked, and what is not started.
Two public repositories: dpp-core, the regulatory library, and dpp-engine, the software that runs a node. This page is the status of both, audited against the repositories rather than against the last version of this page.
dpp-core
v0.20.0
Apache-2.0, published to crates.io
dpp-engine
v0.13.0
BSL-1.1 with a free self-host grant
Nobody is running this in production. No customers, no pilots, no live deployments, and nothing on this page should be read as evidence of any. The battery passport obligation begins on 18 February 2027, and we would rather be correct when it arrives than early and wrong.
There are no dates below. Timing on regulatory infrastructure depends on delegated acts, standards-body votes and registry availability — none of which we control — so the category is the commitment and a quarter would be a guess dressed as one.
Status
Four registers, never mixed.
Shipped
In a tagged release, with a test that exercises it through the running system. Verified fact.
The open library
Eleven crates on crates.io
The domain model, cryptography, credentials, GS1 Digital Link, the Asset Administration Shell projection, the plugin contract and the regulatory rules — all Apache-2.0, all readable and reusable by anyone, including a competitor.
Regulatory rules as a dependency-free crate
The cross-field rules that change when a regulation changes are a pure no_std crate with zero dependencies, so they can be audited on their own terms rather than read through a framework.
Product groups
Every product group modelled, with its full version history
Each carries its schema versions, its categories, its disclosure split and its own note saying which of its fields are a best reading rather than a requirement. Older schema versions stay served — a passport published against one does not stop resolving when a newer one lands.
Compliance rules run sandboxed, and are swapped without a redeploy
Each product group's rules compile to WebAssembly and run isolated from the node. The host verifies a plugin's signature and its declared schema range before dispatching to it.
odal plugin install
Identity and signing
Signed on the operator's own key, on the operator's own infrastructure
Ed25519, an encrypted keystore, and a did:web identity in a domain the operator controls. The signing key can be rotated without invalidating what it already signed. Nothing is sent anywhere to be signed.
Publication and resolution
Scan the code, get the public view
GS1 Digital Link resolution when the product carries a GTIN, and a plain passport URL when it does not — because requiring the barcode would mean requiring GS1 membership. No login and no fee, because the regulation says so.
/01/{gtin}/21/{serial}
Asset Administration Shell export
A shell plus per-product-group submodels, for the industrial systems that speak AAS rather than passports.
Disclosure
Depth proven by credential, enforced per field
The same record answers a repairer, a recycler and an authority differently, and which fields each sees is decided by the credential they present rather than by a header they set. For batteries this is a lattice and not a ladder — an authority sees less than a recycler in one specific respect, and modelling it as a ranking would be wrong.
Lifecycle and custody
A record that survives the sale
Suspension, retirement, a typed end of life, a recorded waste handover, and lineage that can name several predecessors rather than one.
odal passport eol
Responsibility changes hands with both signatures on the record
Remanufacture, repurposing or a sold product line, between two legal entities — either side can refuse or withdraw, and the chain of custody is part of the passport rather than an email thread.
odal passport transfer initiate
A tamper-evident history
Every change is appended to a hash-chained audit trail, so a record that was edited cannot present itself as one that was not.
odal passport history
Evidence and verification
A dossier that verifies with no network and no trust in us
Passport, signatures, identity documents and the full history in one signed file. Someone who has never heard of Odal Node can check it offline.
odal verify
The passport still resolves when the node does not
A pre-rendered static tier, signed and bounded, serving the same page the live resolver serves — through one renderer, so the two cannot drift.
odal snapshot verify
Running a node
One command-line control plane
Twenty-six command groups: bring the node up, onboard the operator, mint scoped API keys, manage facilities and economic-operator identifiers, import, publish, issue credentials, inspect seals, read registry status and scan telemetry. There is no separate console to learn, and no operation that is only available in one.
odal --help
Signed outbound webhooks
Passport events delivered to the operator's own systems, signed so a receiver can tell a real delivery from a replayed one.
odal webhook list
Compliance rulesets arrive signed, and are verified fail-closed
Rulesets ship as signed bundles and are hot-swapped. A node configured for production refuses a placeholder trust adapter rather than accepting one quietly.
odal ruleset reload
Scan telemetry the operator owns
How often a passport was resolved, operator-wide and per record, on the operator's own node rather than in someone else's analytics.
odal stats
The ESPR Article 24 unsold-goods disclosure
Recorded as many lines rather than one aggregate, because the article asks for figures differentiated per product type, per reason and per destination. A destruction recorded under an exemption must say which exemption.
odal unsold-goods record
Registration intent survives a crash
A durable outbox holds pending EU registry registrations and drains with backoff, so a registry that is slow, down or not yet reachable delays binding without ever losing custody.
odal registry
Getting data in
Bulk import from spreadsheets, with per-row errors
CSV, TSV, Excel and JSON, with a dry-run mode that reports what is wrong row by row instead of rejecting the file. Coverage is partial and the gap is tracked below — not every product group has an import mapping, and fewer have a downloadable template.
POST /api/v1/import/{productGroup}
Built, and legally inert
The machinery is written, tested and running. What it cannot do is claim any legal status — and the reason is not an engineering one.
eIDAS qualified seal
The sealing subsystem runs end to end today
Seals are created, stored, audited and re-read across restarts. EU Trusted List verification walks the list-of-lists down to the national list. Each seal carries its own findings — issuer, binding, evidenced level, attested time, archival state, certificate validity and revocation — and an operator can re-run a repair.
odal seal status
Every seal it issues reports itself as self-issued and of no legal effect
Under eIDAS an electronic seal may only be created by a legal person. There is no company behind this project, so there is no qualified certificate, so there is no qualified seal. The software says exactly that rather than rounding it up, and it refuses to present a qualified claim it cannot support. When a credential exists, what changes is the backend and the verdict — not the design.
Regulation (EU) No 910/2014, Art. 3(24)
EU Central Registry
The registry is live; enrolment is not open to us
The EU Digital Product Passport registry became operational on 20 July 2026. Registration identity is proved by qualified electronic seal or attestation — the same blocker as above, one step further along.
Commission Implementing Regulation (EU) 2026/1778
Our own connector has a structural mismatch to correct first
It models a bearer-token exchange where the registry expects eIDAS-based identity. That is a wrong assumption rather than a wrong URL, and it is a breaking change we would rather make against the published specification than guess at. The connector is not pointed at real products.
In build
Committed, each with a named condition. Nothing here is claimed as working.
Replacing the mandatory GTIN with the standard's identifier union
EN 18219 offers several identifier schemes as alternatives rather than a hierarchy, and requiring a GTIN meant requiring GS1 membership. The passport model and the plugins already take the union; the remaining work is the sweep through every rule, fixture and test that still assumes the old field. Condition: the next library release.
Wiring the compliance calculators into the node
Cradle-to-gate CO2e and EN 45554 repairability are written and published as part of the open library, with the licensed emission-factor data injected rather than bundled. Nothing in the running node invokes them yet, so no passport carries a computed figure. Condition: the evidence-receipt path that records which ruleset version produced a number.
Import coverage across every product group
Bulk import maps five of the twelve product groups, and downloadable CSV templates exist for two. The mechanism is shipped; the per-group mappings are not. Condition: one mapping and one template per modelled group.
The unsold-goods disclosure as a publishable artifact
The record is written and read today. What does not exist is the document an operator publishes on their own website, which is where Article 24 actually puts the obligation. Condition: the output format, which no implementing act prescribes.
odal unsold-goods list
Toy and detergent content completeness
Both schemas carry almost none of the content their annexes mandate — and that content is in the adopted acts, not in the implementing acts still pending. These two are modelled far more thinly than the rest and should be read as placeholders.
Horizon
Under consideration. Not started, not scheduled, and deliberately carrying no dates.
Known gaps in what is modelled
The semantic repository
The framework requires passport data to be expressed against a published vocabulary held in a repository we do not yet read. It is mandatory and it is free, and not having read it is the largest single gap on this page.
Language
Toys and detergents must present the passport in the language or languages of the Member State where the product is placed. There is no language dimension anywhere in the model.
Images
The toy and detergent annexes both require a colour image of the product. There is no image concept in the passport at all.
A position on personal data in a passport
One ESPR paragraph is unconditional about what a passport carries, and we have taken no position on what that means when the value identifies a customer. Deciding this badly is worse than deciding it late.
Battery carbon footprint
Blocked upstream rather than by us: the calculation method has not been published, so there is nothing to implement. Guessing at it would produce a number that looks authoritative and is not.
Options not yet taken
A public, genuinely offline conformance validator
Anyone could check a passport against the standards without sending it to us, or trusting us. Six European standards are cited by the framework; two have been read in full so far.
A second credential format
The UN Transparency Protocol's passport credential as an alternative door into the same record, for supply chains that have standardised on it.
A second signing curve
P-256 alongside Ed25519, if a hardware or registry requirement ever calls for it. An open question rather than a plan.
An EU-operated identity method
did:ebsi as an alternative issuer identity to did:web, if registry requirements call for it.
Hosting several operators
One operator, one node, one database, one key, and no shared data paths at any layer — that invariant is settled and is not what is open. What is open is only how the machines are provisioned.
An edge-cached public resolver
Cached passport pages for scan latency away from the node's own region.
How this is maintained
What moves a feature between registers.
An item is shipped when it is in a tagged release of the relevant repository and a test exercises it through the running system. Merged is not shipped, and neither is demonstrated — "shipped" here means there is something that fails if it stops working.
An item is in build only with a named condition attached, so that a reader can tell what would have to be true for it to move. An item on the horizon is an option under consideration, and is written in the grammar of an option: it carries no date, and no promise.
The fourth register is the one most roadmaps do not have. Built and legally inert covers work that is finished, tested and running, and that cannot be used for the thing it exists to do. The sealing subsystem is the example: it works end to end and every seal it produces reports itself as self-issued and of no legal effect, because under eIDAS only a legal person may create an electronic seal. Filing that under "in build" would turn a legal fact into an engineering timeline.
Items move backwards. Discovering while building something that it needs more foundational work is an ordinary outcome of building it, and that work returns to the horizon with a note about what was learned. A reversal recorded is better than an item quietly drifting for six months.
Honesty
What this page is not.
It is not a schedule, and it is not exhaustive. The open issues in both repositories are public and carry the detail this page compresses — including the defects. If something you need is absent here, the useful assumption is that it does not exist rather than that it was forgotten, and the issue trackers are the place to say so.