Use case · Product compliance

A passport for every product, built on data you can defend.

We design and build digital product passports: collecting material and supply-chain data, issuing identifiers and QR data carriers, controlling who sees which fields, and keeping verifiable records. AI agents gather and check supplier data; your compliance team approves what is published.

For heads of product compliance and sustainability leads at manufacturers placing batteries, textiles, electronics or other regulated products on the EU market.

A product with a verifiable recordSCAN FORPASSPORTIDENTIFIEROwner approvesCOMPOSITIONRecord publishedFOOTPRINTHash anchoredACCESSVersions retained#3fa1#3fcc#3ff7#4022#404d#4078

Regulatory clock

Dates that shape a passport programme.

Obligations depend on product group and on delegated acts still being adopted; check current legal texts before relying on a date.

Where most programmes start

  1. The EU Battery Regulation enters into force and sets a battery passport requirement for a later date.

  2. ESPR enters into force as a framework. It creates the legal basis for passports but leaves product-specific data requirements to delegated acts.

  3. The Commission publishes its first ESPR working plan naming priority product groups. Supplier data requests still go out by email and spreadsheet.

  4. Composition and footprint data sit with different teams, with no identifier tying them to a model, batch or item.

With a passport programme

  1. Data sources are inventoried against the battery passport requirements and the fields likely to apply to your product groups. Each gap has an owner.

  2. A pilot runs for one product line: identifiers issued, QR carriers tested on labels, access tiers configured and supplier data validated.

  3. The battery passport applies to EV, light means of transport and industrial batteries above 2 kWh placed on the EU market.

  4. Each new product group joins the same data model and platform, with requirements and transition periods taken from its own act.

Inside a record

An annotated passport, field by field.

An illustrative record for an industrial battery module. Values are placeholders; the notes show what each field needs behind it.

Passport · Industrial battery module (sample)Illustrative record · fictitious data · public view with restricted fields marked
Unique identifier: GS1 Digital Link URI, encoded in a QR code on the module label
Manufacturer: legal name, registered address, operator identifier
Material composition: cathode chemistry, critical raw materials, hazardous substances
Recycled content: cobalt, lithium, nickel and lead shares [declared]
Carbon footprint declaration: value, performance class, study reference
Repair and dismantling: procedure link, spare-part sources [restricted]
Access tier per field: public / legitimate interest / authorities
Ledger anchor: SHA-256 digest of record v3, Hedera consensus timestamp

Assembling a passport

From scattered declarations to a published record.

Three stages between a supplier's spreadsheet and a scannable QR code.

A product with a verifiable recordSCAN FORPASSPORTIDENTIFIERSupplier requests sentCOMPOSITIONDeclarations parsedFOOTPRINTBOM cross-checkedACCESSGaps sent back#3fa1#3fcc#3ff7#4022#404d#4078

Conceptual flow, not a live system or measured result.

01

Collect and check supplier data

Agents send structured data requests to suppliers, read the declarations, test reports and certificates that come back, and map each value to the passport data model. They check part numbers against your bill of materials and flag missing substances, expired certificates and figures that contradict earlier submissions, returning each gap to the supplier. Every exchange is kept with the supplier record, and nothing enters a passport until a compliance reviewer has accepted the evidence behind it.

A product with a verifiable recordSCAN FORPASSPORTIDENTIFIERSupplier requests sentCOMPOSITIONDeclarations parsedFOOTPRINTBOM cross-checkedACCESSGaps sent back#3fa1#3fcc#3ff7#4022#404d#4078
Supplier requests sentDeclarations parsedBOM cross-checkedGaps sent back
02

Assemble and tier the record

Accepted data is combined into a passport record per model, batch or individual item, depending on what the applicable act requires. Each field is tagged with an audience: public information for buyers, detailed data for repairers and recyclers with a legitimate interest, and full records for market surveillance authorities. The platform then issues the unique identifier and generates the QR data carrier for the label, product or packaging, and your team tests that it scans and resolves correctly.

A product with a verifiable recordSCAN FORPASSPORTIDENTIFIERRecord assembledCOMPOSITIONFields tieredFOOTPRINTIdentifier issuedACCESSQR carrier generated#3fa1#3fcc#3ff7#4022#404d#4078
Record assembledFields tieredIdentifier issuedQR carrier generated
03

