jouleclaw-compliance: no ESPR record on an AI service passport #441
2026-10-22
jouleclaw-compliance: no ESPR record on an AI service passport
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 5s
jouleclaw public surface must stay documented / Public-surface audit (jouleclaw-rs) (pull_request) Successful in 1m1s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 46s
standards workspaces build + test / jouleclaw-rs (-nodebug, jouleclaw/jouleclaw-rs, -p jouleclaw-energy --features rapl,nvml, jouleclaw-rs, linux-arm64, -C target-feature=+fp16) (pull_request) Successful in 2m25s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 1m11s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 8m17s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 2m57s
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]>