§1 Scope and compatibility posture

VER 1.1 adds representational capacity to the VER Record. It changes no algorithm: CPNP-1 is untouched, cpnp_version remains "1.0" in every 1.1 Record, and a 1.1 Record's pixel_hash lives in the same universe as a 1.0 Record's. Any change to CPNP is CPNP-2, is a new pixel_hash universe under 1.0 §13, and is therefore VER 2.0 with a dual-publish migration window — not this document.

Moving a Record from 1.0.1 to 1.1 is a real migration, not a version bump. An earlier revision of this draft claimed the 1.1 schema was a superset of the 1.0.1 schema for every shared structure, with ver_version and dim/dtype as the only differences. That property was purchased by leaving encodable rules out of the schema, and the price was the wrong way round: the standard's own machine-checkable requirements were being suppressed to protect a mechanical upgrade path that nobody had asked for. The superset goal is withdrawn. Every rule that JSON Schema can express is now expressed (§15), seven objects left open by oversight in 1.0.x are closed (§15.2), and integrity-relevant URIs now require the digests that make them verifiable (§15.3).

What that costs a producer is stated exactly, and empirically, in §12.1: a 1.0.1-valid Record needs a bounded, enumerable set of edits, and the section lists the failure pointers a real validator emits for each one. What it buys is that a 1.1 Record's conformance is checkable by a schema validator instead of being asserted in prose that no tool reads.

• ver_version becomes "1.1". This is the wire signal that a Record MAY carry the structures below, and that it has been brought up to the 1.1 rules. A Record that uses none of the new capabilities and has not been migrated SHOULD continue to declare "1.0", so that 1.0 consumers accept it.
• **A 1.1 Record is judged by the 1.1 schema; a 1.0.x Record is judged by the 1.0.x schema.** Nothing in this document re-grades a published 1.0 Record, and nothing in it may be applied retroactively. COMPATIBILITY.md §6 carries the per-capability classification.

1.1 What a 1.0 consumer sees

A consumer implementing only VER 1.0 and encountering a 1.1 Record will reject it, because the 1.0 schema's root is closed and ver_version is const: "1.0". That is intended: a 1.1 Record may carry lineage, redaction commitments, and registry-extended actions whose meaning a 1.0 consumer cannot evaluate. Version negotiation, not silent tolerance, is the migration mechanism. Producers that must reach 1.0 consumers dual-publish: a 1.0 Record without the new members and a 1.1 Record with them, sharing content_hash.