1.1-draft fixtures

Unratified. Everything in this section describes standards/ver/1.1-draft/, which is a draft: its numbers, its codes and its schema may change before ratification, and no interoperability claim may rest on a fixture here. The 1.0.1 fixtures are unaffected by all of it — a 1.1 rule fires only when the run selected 1.1-draft, and the two sets share a manifest without sharing a single expectation.

The schema axis

"schema": "1.1-draft" on a manifest entry does two things at once: it validates the record against standards/ver/1.1-draft/ver-record.schema.json, and it switches on the twenty-six profile rules gated on that release. Those two halves are why a 1.1 fixture cannot be expressed as an also run on a 1.0.1 one — the record bodies differ (ver_version "1.1", members 1.0.x has no place for), not just the options.

Two consequences are worth stating because their opposites look reasonable:

• VER104 never fires on a 1.1-draft run, and VER105/VER106 never fire on a 1.0.x one. Section 7 of the draft makes the same three payload quantities normative that 1.0 leaves advisory, and a severity that changed with the selected release is not something one code can express. Exactly one of {VER104} and {VER105, VER106} is reachable per run.
• VER1002 never fires on a 1.1-draft run either. salted_sha256 does not exist at 1.1 — ADR-0006 renamed and reshaped it — so no record could be VER1002-clean and VER201-clean at once. Its 1.1 successors are VER1006 and VER1007, and both have fixtures.

What is here

Draft §3.5 requires eight lineage fixtures before §3 can ratify. Three of them are valid/ records (1, 2, 8); the other five are the invalid/ fixtures for VER1601 through VER1605, in the order §3.5 lists them.

Running them

ver-validate --schema 1.1-draft conformance/valid/l3-full-1-1.json
ver-validate --schema 1.1-draft --registry conformance/registries/test-registry-snapshot.json \
             conformance/invalid/ver1205-bare-action-token-unregistered.json
ver-validate --schema 1.1-draft \
             --lineage-peer conformance/lineage-peers/lineage-cycle-peer.json \
             conformance/invalid/ver1604-lineage-cycle.json
ver-validate --schema 1.1-draft --profile high-trust \
             conformance/invalid/ver1606-lineage-parent-content-hash-absent.json

Each of the four flag-gated fixtures carries an also run without its flag, so the corpus states what the flag is: --registry turns VER1206 into VER1205 or into silence, --lineage-peer is the only thing that can make a cycle visible, and --profile high-trust turns the VER1606 warning into an error and does nothing else.

The lineage-peers directory

lineage-peers/ holds records supplied to a run with --lineage-peer. They are inputs, not fixtures: they have no target_code, no expected result, and no manifest entry of their own, which is why they are not in valid/ — the manifest-and-disk agreement check covers valid/ and invalid/ only, and a peer registered as a fixture would be claiming a verdict nobody computed.

A peer matters because VER1604 walks a graph and this validator fetches nothing. A record is identified in that graph by its identity.content_hash.value (the content-hash edge) and by any uri on a chain event whose target is record (the record-URI edge). pixel_hash is deliberately not an identifier: 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 merge unrelated assets into one node and invent cycles that do not exist. The cycle fixture uses one edge of each type, so a single run exercises the detection rule on both.

The corpus-local registry snapshot

registries/test-registry-snapshot.json is a corpus-local stand-in for a VER Registry snapshot. It is not standards/registry/snapshots/1/registry.json and it must never be substituted for it: it carries zero trust, exactly as keys/corpus-signing-key.pub.pem does, and nothing may cite it as evidence that any token is registered anywhere.

It exists for one reason. The corpus's expected codes must not depend on a governed artifact that changes on its own schedule. A fixture pinning "this token is active" against the published registry would break the day the registry deprecated that token — and deprecation never invalidates history, so the fixture would be wrong about the standard rather than the other way round. The rule under test only asks whether a snapshot lists a token as active, so any spelling works; this one lists watermark and nothing else, which makes watermark resolvable and sidecar_merge a token that was never registered.

provenance.registry.sha256 in the two fixtures that name it is the real SHA-256 over the RFC 8785 JCS serialization of that snapshot document, and moves if the snapshot is edited.

Digests, and how each was constructed

Rules 3 and 4 apply unchanged. Stand-in values use the 1.1 preimage sha256("ver-conformance-corpus/1.1-draft <purpose>"). Four values are not stand-ins at all and recompute from what the record itself carries — three of them in one line each, and commitment_sha256 below:

import hashlib, rfc8785
jcs = lambda value: hashlib.sha256(rfc8785.dumps(value)).hexdigest()
manifest_sha256   = jcs({"files": files})                                  # §4.2
descriptor_sha256 = jcs({k: v for k, v in space.items() if k != "descriptor_sha256"})
recipe_sha256     = jcs(envelope)                                          # §3.4

valid/lineage-composed.json's envelope is exactly:

{"recipe_version":"1","canonicalization":"rfc8785-jcs",
 "steps":[{"op":"canvas","width":8,"height":6,"background":"#000000"},
          {"op":"place","source":"parent-a","x":0,"y":0},
          {"op":"place","source":"parent-b","x":4,"y":0}]}

and it validates against standards/ver/1.1-draft/ver-recipe.schema.json. The same digest is the compose event's params_sha256 and the last path segment of recipe_uri, so the three are cross-checkable.

A bundle's per-file sha256 and byte_length recompute too: each file's bytes are the ASCII string ver-conformance-corpus/1.1-draft bundle-file <path>, and each model.artifacts[] entry's are ver-conformance-corpus/1.1-draft artifact <name>. The one exception is valid/l3-full-1-1.json, which is the published example and carries the example's own constructions — standards/ver/1.1-draft/RELEASE.md documents every one of them, including its salt. Nothing in the corpus is a plausible-looking hex string.

commitment_sha256 is the §5.3 construction, computed:

commitment_sha256 := SHA-256( "VER-REDACTION-COMMITMENT-1"
                            ‖ uint64be(len(salt))          ‖ salt
                            ‖ uint64be(len(JCS(value)))    ‖ JCS(value) )

with JCS(value) the RFC 8785 form of the value as it appeared in the normalized view, so a string is hashed with its quotes. The corpus salt is sha256("ver-conformance-corpus/1.1-draft redaction-salt <field>") — 32 octets, above the 16-octet floor. That recipe is published here and only here. The salt appears in no record, in no extensions block, and in no fixture: its absence from the record is the entire mechanism, and a real deployment's salt is never written down anywhere a reader of the record can reach. A commitment binds the Producer to a value no later than signing time; it is not evidence that the value ever existed in the asset.

invalid/ver105 is 1.5 MB, deliberately

The cheapest way to trip a single §7 quantity is quantity (c), a single decoded inline vector above 6 MiB. An inline JSON array is charged at the documented proxy of 8 bytes per component regardless of dtype, so the limit is reached at 786,433 components — about 1.5 MB of text when the components are zeros. Quantity (b) would need roughly 8 MB of base64, and quantity (a) a 10 MiB document. The array is written on one line, as invalid/ver104 is.