Schema description prose is unaudited for fabricated regulatory content

[LKSNDRTMLKV]

The gap

Every JSON schema under crates/dpp-domain/schemas/ carries description fields, and those descriptions make regulatory assertions — act numbers, adoption dates, effective dates, product-class scope, annex references. None of them has been checked against primary text.

This is not hypothetical. Two electronics schema description fields once asserted an adoption date, an effective date, three named priority product classes and a phase-two date for an act that does not exist. They shipped to crates.io. A released crate version cannot be unpublished.

Why prose specifically

Every gate step this repo runs reads Rust. cargo doc, clippy, the test suite, cargo audit — none of them reads a description string. Every recorded instance of this failure class has been in prose or data: a module doc, a schema description, a README paragraph, a JSON source field.

So the defect is not that someone was careless. It is that the one part of the crate making the most load-bearing regulatory claims is the one part nothing checks.

Scope

Mechanical, and that is the appeal:

1. Extract every description from all schema files (28 today, across 11 sectors).
2. For each, identify whether it makes a checkable regulatory assertion — an act number, a date, a threshold, a scope claim, an annex citation.
3. Verify each against primary OJ text. CELEX PDF plus text extraction is more reliable than the EUR-Lex HTML, which truncates under JS.
4. Correct what is wrong; mark what is secondary-sourced rather than encoding it as fact.

What would make this stick

A description that cites its basis is checkable by the next reader; one that asserts a bare fact is not. Worth considering whether descriptions carrying regulatory claims should be required to name the instrument and article they come from — which turns a future check from research back into a lookup.

Not in scope

The Rust-side constants. Those have a separate provenance story and several trace to verified research already. This is specifically about the prose that ships beside them.

[LKSNDRTMLKV]

Recording a consumer that is now waiting on this audit.

dpp-engine v0.12.0 ships GET /integrator/api/v1/schemas[/{sector}[/{version}]],
serving these schemas over HTTP for SDKs and dashboards to pre-validate against.
It strips every description before serving, precisely because of this
issue: the machine-readable contract goes out, the unaudited regulatory prose
does not.

That is a holding position, not the end state. When the audit lands, the
stripping comes out — it is one function (strip_descriptions) and one call
site in crates/dpp-integrator/src/handlers/schemas.rs, marked as temporary in
the module docs with a pointer back here.

So the audit now has a second beneficiary beyond the crate itself: until it is
done, an SDK cannot see the field documentation at all, which is a real cost on
top of the risk this issue describes.

Two things worth knowing for whoever picks it up:

• Scope check, measured today: 28 schema files across 11 sectors, and 165
  description values containing something that looks like a checkable
  regulatory assertion (an act number, a directive, an annex, a four-digit year,
  or an article reference). That is the upper bound on the research, not the
  count of wrong ones.
• title is not in scope and does not need to be. All 28 are short labels
  of the form Odal Node — Battery Sector Data (v2.6.0), none over 60
  characters, none making an assertion. The engine serves them unchanged.