§1 Status, scope, and how to read this annex

VER 1.0 was published as three artifacts: the specification document (VER-1.0-Specification.docx), the companion JSON Schema (ver-record.schema.json), and the golden example (example-record.json). Those three files, exactly as published, are frozen at standards/ver/1.0.0/ and are never edited. A published specification document is not rewritten in place; corrections ship as an annex.

This annex is that annex. It is normative. Where this annex and the 1.0.0 specification text disagree, this annex governs for any Record claiming conformance to artifact release 1.0.1 or later within VER 1.x.

Three properties of this release are load-bearing and are stated here once. Each is stated with its exceptions, because a compatibility property with an undisclosed exception is worse than no property at all.

1. The wire version does not move. Records corrected under this annex still carry "ver_version": "1.0". 1.0.1 is a release version over the published artifact set, not a record format version. A consumer written against 1.0.0 parses every 1.0.1 record without change. This property has no exceptions.

1. CPNP-1's algorithm is unchanged; five items select among readings of it. cpnp_version remains "1.0", and no item in this annex alters a step, a constant, or the preimage of the Canonical Pixel Normalization Pipeline. But five items — E3, E6, E7, E8, E9 — each resolve an ambiguity where two defensible readings of the 1.0.0 prose produced different Canonical Buffers for the same Asset.

Resolving such an ambiguity necessarily selects one reading. The consequence is stated plainly and identically in each of those five items:

Records produced under a non-selected reading were never interoperable and are non-conformant under this annex. Their pixel_hash values are withdrawn, not recomputed — there is no migration that maps an old value onto a new one, because the two values were never values of the same function. No Record produced under a selected reading changes.

E8 goes one step further: for an Asset carrying a present-but-unusable ICC profile it withdraws canonical identity entirely, because every available reading of 1.0.0 produced an identity no other implementation could reproduce. See E8's own reconciliation note.

Every other item in this annex leaves pixel_hash untouched.

1. **Every correction is a tightening or a disambiguation, never a new capability — with exactly one deliberate relaxation.** No item here adds a field, a value, or an ability that a 1.0.0 record could not already express. The one exception is E15: §7.1's L1+ byte-exact-preservation MUST is made subordinate to §7.5 redaction, so a redacting Producer that omits a sensitive segment is conformant under 1.0.1 and was not conformant under a literal reading of 1.0.0 §7.1. That is the single direction in which 1.0.1 relaxes 1.0.0, and it is recorded as such in COMPATIBILITY.md and in this release's RELEASE.md. Additive work is drafted separately in standards/ver/1.1-draft/ and is not part of this release.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119 and RFC 8174, as in the base specification (§2).

1.1 Item format

Each item carries five parts, and five items carry a sixth:

• [1.0.0 text] — the published text at issue, quoted verbatim.
• [Defect] — what is wrong with it, in operational terms.
• [Correction] — the corrected or clarifying normative text. This is the text that governs.
• [Identity impact] — present on E3, E6, E7, E8 and E9 only: the five items that select among readings of 1.0.0 which produced different Canonical Buffers. It states which Records are affected, and how. Its absence from an item means that item moves no pixel_hash.
• [Classification] — one of editorial, patch-correction, additive-1.1, breaking-major, open-ADR.
• [Findings] — identifiers from the VER standards audit that produced the item, for traceability into docs/standards/VER-1.0-errata.md. Identifiers of the form App. D #n cite item n of Appendix D of the base specification. (Earlier working notes wrote these as K<n>; the two forms denote the same items.)

1.2 Provenance of the rulings

Every item below is derived from a verified audit finding. Where the audit proposed more than one defensible resolution, the resolution adopted here is the one that (a) preserves the validity of every already-conformant Record and (b) matches observed producer behaviour, in that order of precedence. Where this annex departs from an audit finding's recommended disposition, the departure is stated inside the item. Dispositions inherited from the Studio PRD §16 review are marked as such.