A public, genuinely offline conformance validator

[LKSNDRTMLKV]

A single artefact a third party can run against their own output, with no Odal service, no account, no network, and no product source. Exit 0 conformant · 1 findings printed · 2 usage error.

Why

We have the capability scattered and slightly misnamed. What ships today is node-backed verification — useful, and not an offline verifier. This is where that naming gets reconciled: either we have an offline verifier or we do not say we have one.

Commercially, this is the artefact handed to a manufacturer's IT department. It converts "trust our platform" into "check us yourself, and check your own data while you are at it" — the open-core thesis as a downloadable file.

Distribution

A statically-linked binary, odal-verify, published per platform and installable with cargo install. Not a service, not a container, no configuration file, no telemetry. If a door needs network access it is off by default and says so.

Rust, reusing dpp-core, so the validator and the product share one implementation of every check. A separate implementation would drift, and the drift shows up as us telling a customer their valid passport is invalid.

Doors

Ship only the doors that exist.

Door	Checks	Available
schema	passport JSON against the versioned schema for its product group	now
signature	JWS over the canonical form; resolves the issuer did:web only if --online, else takes a key file	now
disclosure	the signature attached covers exactly the body present	now
gs1	Digital Link grammar and check digits	with #79
aas	AAS Environment against the vendored AAS v3 schema	later
untp	UNTP DPP credential against its schema	later
sdjwt	disclosure reconstruction and signature	with #80

The disclosure door is the interesting one and the one no competitor can copy without our disclosure-set model. It answers "does the proof attached to this document actually cover this document?" — the question whose wrong answer we found in our own publish path.

Honesty constraints

• Output states what was checked, against which schema version, read on which date
• A pass prints "validates against schema X vN" — never "conformant", never "compliant", never "EU-ready"
• Failures print the JSON pointer, the expectation and the actual value. A validator that says "invalid" without saying where is a support-ticket generator
• Where a door is non-normative, the output says so on every run, not in a footnote

Merge gate

• A clean-room invocation — container with the binary and a passport file, no network, no Odal service — exits 0 on a valid passport and 1 on a mutated one
• Every door has a positive and a negative fixture
• Exit codes are exactly 0/1/2, asserted, since scripts will depend on them
• The disclosure door fails on the specific historical defect: a body carrying a signature that covers a different field set — that bug becomes a permanent regression test
• --online is genuinely optional: with networking disabled every other door still runs

Ship deterministic sample passports per product group, so a user can run the tool successfully before pointing it at their own data.

Scope boundary

Structural and cryptographic validation only. Not a compliance check, not a determination, not a substitute for the rules engine — a passport can validate perfectly and still describe a non-compliant product. Say so in the tool's own help text.

Note: an earlier internal write-up covers the same binary from the commercial angle. Reconcile the two before building — two plans for one artefact is how they drift apart.