§5 The redaction two-envelope pattern

Worth its own section because it is where §7.1 and §7.5 collide (SPEC-02, Appendix D #8), and because the resolution has an operational shape.

§7.1 requires byte-exact preservation of every metadata segment at L1+. §7.5 requires that redacted values be removed and replaced by proof. Both cannot hold in one Record: preserving the raw EXIF segment preserves the GPS coordinates that the redaction claims to have removed. Annex E15 rules that a Record MUST NOT claim redaction of a value while preserving a raw segment that still contains it (VER1005).

The pattern that satisfies both requirements:

• The private evidence record keeps the raw segments byte-exact, claims no redaction, and never leaves your trust boundary. It is your L1+ evidence.
• The shareable record omits the affected raw segments from raw[] entirely, sets the family's availability to redacted, and populates redactions[] with the reason and a salted_sha256 so the value can be matched on challenge without being disclosed.

Omit, do not scrub. Editing the sensitive bytes out of a segment and carrying the remainder is not an option in 1.0.x: nothing in the Record distinguishes a scrubbed segment from acquired evidence, so a scrubbed segment would masquerade as byte-exact acquisition evidence — which is the whole point of L1+. Carrying a scrubbed segment behind an explicit marker is 1.1 ratification material. Until then the segment is either preserved intact or absent, and VER1005 is an error whose remediation is "omit the segment".

The shareable record's conformance level reflects what it actually carries. A record that dropped its raw EXIF is not L1 for that family, and claiming L1 anyway is exactly the self-declaration problem the profile validator exists to catch (VER302, VER303).

Decided, and version-gated. ADR-0006 resolved on 23 August 2026: for Records declaring ver_version: "1.1" a redaction the producer performed REQUIRES a commitment, and the never-held case gets its own state (upstream_withheld) rather than a silent omission.

Nothing about 1.0.x changes. salted_sha256 stays optional in 1.0.x, and VER1002 stays a warning there permanently — the requirement became normative for a different version, so the 1.0.x rule is untouched.

Two pieces of advice for a 1.0.x producer, and the second is the one that will hurt if ignored:

1. Emit the salted hash whenever you hold the value. It clears VER1002 and it is the field 1.1 turns into a requirement.
2. Keep your salts. The 1.1 member is not a rename of salted_sha256 — the preimage changes (domain tag, length framing, JCS serialization of the value), so a 1.1 commitment_sha256 must be recomputed from the salt and the value. A producer who has discarded a salt cannot migrate that entry at all. Prefer keeping the Record at 1.0 in that case: the other path ADR-0006 names — restating the entry as upstream_withheld — collides with §5.2's definition of that state ("the Producer never received the value"), and a producer who held the value would be trading an impossible commitment for a false provenance statement. The tension is ledgered as REV-36 (owner ruling requested); until it is ruled, stay at 1.0. §6.2 repeats the keep-your-salts rule because it is the one migration step that becomes impossible if you wait.