§4 Annex items E1–E29
All twenty-nine are corrections, disambiguations, or scope statements over VER 1.0. None adds a field, a value, or a capability; several are enforced by the conformance profile rather than by the schema, and those rows say so. Five resolve a Canonical-Buffer ambiguity (§4.1) and one relaxes 1.0.0 (§4.2); every other row leaves every conformant Record untouched.
| Item | Subject | Class | Record-level impact |
|---|---|---|---|
| E1 | What pixel_hash actually survives | patch-compatible correction | No record changes. Corrects a claim: pixel_hash survives descriptive-metadata stripping, not removal of render-affecting metadata |
| E2 | image.width/height are Canonical Buffer dimensions | patch-compatible correction | A Record that recorded pre-orientation dimensions for Orientation 5–8 is now non-conformant; it was ambiguous before, and the ruling matches every deployed producer |
| E3 | Quantize is a scale, not a clip | patch-compatible correction (ambiguity resolved — §4.1) | The scaling reading is selected. pixel_hash values produced by a clip-implementing producer over sources deeper than 8 bits per channel are withdrawn, not recomputed; those Records were never interoperable. No Record produced by a scaling producer changes |
| E4 | Alpha compositing is 8-bit | patch-compatible correction | No record changes. Pins the arithmetic domain the formula always assumed |
| E5 | Rendition selection happens at decode | patch-compatible correction | No record changes. Step 4 only records hdr_present |
| E6 | One orientation source; out-of-range means upright | patch-compatible correction (ambiguity resolved — §4.1) | EXIF/TIFF tag 274 in the primary IFD is selected; XMP tiff:Orientation is reconciliation data, never CPNP input; out-of-range means 1. pixel_hash values produced by a producer that consumed XMP orientation, or that rejected or guessed an out-of-range value, are withdrawn |
| E7 | Animated sources: frame 0, fully coalesced | patch-compatible correction (ambiguity resolved — §4.1) | The coalesced logical screen at index 0 is selected; the frame-rectangle reading is withdrawn, along with the pixel_hash values produced under it. Also moves a Scope rule into normative CPNP text |
| E8 | Unusable ICC fails closed | patch-compatible correction (ambiguity resolved — §4.1) | A producer that silently assumed sRGB on ICC failure must now reject or emit a non-conformant diagnostic outside the Record; no undeclared field (icc_error) is ever legal. E8 additionally withdraws canonical identity entirely for an asset whose embedded ICC profile is present and unusable — under 1.0.x no conformant pixel_hash exists for it |
| E9 | Only an embedded ICC profile is consumed | patch-compatible correction (ambiguity resolved — §4.1) | Consuming none of gAMA/cHRM/sRGB/EXIF ColorSpace is selected, matching every deployed producer. pixel_hash values produced by a producer that honoured them are withdrawn; honouring them is CPNP-2 |
| E10 | The pixel_hash preimage, byte for byte | patch-compatible correction | No record changes. Decimal ASCII, no leading zeros, no sign — what every producer already emits |
| E11 | Raw-segment byte ranges, per container | patch-compatible correction | A Record whose raw[].sha256 covered re-framed bytes is non-conformant; it already violated §7.1's byte-exact MUST. Enforced by VER1302 |
| E12 | "Conformant decoder", defined | patch-compatible correction | No record changes. Results from an unprofiled decoder are PROVISIONAL. The first reference corpus and implementation profile are now published — standards/decoder-corpus/1/, profile verd-pillow/1 — so an implementation that reproduces every corpus digest exactly may drop PROVISIONAL for the Records it produces under that profile. Comparability is scoped to the profile, and a Record carries no field naming one: a Producer states its profile outside the Record (§8) |
| E13 | Conformance-table corrections | patch-compatible correction | Relaxes one row (L3 contextual embeddings are optional per §8 — see `VERSIONING.md` §2.1's self-contradiction carve-out) and defines "full space descriptor" as the complete §6.1 field set: reference (set_uri + tolerance_cosine) plus the per-kind preprocessing members — visual resize, interpolation, antialias, crop, mean, std, channel_order; text tokenizer, tokenizer_sha256, max_length, truncation, casing. §11 row 2's M is satisfied structurally by the schema-required members. A descriptor lacking either cannot back a cross-implementation conformance claim (E12) and draws profile warnings — VER404 (reference), VER405 (preprocessing, checked per kind for visual and text spaces). Whether those become errors is 1.1 ratification material |
| E14 | Reconciliation precedence completed | patch-compatible correction | No record changes. Adds platform at the bottom of an order the schema already admitted |
| E15 | Redaction: which shape, and the raw carve-out | patch-compatible correction + the one relaxation (§4.2) | §7.1's L1+ byte-exact-preservation MUST is subordinate to §7.5 redaction: when a redaction claim covers a value carried in a raw segment, that segment MUST be omitted from raw[] entirely (VER1005, error; remediation is "omit the segment"). In-segment scrubbing is not representable in 1.0.x. A redacting producer that omits the segment is conformant under 1.0.1 and was not under a literal 1.0.0 §7.1 reading — the one direction in which 1.0.1 relaxes 1.0.0. Whether salted_sha256 is mandatory was ADR-0006, decided on 23 August 2026 for records declaring ver_version: "1.1" only — 1.0.x is unaffected, salted_sha256 stays optional there and VER1002 stays a warning (§6 row 5) |
| E16 | record_id and created_at, defined | patch-compatible correction | No record changes. record_id uniqueness is per (producer, record); chain chronology becomes checkable — VER1201–VER1204 |
| E17 | The signature payload, defined | patch-compatible correction | Makes an existing SHOULD verifiable. A signature computed over a different payload was never verifiable by anyone else |
| E18 | space_id unique within a Record | patch-compatible correction | Duplicates become non-conformant. The 1.0.1 schema still accepts them; the profile rejects them (VER401). JSON Schema cannot express key-uniqueness over an array of objects, so 1.1 §11.4 makes the prohibition normative specification text while enforcement stays in the profile — see §6 row 11.4 |
| E19 | Grade is derived from source.class | patch-compatible correction | No record changes, no new field. Supplies the mapping that §8's consumer MUST needs |
| E20 | Fused recipe inputs are space_ids | patch-compatible correction | A fused Record whose recipe.inputs named roles rather than declared spaces is non-conformant (VER704) |
| E21 | Availability: naming, other, basis scope | patch-compatible correction | No record changes. iptc ≡ iptc-iim; other segments carry no availability family in 1.0; basis is record-scoped |
| E22 | Digest encodings and registered algorithms | patch-compatible correction | Pins lowercase hex and bit order. Backs schema delta S1 |
| E23 | Validators MUST assert format/contentEncoding | patch-compatible correction | No record changes. A conformant Record already satisfied both; 2020-12 simply made them non-assertive annotations |
| E24 | Vector carriage, dtype inheritance, byte layout | patch-compatible correction | A Record whose embedding.dim/dtype disagree with the descriptor is non-conformant (VER601/VER602); when absent, the descriptor's values apply. Mandatoriness is ADR-0008 |
| E25 | source_bytes_ref.sha256 = content_hash.value | patch-compatible correction | A Record where they disagree is non-conformant (VER1305). They always referred to the same bytes |
| E26 | Shipped examples are illustrative | patch-compatible correction | No record changes. A standing notice, not a requirement |
| E27 | pixel_hash groups, never keys | patch-compatible correction | Non-normative guidance. Asset identity belongs to the deploying system |
| E28 | C2PA state consistency | patch-compatible correction | availability.c2pa: "present" with c2pa.status: "missing" is non-conformant (VER1103). §9's "MUST be validated" reads as "MUST NOT report contrary to fact" until unverifiable lands in 1.1 |
| E29 | model.weights_sha256 has no defined preimage in 1.0.x | patch-compatible correction (normative scope note) | No record changes, no new field. VER 1.0.x defines no preimage beyond "SHA-256, lowercase hex", so for a multi-file checkpoint there is no interoperable construction: 1.0.x weights_sha256 values are comparable only within a producer. Producers SHOULD document which artifact was hashed. The interoperable construction is the 1.1 model.bundle manifest (ADR-0007) |
4.1 The five items that resolve a Canonical-Buffer ambiguity
E3, E6, E7, E8 and E9 each resolve a place where two defensible readings of the 1.0.0 text produced different Canonical Buffers, and therefore different pixel_hash values. That is the one thing a corrective release cannot do invisibly, so it is stated here in full rather than left to the annex.
The mechanism is identical in all five cases:
Resolving an ambiguity necessarily selects one reading. A Record produced under a non-selected reading was never interoperable — no other producer agreed with it — and is non-conformant under this annex. Its
pixel_hashis withdrawn, not recomputed: the value was never a claim anyone else could reproduce. No Record produced under a selected reading changes.
| Item | The ambiguity | The reading selected | What is withdrawn |
|---|---|---|---|
| E3 | §4 step 6, "quantize to 8 bits per channel, clamp to [0, 255]" — scale, or clip? | Scale: round_half_up(v * 255 / maxval), clamping after scaling | pixel_hash values produced by a clip-implementing producer over sources deeper than 8 bits per channel. Read literally, the clip destroys the image and not merely its precision; no interoperable producer implemented it (CPNP-04, audited breaking-major) |
| E6 | Which orientation source, and what an out-of-range value means | EXIF/TIFF tag 274 in the primary EXIF IFD only; out-of-range, zero or malformed means 1 | pixel_hash values produced by a producer that consumed XMP tiff:Orientation — a real case, since Adobe tooling writes both — or that rejected or guessed an out-of-range value |
| E7 | What "the first frame" of an animated source is | The decoder's frame at logical index 0, fully coalesced | pixel_hash values produced by reading a GIF's first-frame rectangle rather than the coalesced logical screen |
| E8 | What a present-but-unusable ICC profile means | Fail closed — reject, or emit a diagnostic state outside the Record | Canonical identity entirely, for such assets: under 1.0.x no conformant pixel_hash exists for an asset whose embedded ICC profile is present and unusable. A value produced by assume-sRGB is withdrawn, not re-derived |
| E9 | Whether gAMA/cHRM/sRGB chunks and EXIF ColorSpace are consumed | None are; CPNP-1 consumes only an embedded ICC profile | pixel_hash values produced by a producer that honoured them. Honouring them is CPNP-2, i.e. VER 2.0 |
Why E8 fails closed where E6 defaults. Orientation has a defined default: treating a malformed value as 1 preserves the visual meaning the file's pixels already carry. An unusable ICC profile leaves colour meaning undefined, and assuming sRGB fabricates it. A fabricated canonical identity is worse than none — it is a pixel_hash asserting an agreement no two implementations can honour. E8 therefore overrides §7's core preserve-and-proceed posture for this one case, and the annex says so explicitly, because the alternative fabricates canonical identity.
Why these ship in a patch release. A text with no single correct reading has no conformant implementations to protect. Each of the five sides with the reference implementation's actual behaviour, which is also the behaviour of every deployed producer. They are recorded here, rather than in the annex alone, precisely because the class is uncomfortable.
The 1.1 draft §16 records that 1.1 does not revisit any of these rulings, and cpnp_version stays "1.0" throughout.
4.2 The one item that relaxes 1.0.0
E15 is the single deliberate relaxation in 1.0.1. §7.1 requires byte-exact preservation of every metadata segment at L1+; §7.5 requires that a redacted value be removed and replaced by proof. Both cannot hold in one Record. E15 rules that preservation is subordinate to redaction: when a redaction claim covers a value carried in a raw segment, that segment MUST be omitted from raw[] entirely. VER1005 stays an error, and its remediation is "omit the segment".
In-segment scrubbing is not representable in 1.0.x. There is no marker distinguishing a scrubbed segment from acquired evidence, so a scrubbed segment would masquerade as byte-exact acquisition evidence. Scrubbed-segment carriage with an explicit marker is 1.1 ratification material.
Consequence, stated plainly: a redacting producer that omits a sensitive segment is conformant under 1.0.1 and was not conformant under a literal 1.0.0 §7.1 reading. This is the one direction in which 1.0.1 relaxes 1.0.0, and it is why `VERSIONING.md` §2.1's "a patch release may not relax a constraint" carries an explicit carve-out. The operational shape is the two-envelope pattern in `docs/standards/VER-migration-guide.md` §5.