Publish, anchor and maintain

When a compliance owner approves a record version, it is published at the identifier's resolver address. Optionally, a hash of that version is submitted to the Hedera Consensus Service, giving an independent timestamp that later shows whether the record was altered. Updates, such as a revised repair procedure or a changed supplier, create a new version with its own approval and anchor, and earlier versions stay retrievable so an auditor can see exactly what was shown, and when.

A product with a verifiable recordSCAN FORPASSPORTIDENTIFIEROwner approvesCOMPOSITIONRecord publishedFOOTPRINTHash anchoredACCESSVersions retained#3fa1#3fcc#3ff7#4022#404d#4078
Owner approvesRecord publishedHash anchoredVersions retained

Choosing an approach

Three ways to hold passport data, weighed fairly.

A ledger is not legally required. It makes records tamper-evident, which is not always worth the extra moving parts.

CriterionSpreadsheet + PDF declarationsCentral database / PLM exportPassport platform with verifiable records
Set-up effortLow; uses tools teams already haveModerate; extends existing systemsHighest; new data model, integrations and governance
Supplier data validationManual reading of each declarationField checks on import; evidence often held elsewhereAgents check values against evidence before acceptance
Access by audienceOne file for everyoneDepends on the portal; often all-or-nothingField-level tiers enforced by the platform
Proof a record is unchangedFile metadata onlyDatabase audit log, trusted if you trust the operatorOptional ledger anchor that third parties can verify
Running cost and complexityLow cost, heavy manual effortModerate; fits existing IT operationsHigher; a ledger adds transaction fees, keys and monitoring
Best suited toEarly data discovery or very small rangesProducts made in-house with strong PLM dataMany suppliers, many audiences, or disputed data

Programme readiness

How prepared is your product data?

Six questions. Four or more yeses mean a pilot could start from real data rather than a discovery exercise.

How prepared is your product data?

0 of 6

Start with a data inventory.

Map products to regulations, parts to suppliers and fields to owners. That work is needed whichever platform you choose.

Talk it through with us

Straight answers

When a passport platform is premature.

  • None of your products fall under the Battery Regulation or an ESPR priority group. A data inventory is a better first spend.
  • You sell mainly outside the EU and no customer is asking for passport data yet.
  • You want a ledger for its own sake. If one trusted operator holds the records and nobody disputes them, a well-audited database is simpler.
  • Your suppliers have not declared the data yet. A platform cannot publish what does not exist; start with supplier engagement and contract clauses.

Compliance questions

What product and compliance teams ask about passports.

Does the law require a blockchain or distributed ledger?

No. Neither ESPR nor the Battery Regulation requires a ledger. They set requirements for data content, identifiers, data carriers, access rights and availability. We offer optional anchoring on Hedera where tamper-evidence adds value, for example when several companies contribute data or records may be disputed, but a passport without it can meet the requirements.

Which products need a passport, and when?

Batteries are the first confirmed case: the battery passport applies from February 2027 to EV batteries, light means of transport batteries and industrial batteries above 2 kWh. Under ESPR, each product group receives its requirements and dates through its own delegated act. Your legal advisers should confirm scope for your products.

Will ColdAI certify our passports as compliant?

No. We design and build the data platform and agent workflows and map them to published requirements. Conformity remains the responsibility of the economic operator placing the product on the market; any third-party verification an act requires is done by designated bodies.

What do the AI agents actually do?

They handle the repetitive part of supplier data collection: sending requests, reading declarations and test reports in varied formats, mapping values to the data model, and checking them against your bill of materials and earlier submissions. They raise gaps and contradictions. They do not approve data for publication; a named compliance reviewer does.

Who can see commercially sensitive data?

Fields are tagged by audience. Consumers see public information; repairers, recyclers and others with a legitimate interest see the restricted fields granted to them; authorities see what the regulation entitles them to. Supplier-confidential values can be held as evidence without being published, subject to what the applicable act requires.

Go deeper

The pieces behind this workflow.

02Your starting point

What would you like to move forward?

Start with the outcome that feels closest. We'll help give the next step a useful shape.

04Let's find your next move

One conversation. A clearer direction.

Tell us what you want to improve. A few sentences are enough to start.

shayan@coldai.org

Last reviewed 25 September 2026.