§9 Answers, stated once
Does any 1.0.0-conformant Record become invalid under the 1.0.1 schema? No. Three classes of Record that the 1.0.0 schema accepted are now rejected — wrong-width perceptual digests, undeclared members in identity.content_hash, undeclared members in identity.pixel_hash — and each already violated 1.0.0 prose. The frozen 1.0.0 example is one of them, which is why it is frozen with a defect notice rather than repaired.
Does any 1.0.0-conformant Record become non-conformant under the 1.0.1 annex? Yes, in exactly one family of cases: a Record produced under a reading that E3, E6, E7, E8 or E9 did not select. Those Records were never interoperable; their pixel_hash values are withdrawn, not recomputed. §4.1 states each case. Nothing else in 1.0.1 moves a Record from conformant to non-conformant.
Does 1.0.1 relax anything in 1.0.0? Once. E15 subordinates §7.1's byte-exact preservation MUST to §7.5 redaction, so a producer that omits a raw segment covered by a redaction claim is conformant under 1.0.1 and was not under a literal 1.0.0 reading. §4.2.
Does any 1.0.1-valid Record fail the 1.0.0 schema? No. Every 1.0.1 schema change is a tightening or metadata. The corrected 1.0.1 example is the proof: it validates under both.
Does any 1.0.x-valid Record fail the 1.1 draft schema? Yes — every one of them, and on more than the version gate. That is the change the 23 August owner review made: the schema-superset property is withdrawn, and moving a Record to 1.1 is a real migration whose every step is enumerated in draft §12.1 with the failure pointer it produces. Fourteen rows; the 1.0.1 golden example trips two of them (three pointers), and the ten 1.0.1 conformance/valid/ fixtures trip four between them — the four fixtures that declare "schema": "1.1-draft" are 1.1 Records already and trip none. §6 carries the measured table.
Rules that 1.1 states and the schema still does not carry are listed in draft §15.4, and none of them is there for compatibility any more. Two reasons remain:
| Rule | 1.1 § | Why it is not encoded |
|---|---|---|
| Size limits (serialized record ≤ 10 MiB, decoded inline raw ≤ 6 MiB, decoded single vector ≤ 6 MiB) | §7 | Not portably encodable: no keyword bounds a document's byte length, maxLength bounds base64 text rather than decoded octets, and none sums across array members. VER104 enforces all three |
space_id uniqueness within spaces[]; raw[].index uniqueness; dim/dtype vs the descriptor; vector byte-length arithmetic; every digest recomputation; lineage acyclicity; authority ownership | §11.4, §10.1, §12, §11.2, §15.3, §3.3, §11.6 | Inexpressible — key uniqueness, cross-member comparison, arithmetic, hashing, graph properties, facts about the world. Profile-enforced for the life of VER 1.x |
Per-kind preprocessing completeness | §11.1 | Deliberate: E13's full-descriptor definition backs a warning (VER405), so an incomplete descriptor is diagnosed rather than made unparseable. Promoting it is an open ratification vote |
Does any 1.1 Record fail the 1.0.1 schema? Yes, by design, whenever it uses a 1.1 capability. Such Records declare ver_version: "1.1", which is the signal a 1.0 consumer needs to decline them rather than misread them.
Does anything on this branch move a pixel_hash? Nothing moves one. Five annex items withdraw pixel_hash values that were never interoperable — E3, E6, E7, E8, E9 — and E8 withdraws canonical identity entirely for assets with a present-but-unusable ICC profile. Every value produced under a selected reading is bit-identical before and after. cpnp_version stays "1.0". See §4.1.