§10 Metadata carriage

10.1 Raw segment index and by-reference carriage

Multi-segment metadata families are common — multi-APP1 EXIF, Extended XMP spanning several markers, multi-chunk iCCP — and 1.0's raw[] entries carry no ordinal, so reassembly depends on array order alone (E11). Large segments must be inlined as base64 into the Record, which collides with §7's size limits.

• metadata.raw[].index is an optional zero-based ordinal within the segment's family, in file order. **It is REQUIRED when a family occupies more than one segment**, and that conditional is now schema-encoded — one branch per family, keyed on the array containing two or more entries of that family. Reassembly is by ascending index.
• **Uniqueness and contiguity of the ordinals within a family are profile-enforced.** JSON Schema cannot compare two array members, so “no two entries of one family share an index” has no encoding (§15.4).
• metadata.raw[].bytes_ref is an alternative to bytes, carrying {uri, sha256, byte_length}. Exactly one of bytes and bytes_ref MUST be present. Where bytes_ref is used, the entry's own sha256 MUST equal bytes_ref.sha256, and both are the digest of the **decoded segment octets** as defined by E11's per-container table — never of the base64 text.
• A Consumer that cannot resolve a bytes_ref MUST treat the segment as unavailable, not as absent: availability still governs what the Producer asserts about the family.

10.2 Consumed render-affecting metadata

CPNP-1 consumes EXIF Orientation and the ICC profile into the Canonical Buffer and 1.0 §7.1 simultaneously requires them preserved byte-exact. Nothing in a 1.0 Record marks a preserved segment as already consumed, so a Consumer that re-renders from the Canonical Buffer plus the preserved EXIF double-applies the rotation and the colour transform.

metadata.raw[].consumed_by_cpnp is an optional boolean. true means CPNP-1 consumed render-affecting data from this segment. A Consumer MUST NOT re-apply a segment marked true to the Canonical Buffer. Absence of the marker means the Producer made no statement — it does not mean false; the E1 warning against re-applying preserved render-affecting metadata applies regardless.

10.3 Availability: other, upstream_withheld, and per-family basis

• metadata.availability gains an other key, so 1.0 §7.2's “each metadata family carries exactly one state” becomes satisfiable for a preserved other segment (E21).
• metadata.availability gains the state upstream_withheld: the Producer never received the family's values, so it can neither preserve them nor commit to them (§5.2, ADR-0006). It is distinct from stripped_suspected — a belief about what an upstream did — and from absent, which says nothing about why. This is an additive 1.1 enum extension; the five 1.0 states keep their meanings exactly.
• metadata.availability_basis accepts an object keyed by family in addition to the 1.0 string form, so two families stripped for different reasons can each state their basis. The string form remains valid and means what it meant in 1.0: one narrative covering every stripped_suspected family. **Where the object form is used, every family whose state is stripped_suspected MUST have a non-empty entry** — schema-encoded, one branch per family. A basis SHOULD also be stated for an upstream_withheld family; it is not required, because the state itself already says what happened.

The iptc / iptc-iim naming split (E21) is not repaired in 1.1. Introducing iptc-iim as the availability key while keeping iptc as a deprecated alias creates two spellings of one family for the lifetime of VER 1.x. The rename is deferred to VER 2.0, where the alias can be dropped in the same breath.