This is the intake form for one product batch. Each row is a claim from the manufacturer's spec sheet. The passport is only as trustworthy as its weakest sufficiency-critical claim, so every row must declare where its evidence came from.
Prefilled from the datasheet. Change anything — a value, a provenance grade, a reliability, or whether a field is critical — then compute the receipt. Try setting a critical field to MISSING, or downgrading a VERIFIED claim to SELLER-ASSERTED, and watch the verdict move.
| Field (claim) | Value | Provenance | Source of evidence | Reliab. | Critical |
|---|
Reliability is the calibrated trust in that kind of source. MISSING forces it to 0. The engine gates on the minimum reliability across the critical rows — the weakest link.
The engine graded every claim, gated on the weakest critical one, and sealed the result. This is the receipt — reproducible by anyone, tamper-evident.
The receipt travels with the product record. Download it, attach it to an email, or POST it to a registry / transparency log. The external RFC 3161 time anchor is added at issue time server-side; the content and chain you can verify anywhere, offline.
In production the same bytes are anchored to an RFC 3161 timestamp authority (freeTSA / DigiCert) and, optionally, appended to a public transparency log so a third party can prove the receipt existed at issue time.
Months later, pull the stored receipt and re-derive it from the retained fields. If the bytes were kept faithfully, the recomputed hashes match to the character — that is the proof of retention. Flip one byte and the seal breaks.
Want to check it against the standalone verifier? Open the receipt verifier → and paste the receipt from Step 3 — it runs the same five checks.
Worked illustration on a synthetic batch. It shows how EU Battery Regulation / Digital Product Passport claims are graded and sealed; it does not establish conformity for any real product. Not legal, financial, or compliance advice.