Compatibility matrixstable
§6 The 1.1 draft capabilities
Every row is additive 1.1 unless marked otherwise, and every row carries the same Q2 answer: a Record using this capability fails the 1.0.1 schema and MUST declare ver_version: "1.1".
The Q1 answer for the whole section changed at the 23 August owner review, and the change is the largest single thing on this branch:
The schema-superset property is withdrawn. An earlier revision of the 1.1 draft advertised its schema as a superset of the 1.0.1 schema for every shared structure, with
ver_versionanddim/dtypeas the only differences. That property was real and it was bought by leaving encodable rules out of the schema — the binary-space constraints, the multi-segmentindexrequirement, the tolerance floor, the URI/digest couplings, and seven objects the prose closes and the schema did not. Suppressing a standard's own machine-checkable requirements to protect a mechanical upgrade path is the wrong trade.Moving a Record from 1.0.1 to 1.1 is therefore a real migration, and the obligation that replaces the superset property is that the migration be enumerated and verified:
standards/ver/1.1-draft/VER-1.1-draft.md§12.1 lists all fourteen edits with the validator failure pointer each omission produces, measured against this repository's own artifacts. `VERSIONING.md` §2.2 makes that enumeration a requirement of every minor release from now on.
So the honest Q1 answer is yes, on fourteen enumerated counts, of which the 1.0.1 golden example trips two and the 1.0.1 conformance/valid/ corpus trips five in total. The measured result:
| Artifact | Failure pointers against the 1.1 draft schema |
|---|---|
standards/ver/1.0.1/example-record.json | /ver_version, /spaces/0/reference, /spaces/1/reference — three, no more |
Eight of the ten 1.0.1 conformance/valid/ fixtures | /ver_version and one /spaces/N/reference per space — nothing else |
conformance/valid/binary-dtype.json | those, plus /spaces/0/metric and two more on /spaces/0/reference (a binary space declaring metric: "cosine" and a cosine tolerance) |
conformance/valid/redacted-with-proof.json | those, plus two on /metadata/redactions/0 and one on /metadata/normalized/Iptc4xmpExt:PersonInImage (salted_sha256 → commitment_sha256) |
tests/test_schema_versions.py regression-tested the old superset property and must be updated to test the new one — the enumerated migration — which is a tooling change, not a standards change.
Rows below that narrow at the conformance rather than the schema level say so in their impact cell and are listed again in §9.
| § | Capability | Class | Record-level impact beyond the section rule |
|---|---|---|---|
| 2.2 | provenance.registry — the registry snapshot a Record's registry-dependent values were minted against (ADR-0004 C2) | additive 1.1 (conditional requirement) | New optional object, required when the chain carries a bare action token outside the sixteen the specification defines. Unreachable for a 1.0.x Record, whose action enum is the core six |
| 2.3 | Provenance actions become an open value space with a registry (ADR-0004) | additive 1.1 | A 1.0 consumer meeting an unregistered action must treat it as opaque, not reject the Record. Three tiers now: the six core and the ten specification-registered tokens are must-understand; everything else may be opaque |
| 2.3.1 | provenance.chain[].target — asset | record, defaulting to asset (ADR-0004 C4) | additive 1.1 | New optional member. The default is what keeps every 1.0 chain event's meaning intact. A sign event's target, when stated, MUST be record |
| 2.3.2 | provenance.chain[].uri (ADR-0004 C5) | additive 1.1 | New optional member. Deliberately not digest-coupled — it names a location, not a content-addressed artifact (draft §15.3) |
| 2.3.3 | A sign chain event requires provenance.signature (ADR-0004 C5) | additive 1.1 (schema-encoded rule) | sign is a 1.1-only action value, so no 1.0.x Record can trip this |
| 2.4 | Registry mechanism drafted for perceptual algorithms, source classes, segment families | additive 1.1 | The three value spaces stay closed in the draft schema. The VER Registry document now exists (checklist row 8) and snapshot 1 seeds all three, but seeding is not opening: opening is deferred to the revision that publishes the registry, and source.class is additionally gated on its grade table being registry-backed — snapshot 1 carries that table without activating it. Drafting a mechanism changes no Record |
| 3 | Lineage: parents[] with relation, multi-parent composites, recipe_sha256 (ADR-0005) | additive 1.1 | New optional object. A 1.0 consumer sees a Record with no lineage and is not misled — absence never implies "no parents". The parent shape is the revised one: at least one globally resolvable identifier (record_uri, or {producer_id, record_id}); a bare record_id no longer qualifies (E16); pixel_hash is {value, cpnp_version} and never qualifies (E27) |
| 3.4 | The recipe envelope: media type, {recipe_version, canonicalization, steps}, x-<authority> extension keys | additive 1.1 (companion artifact) | No Record shape change. Makes "verify the recipe against recipe_sha256" actionable by saying what document is hashed. Published as standards/ver/1.1-draft/ver-recipe.schema.json; the binding is one-way — the Record schema constrains recipe_uri/recipe_sha256 and never the envelope, and a Consumer that cannot fetch the envelope is not thereby non-conformant |
| 3.5 | The named high-trust profile vera-profile-high-trust/1.1-draft: VER1606 (lineage-parent-content-hash-absent) promoted warning → error | additive 1.1 (profile, not schema) | No Record shape change and no schema change: a Record that fails high-trust is still schema-valid, because a missing parent content_hash is a weaker claim, not a malformed document. Opt-in per run (--profile high-trust); the base profile is unchanged, so no Record that was conformant becomes non-conformant unless an operator selects the stricter profile. Unreachable for a 1.0.x Record — VER1606 fires only for schema_version: "1.1-draft", so the flag is a no-op there and the run's output is byte-for-byte the default profile's |
| 4 | Model-bundle manifests: model.bundle with bundle_digest_alg + manifest_sha256; model.artifacts[]; model.checkpoint_uri (ADR-0007) | additive 1.1 | weights_sha256 is not redefined — it keeps annex E29's reading in perpetuity, comparable only within a producer, in 1.1 as in 1.0. The reproducible cross-producer pin is the new manifest_sha256. Two digests in one model object mean different things, and draft §4.2 says which is which |
| 4.2 | Hardened bundle path grammar | additive 1.1 (new construct) | bundle and artifacts[] are 1.1-only, so the grammar rejects nothing that exists. It closes ..\evil, C:\evil, a\..\evil and a trailing newline, which the earlier draft pattern accepted (finding REV-05) |
| 5 | Redaction: state REQUIRED; commitment REQUIRED for producer_performed and forbidden for upstream_withheld; salted_sha256 → commitment_sha256 + commitment_alg; the ver-redaction-commitment/1 construction (ADR-0006) | additive 1.1 (rename + version-gated requirement) | ADR-0006 is decided. For 1.1 Records the member is renamed and its preimage changes, so a 1.0.x value is not a valid 1.1 value and must be recomputed from the salt. A producer that has lost the salt must restate the entry as upstream_withheld or leave the Record at 1.0. 1.0.x is untouched: salted_sha256 stays optional there and VER1002 stays a warning |
| 5.2 | metadata.availability gains upstream_withheld | additive 1.1 (enum extension) | A sixth availability state alongside the five 1.0 ones, none of which changes meaning. It names the case Option A could not express: the Producer never received the values, so it can neither preserve them nor commit to them |
| 6 | c2pa.status gains unverifiable; machine-readable reason REQUIRED for it and forbidden otherwise; error_detail becomes optional and non-normative everywhere | additive 1.1 | A 1.0 consumer meeting unverifiable must not read it as valid. The reason enum carries the machine obligation that an earlier draft put on a human-readable string |
| 7 | Normative size limits (serialized record ≤ 10 MiB; decoded inline raw ≤ 6 MiB; decoded single vector ≤ 6 MiB) | additive 1.1 with a narrowing edge (text only) | A 1.0-valid Record above a limit is 1.1-non-conformant, not 1.1-schema-invalid: no JSON Schema keyword bounds a document's byte length, maxLength bounds base64 text rather than decoded octets, and none sums across array members. The earlier draft's 16 MiB decoded-raw cap was unreachable inside a 10 MiB document (base64 ≈ 21.3 MiB) and is corrected to 6 MiB. Referenced external bytes are governed separately and are not counted. Numbers are unratified; docs/standards/VER-size-corpus.md now measures all three against this project's own conformance corpus and finds nothing within two orders of magnitude of a budget, but that is measurement evidence and not deployment evidence, so the numbers stay proposals. VER104's defaults are aligned to this model, and on a 1.1-draft run VER105/VER106 carry the three quantities in its place (§8) |
| 8.2 | reference.set_manifest_sha256 REQUIRED, plus tolerance_cosine_p5, …_worst, tolerance_hamming_max; tolerance_cosine REQUIRED and ≥ 0.99 for float spaces | additive 1.1 (tightening, schema-encoded) | This is the migration edit every 1.0.1-valid Record in this repository needs: a reference block is a conformance claim, and a claim bound only to a URI is a claim about whatever that URI serves today. The 0.99 floor was profile-only guidance in 1.0.x (note N5) |
| 8.3 | Decoder reference corpus | additive 1.1 (deliverable) | No record shape change. Turns annex E12's PROVISIONAL state into something a producer can exit — and as of standards/decoder-corpus/1/ the exit exists and is executable |
| 9 | Per-embedding compute {runtime, runtime_version, precision, device_class} | additive 1.1 | Optional object. Makes device-dependent arithmetic (EMB-03) declarable instead of invisible |
| 10.1 | Raw segment index + by-reference carriage; index REQUIRED when a family occupies more than one segment | additive 1.1 (tightening, schema-encoded) | Multi-segment families (multi-APP1 EXIF, Extended XMP) become orderable, and a 1.0-valid multi-segment Record with no ordinals is 1.1-invalid. One conditional per family; uniqueness and contiguity of the ordinals compare two array members and stay profile-enforced |
| 10.2 | Consumed render-affecting marker on raw segments | additive 1.1 | Optional. Makes "preserved but consumed" visible in the Record (SPEC-02-core) |
| 10.3 | Availability: other key, upstream_withheld state, per-family availability_basis object with a non-empty entry REQUIRED per stripped_suspected family | additive 1.1 (with a schema-encoded conditional on the object form) | Optional object form alongside the record-scoped string. The 1.0 scope ruling (E21) stays valid, and the string form is unaffected by the conditional |
| 11.1 | kind gains joint_visual_text | additive 1.1 | New enum member. Lets CLIP/SigLIP be declared honestly for both canonical_visual and text-query embeddings |
| 11.2 | metric gains hamming, and the binary rules are encoded: binary ⇔ hamming, binary ⇒ normalization: "none", no inline vector for a binary embedding, tolerance_hamming_max REQUIRED and cosine tolerances forbidden on a binary reference | additive 1.1 (tightening, schema-encoded) | binary dtype becomes usable and its 1.0-era misdeclarations become invalid. conformance/valid/binary-dtype.json is one such Record — a binary space with metric: "cosine" — and it fails on three pointers. The ±1-expansion cosine reading is withdrawn as a conformance basis |
| 11.3 | descriptor_sha256 binding inline copies to the published descriptor; descriptor_uri ⇒ descriptor_sha256 | additive 1.1 | Optional field with a schema-encoded coupling. Makes §6.2 immutability checkable (VER402 checks the registry form today) |
| 11.4 | Duplicate space_id prohibited by the specification, not by the schema | additive 1.1 (text-level tightening) | A Record with duplicates is already non-conformant under annex E18. What 1.1 changes is the status of the prohibition: it becomes normative specification text where it was profile-only in 1.0.x. JSON Schema has no key-uniqueness keyword over an array of objects, so enforcement remains in the profile validator (VER401) for the life of VER 1.x. There is no encoding to move it into, so there is nothing to vote on — draft §15.4(a) records it as a limit of the language rather than a compatibility trade |
| 11.5 | fused spaces: model optional, recipe part of space identity | additive 1.1 (relaxation + text-level tightening) | Relaxes model for derived spaces; makes recipe changes require a new space_id. The identity rule is prose, not schema. Existing fused Records that carry model stay valid |
| 11.6 | space_id pattern: first authority label widened, semver extended | additive 1.1 (pure widening) | The first label may now carry interior and trailing hyphens; later labels keep the 1.0.1 sub-pattern exactly, sloppy edges included — this is the one place where the widening is genuinely pure, and it stays that way because narrowing an edge hyphen buys nothing; the version part gains optional lowercase prerelease and build parts. Every 1.0.1-legal space_id is 1.1-legal. A 1.1-legal space_id may fail the 1.0.1 pattern, which is why the widening is not back-published: relaxing a pattern in a patch release produces 1.0.1-valid Records that 1.0.0 rejects |
| 12 | embedding.dim/dtype REQUIRED for 1.1 Records (ADR-0008) | additive 1.1 (version-gated requirement) | Required only where ver_version is "1.1". Because the draft schema pins ver_version to a const, the version const already partitions the two document sets, so the flat required entry is the gated form — an explicit if/then on a sibling property would be redundant. A multi-version schema would need the conditional. A 1.0 Record omitting them stays valid forever under 1.0.x; the 1.0 profile warns (VER606). See `VERSIONING.md` §2.2 |
| 13 | Redaction reaches derived artifacts (ADR-0009) | additive 1.1 (draft) | 1.1-draft only. A Record MUST NOT carry an artifact derived from a value it redacts (§5.4): the mapped contextual embedding goes (VER1011), the fused consumer of it goes, no member restates the value. No schema member changes; no 1.0.x Record is affected; a 1.1-draft record previously silent can now draw VER1010/VER1011/VER1208, which is the draft tightening before ratification exactly as designed. Q1 no; Q2 no |
| 13 | Record-level extensions: {}, reverse-DNS keys | additive 1.1 | Optional object. The alternative was vendors mutating closed objects, which no consumer can survive |
| 14.1 | VER-F: the wire strategy — stable NSID across 1.x, REQUIRED verVersion/cpnpVersion, closed identity- and security-critical structures, one namespaced ext map with MUST-ignore-unknown | additive 1.1 (wire profile), with a breaking / major reserved for a future wire major | No Record-plane impact. The earlier draft position — open every lexicon object — is rejected: an unrecognised member sitting next to pixelSha256 with no artifact saying whether it matters is the same defect class as an unconstrained hash field. A new NSID is minted only for a breaking wire major, when VER-F 1 and VER-F 2 coexist for a stated dual-publish window. Stated once for rows 14.1–14.8: the artifact is standards/ver/1.1-draft/wire-profile/ (revision: 2, same NSID), and §8 classifies the wire-plane change it makes |
| 14.2 | VER-F: verVersion/cpnpVersion propagation duties | patch-compatible correction (wire profile) | No Record-plane impact. Defaulting cpnpVersion is how consumers compare hashes across universes |
| 14.3 | VER-F: constraint parity with the Record schema | patch-compatible correction (wire profile) | No Record-plane impact. Closes the gap that made WIRE-06 remotely exploitable |
| 14.4 | VER-F: perceptual-digest extensibility | additive 1.1 (wire profile) | No Record-plane impact |
| 14.5 | VER-F: privacy-mode semantics, including vector withholding | additive 1.1 (wire profile) | No Record-plane impact. Gives hashes_only a consumer obligation |
| 14.6 | VER-F: tombstones and retraction | additive 1.1 (wire profile) | No Record-plane impact. Also retires the 52-bit rkey truncation |
| 14.7 | VER-F: signed wire records and trust tiers | additive 1.1 (wire profile) | No Record-plane impact. Record signing (annex E17) is the mechanism |
| 14.8 | VER-F: lexicon and record-plane divergence | editorial (wire profile) | No Record-plane impact. The wire-plane half is published; the implementation half is not, so §14.1 item 5's "both normative artifacts resolved in the same revision" is not yet met — services/verd/ still defaults the version fields, still emits the named phashDct64/pdq slots, and models a third privacy mode, public_vector, that this revision does not define |
Not in 1.1, recorded as decisions rather than oversights (1.1 draft §16, all breaking / major): orientation-invariant pixel_hash; a pinned reference CMM; honouring gAMA/cHRM/APP14/EXIF ColorSpace; renaming the iptc availability key; removing binary from dtype or platform from the conflict sources. Each requires a new pixel_hash universe or a removal.
The seven accidentally-open objects are not in that list. They are classified once, in §2 — patch-eligible, deferred from 1.0.1 to keep the delta surgical, and closed in the 1.1 draft under the VERSIONING.md §2.3 carve-out, carried as row 6 of the 1.1 ratification checklist where the vote is taken.