jouleclaw-compliance: no ESPR record on an AI service passport #441

Merged

dcharlot merged 1 commit from fix/passport-no-espr into main 2026-11-01 09:38:43 -05:00

Conversation 0 Commits 1 Files changed 3 +34 -19

dcharlot commented 2026-10-22 07:27:44 -04:00

Owner

Copy link

The AI Service Passport's compliance record carried an ESPR digital product passport: a URL and a bare registry_submitted: bool. ESPR applies to "any physical goods that are placed on the market or put into service" (Regulation (EU) 2024/1781, Art. 1(2), read from the Official Journal text). This passport describes an inference service. So the record claimed a regime that cannot apply, through a flag nothing checked. The 2026-10-19 sweep raised this as item 21 ("Retire EsprCompliance.registry_submitted").

Changes

• EsprCompliance and ComplianceRecord.espr_dpp are removed. The record's doc says why. It also says the hardware a service runs on is a physical good, so where a delegated act requires a product passport, that passport belongs to the hardware.
• A passport written with the record still reads, and the member is dropped. A seal taken over the old shape covered that member too, so sealed_hash of the re-read passport does not reproduce it. The doc says to check such a seal against the original bytes.
• EsprReport, a report shaped for physical products (repairability, recyclable materials), now says it is for a physical product rather than "product / model".

Nothing outside the crate constructs or re-exports the removed type.

Verification (build host)

• cargo test -p jouleclaw-compliance: 85 pass. cargo clippy -p jouleclaw-compliance --all-targets --no-deps -D warnings is clean.
• A new test feeds a passport that still carries an ESPR record. It must read, and the record must leave nothing in what is sealed. A mutant marking the record deny_unknown_fields fails that test.
• Public-name and spec-reference checks are clean. The comparative-prose script, run on these files, flags one test comment ("Unclaimed, every method builds."). That comment is already on main and is not promotional.

🤖 Generated with Claude Code

The AI Service Passport's compliance record carried an ESPR digital product passport: a URL and a bare `registry_submitted: bool`. ESPR applies to "any physical goods that are placed on the market or put into service" (Regulation (EU) 2024/1781, Art. 1(2), read from the Official Journal text). This passport describes an inference *service*. So the record claimed a regime that cannot apply, through a flag nothing checked. The 2026-10-19 sweep raised this as item 21 ("Retire `EsprCompliance.registry_submitted`"). ## Changes - `EsprCompliance` and `ComplianceRecord.espr_dpp` are removed. The record's doc says why. It also says the hardware a service runs on is a physical good, so where a delegated act requires a product passport, that passport belongs to the hardware. - A passport written with the record still reads, and the member is dropped. A seal taken over the old shape covered that member too, so `sealed_hash` of the re-read passport does not reproduce it. The doc says to check such a seal against the original bytes. - `EsprReport`, a report shaped for physical products (repairability, recyclable materials), now says it is for a physical product rather than "product / model". Nothing outside the crate constructs or re-exports the removed type. ## Verification (build host) - `cargo test -p jouleclaw-compliance`: 85 pass. `cargo clippy -p jouleclaw-compliance --all-targets --no-deps -D warnings` is clean. - A new test feeds a passport that still carries an ESPR record. It must read, and the record must leave nothing in what is sealed. A mutant marking the record `deny_unknown_fields` fails that test. - Public-name and spec-reference checks are clean. The comparative-prose script, run on these files, flags one test comment ("Unclaimed, every method builds."). That comment is already on main and is not promotional. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-22 07:27:44 -04:00

jouleclaw-compliance: no ESPR record on an AI service passport ... 58273f374e

The AI Service Passport's compliance record carried an ESPR digital product
passport with a bare `registry_submitted: bool`. ESPR applies to physical
goods placed on the market or put into service (Regulation (EU) 2024/1781,
Art. 1(2)); a passport here describes a service, so the record claimed a
regime that cannot apply, under a flag nothing checked. It is removed. The
hardware a service runs on is a physical good, and its passport, where a
delegated act requires one, is the hardware's.

A passport written with the record still reads, and the member is dropped.
A seal taken over the old shape does not re-derive from what is read; the
record's doc says to check it against the original bytes.

EsprReport, a product-shaped report, now says it is for a physical product
rather than "product / model".

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit d03f40e6e9 into main 2026-11-01 09:38:43 -05:00

dcharlot referenced this pull request from a commit 2026-11-01 09:38:45 -05:00

Merge pull request 'jouleclaw-compliance: no ESPR record on an AI service passport' (#441) from fix/passport-no-espr into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!441

No description provided.