The 1.1 draft profile
--schema 1.1-draft loads standards/ver/1.1-draft/ver-record.schema.json and switches on the twenty-six rules marked ¹ above. The report says so: profile becomes vera-profile/1.1-draft, because the two runs ask different questions and one identifier for both would make two reports incomparable.
The draft is never the default. A draft is a moving target — VER-1.1-draft.md §7 says its own numbers require ratification — so a caller who names no version is judged against the newest published release and has to ask for the draft by name.
Every 1.1 rule is gated on the selected schema version, not on the record's ver_version. The operator chose which standard to audit against; reading that choice out of the document under test would let the document decide which rules apply to it. The consequence that matters: 1.0.0 and 1.0.1 output is byte-for-byte what it was, and tests/test_record_1_1_profile.py runs the 1.0.1 suite's zero-issue record to prove it.
Sizes change hands at 1.1 (§7). VER 1.0 sets no normative limit, so the three payload quantities are advisory there and share VER104. §7 states them as limits, so a 1.1-draft run reports the same three quantities as VER105 (error) and adds the two entry-count SHOULD NOTs as VER106 (warning) — spaces[]/embeddings[] above 64 entries, and provenance.chain[] above 1024. VER104 does not fire on a 1.1-draft run at all. One code cannot carry both readings: severity is a fixed property of a code in this registry, and re-grading VER104 would be a compatibility event that also silently re-graded every 1.0.x report already in circulation.
--registry SNAPSHOT.json resolves bare provenance.chain[].action tokens against a VER Registry snapshot (ADR-0004). The rule is deliberately three-valued, and the middle value is the point of it:
| the record | the run | finding |
|---|---|---|
a bare token outside the sixteen §2.3 defines, no provenance.registry | any | VER1205 (error) — nothing could ever resolve it |
the same token, provenance.registry present, no --registry | any | VER1206 (warning) — membership was not checked; the record stays conformant |
the same token, --registry supplied, token is an active entry | — | silent |
the same token, --registry supplied, token absent or not active | — | VER1205 (error) |
Nothing is fetched. §2.3 states the reason outright: a consumer that rejected a record because it could not reach a registry "has converted an extensible value space back into a closed enum, unilaterally". An unreadable snapshot degrades to VER1206 rather than to VER1205 — "I could not parse your file" is not "your token is unregistered".
--lineage-peer RECORD.json (repeatable) supplies the records over which VER1604 searches for a lineage cycle. A record does not carry its own address, so a peer is identified by the two things the standard does make globally resolvable: its identity.content_hash.value, and any chain event uri whose target is record — which is what §2.3.2 adds uri for. pixel_hash is deliberately not an identifier here: annex E27 makes it a rendered-identity grouping key that resolves to a candidate and never to an identity, so matching two records by it would invent cycles that do not exist. With no peers there is nothing to walk, and silence means not established rather than no cycle. A dangling record_uri is accepted with no code at all (§3.5 fixture 8): making network reachability part of conformance would repeat VER1303's mistake.
--profile high-trust promotes exactly VER1606 — a lineage parent carrying no content_hash — from warning to error, and changes nothing else. §3.5 makes that promotion the entire content of the named high-trust profile. It is applied to the issues in one report and never to CODES: severity is a property of the code, and mutating the registry would make one caller's strictness choice visible to every other caller in the process.
Digest recomputation needs rfc8785. VER407, VER411 and the JCS-based comparisons behind them use the same optional dependency stage 15 does. Where it is absent they report nothing rather than falling back to json.dumps(sort_keys=True), which would compute a digest over a serialization RFC 8785 does not define and then accuse a producer who canonicalized correctly. Install the signatures extra to have them run.
Four rules that read 1.1 shapes
Four existing codes describe things the 1.1 draft gave a new shape to. None changes its meaning, its severity or its 1.0.x behaviour; each reads the additional shape only under --schema 1.1-draft. Without these, the profile would report the draft's own published example record as non-conformant — which would be a statement about this validator, not about the example.
| Code | 1.0.x | Additionally, under 1.1-draft |
|---|---|---|
| VER1002 | unchanged, permanently a warning | does not fire. salted_sha256 does not exist at 1.1 — ADR-0006 renamed and reshaped it as commitment_sha256 + commitment_alg, and the 1.1 schema closes metadata.redactions[] without it, so a record could not be VER1002-clean and VER201-clean at once. VER1006 and VER1007 are its 1.1 successors |
| VER701 / VER702 | canonical_visual needs a visual space, contextual a text one | joint_visual_text also satisfies both — the 1.1 schema calls that kind "legal for canonical_visual embeddings AND for text-derived contextual embeddings". VER703 is not widened: one model embedding two modalities is not two geometries combined (annex E20). The 1.0.x reading is left as it is on purpose — the 1.0.x kind enum has no such value, so such a record is already schema-invalid there, and widening a published release's profile would re-grade records already validated against it |
| VER901 | a basis is the record-scoped availability_basis string | the per-family object form (§10.3) is also a basis, checked per suspected family. Whitespace is still not a basis, in either shape |
| VER1001 | one pairing: a ledger entry ⇔ a family marked redacted | two pairings, which §5.2 assigns to VER1001 by name — producer_performed ⇔ redacted, and upstream_withheld ⇔ the availability state of the same name. Running only the 1.0.x arm would read a ledger of honest upstream_withheld entries as a ledger with no redacted family |
tests/test_record_1_1_profile.py pins both sides of each row, and test_the_published_1_1_example_record_is_conformant pins the outcome: the draft's example record validates with the single warning VER308 (it claims L3 and carries no signature), and stays conformant under --profile high-trust.