Skip to content

docs: correct the regulatory citations, security-property claims and registry status - #15

Open
LKSNDRTMLKV wants to merge 13 commits into
mainfrom
docs/claim-families
Open

docs: correct the regulatory citations, security-property claims and registry status#15
LKSNDRTMLKV wants to merge 13 commits into
mainfrom
docs/claim-families

Conversation

@LKSNDRTMLKV

Copy link
Copy Markdown
Member

Corrects roughly twenty published claims that primary text or engine source contradicts. Grouped by what each was checked against rather than by severity, because that is what makes the pass reviewable: one family, one source.

Contains #13 and #14 and PR #10 as merges — it needed PR #10's access-control rewrite in place to scope the remaining vocabulary work. Review those first; this diff is the four claim families on top.

Family A — regulatory citations, checked against the OJ texts

Recycled-content shares cited Annex X; Annex X is the due-diligence raw-materials list. The correct basis is Art. 8(2)/(3) cross-referenced to Annex VIII. Same wrong annex had already shipped once elsewhere.

An A–E carbon-footprint class that does not exist in law — Art. 7(2) defers the classes to an unadopted act and requires the scale to be revised every three years, so neither the labels nor how many there are is settled.

Battery categories listed a subset as peers and omitted SLI. Art. 1(3) fixes a closed set of five; the tie-break rule ("strictest requirements apply") only works over a closed set, and stationary storage sits inside industrial rather than beside it.

The back-up duty was attributed to Art. 9 with an invented "certified" qualifier. It is Art. 10(4), and the text says "digital product passport service provider".

Retention was given as "10 to 20 years". Art. 9(2)(i) sets no figure — "at least the expected lifetime of a specific product". Nothing in the verified set is 20 years.

Construction, detergent, toys and tyres all had wrong or vague dates. Now 8 Jan 2027, 23 Sep 2029, 1 Aug 2030 and "labelling in force, no DPP mandate" respectively.

And the opening claim that "the first product-group delegated acts started landing immediately" — no Art. 4 delegated act has been adopted for any product group.

Family B — security properties, checked against engine source

In all four cases the code's own comment was more accurate than the documentation of it, so the fix was to quote the source.

The sandbox does not deny "system clock or randomness": it grants both. The clock is pinned to one instant per invocation so a determination cannot vary with the time it ran; randomness is real OS entropy, deliberately not pinned. Filesystem and sockets genuinely are denied.

"The engine implements no cryptography of its own" — it hashes API keys and admin passwords with SHA-256 and compares in constant time.

"An application role that cannot delete rows" — it holds one sanctioned DELETE grant, on the import-job table.

"As each delegated act takes effect, the determination switches on" describes an automatic date-aware gate. There isn't one; a maintainer flips a manifest status and it moves with a release.

Family C — registry status

The site said the registry's API "is being defined" and "remains unpublished". It went live 20 July 2026.

Correcting that alone would have replaced a stale claim with an optimistic one, so the page now also names the two blockers that stand between "live" and a battery registration succeeding: the semantic catalogue is undefined, and the registry caps a unique product identifier at 50 characters where ours runs to 65.

Two dates were deliberately not published. The implementing act's dates are secondary-sourced in our own research, and the enrolment evidence requirement is marked "reportedly". Both are stated without the unverified specifics. A secondary-sourced claim published as bare fact is the same defect as an invented one.

Family D and E

Five remaining places used an access-tier vocabulary for a model the code does not have. And the strongest claim on the site — "nothing for an operator, or for us, to hand over later" — is false in a way that reads as scrupulous: the file is discarded, but the passport and the import job's per-row findings survive. Both locations now distinguish the file from the record derived from it.

Verification: build green · check 0/0/5 · 748 links resolve · leakage clean · spec matches.

ESPR Article 10 is Requirements for the digital product passport and defines no tiers; access is Art. 11(b), free of charge, with the actor-to-data mapping delegated per product group under Art. 9(2)(f) and no such act adopted yet, so the public Public/Restricted/Private tier page was wrong at its premise and is replaced by the Battery Art. 77(2) lattice plus the constraints common to every regime.
…ate per-passport-per-day count with no scanner-identifying field
…ng a removed product-category schema and an internal decision-record reference from published content
…d act that does not exist, and correct the ESPR sector table's electronics basis and unsold-goods article
…ne, and give the docs site the headers and robots file the landing site already had
# Conflicts:
#	site/dpp-docs/src/content/docs/regulatory/electronics.mdx
…istry status and access vocabulary against primary text and engine source
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying odal-node-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: ff5e7bb
Status: ✅  Deploy successful!
Preview URL: https://3430eac9.odal-node-docs.pages.dev
Branch Preview URL: https://docs-claim-families.odal-node-docs.pages.dev

View logs

@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying odal-node-landing with  Cloudflare Pages  Cloudflare Pages

Latest commit: ff5e7bb
Status: ✅  Deploy successful!
Preview URL: https://eec1b564.odal-node-landing.pages.dev
Branch Preview URL: https://docs-claim-families.odal-node-landing.pages.dev

View logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant