Compatibility matrixstable
§1 The four classes, and the questions each must answer
| Class | Definition |
|---|---|
| editorial | Wording only. No requirement, no schema constraint, and no record content changes. |
| patch-compatible correction | Corrects or disambiguates an existing requirement. Every already-conformant Record stays conformant, and every working consumer keeps working. |
| additive 1.1 | Needs a new field, value, or capability. Gated behind ver_version: "1.1". |
| breaking / major | Changes a pixel_hash universe, removes a field, narrows a value space, or changes an existing field's meaning. VER 2.0 only. |
Every row below answers the same two questions:
- Q1 — Does any 1.0.0-conformant Record become invalid?
- Q2 — Does any Record valid under the new artifact fail the old one?
For a patch-compatible correction the answers must be no and no. Where a row answers otherwise, the row says so explicitly and the reason is recorded.
Headline result. 1.0.1 changes no Record produced under a reading the annex selects, and the corrected 1.0.1 example validates under both the 1.0.0 and the 1.0.1 schema. Three qualifications, each stated once and traceable to a row:
- Five annex items — E3, E6, E7, E8, E9 — resolve places where two defensible readings of 1.0.0 produced different Canonical Buffers. Resolving an ambiguity necessarily selects one reading, and Records produced under a non-selected reading were never interoperable and are non-conformant under the annex. Their
pixel_hashvalues are withdrawn, not recomputed. §4.1 states the mechanism and the five items in full. - One annex item — E15 — is a deliberate relaxation of 1.0.0: §7.1's byte-exact preservation MUST is subordinate to §7.5 redaction. §4.2.
- Three classes of Record that the 1.0.0 schema accepted **while violating 1.0.0 prose** are now rejected by the schema; each is named in §2 and answered again in §9.