# Media lifecycle, provenance, and release-proof inspection Phase 182, `182.C.39.07`. Media and storage lifecycle, final-byte evaluation, C2PA verification, watermark and disclosure, and how to read a release proof. ## 1. Media never rides inside a payload A job envelope, a database row, a log line and a client response carry object **keys and digests, never bytes** (`human-video-inline-media-guard.ts`). This needs enforcement rather than a convention, because every provider integration is one response shape away from breaking it — and the repo contains the proof: one provider projects a produced clip to `data:video/mp4;base64,…`, and the OpenRouter adapter did the same before `182.C.11.08` replaced it with a stream. A twenty-second 1080p take is tens of megabytes; base64 makes it a third larger again; and it is then held by whatever parsed it, copied by whatever logged it, and stored by whatever persisted it. The lifecycle after that is ordinary and audited: namespaced objects (`human-video-object-namespaces.ts`), derived renditions recorded against their parent (`human-video-derivation.ts`), review artifacts separated from delivery (`human-video-review-artifacts.ts`), signed delivery with a cache lifetime clamped to what is left of the signature (`human-video-delivery.ts`), and erasure that enumerates derivatives from the lineage rather than guessing (`human-video-erasure.ts`). ## 2. Final-byte evaluation **The thing you measured and the thing you ship are different files unless somebody checks.** A master evaluated before encoding, shipped as a transcode, leaves a release proof that is about bytes nobody received (`human-video-final-bytes-gate.ts`). This is why `final-bytes-binding` is on the non-waivable list with the shortest reason of the twelve: _without it the proof is about nothing in particular._ ## 3. C2PA: "survives a transcode" is the wrong goal Measured on 2026-09-11 with ffmpeg 6.1.1 (`evidence/2026-09-11-provenance-transcode/`): | Question | Result | | --------------------------------------------------------------------------- | ------------------------------------------------- | | Does a custom metadata key (`c2pa_manifest=…`) get written into MP4 at all? | **No** | | Does a recognised key (`comment`) survive a re-encode and scale to 160×120? | **Yes** | | Does it survive a stream-copy remux? | **Yes** | | Does `-map_metadata -1` remove it? | **Yes — one flag** | | How much payload survives? | 8000 characters, intact | | Is a stream-copy remux byte-identical to its source? | **Yes** | | Is a transcode byte-identical? | **No** | | After MP4 → WebM, is the key readable? | Yes, but the case changes (`comment` → `COMMENT`) | **A manifest that survives a transcode reports tampering.** The manifest binds the SHA-256 of exact bytes; a transcode produces different bytes by definition; so a surviving manifest verifies as _media hash mismatch_ — the same result a verifier gives for a maliciously edited file. Carrying provenance through a transcode does not preserve provenance, it **manufactures a tamper signal**. So the rule splits on what the operation does to the bytes: - **Remux** is byte-identical: carry the manifest, it stays valid. - **Transcode** needs its **own** manifest, issued over the new bytes, whose edit assertion names the parent's media hash. Two operational consequences: the transport must use a **recognised** metadata key, because a custom one is silently not written at all; and provenance is removable by anyone with one ffmpeg flag, so **its absence is not evidence of anything** and the release proof, not the file, is the record. ## 4. Watermark and disclosure Disclosure is owed to the **viewer**, which is why a tenant cannot waive it — the obligation is not theirs to trade (`human-video-disclosure.ts`). A watermark is a **disclosure control, not a quality control**; a reviewer weighing whether a take looks good enough has no standing over it. Both sit on the non-waivable list for that reason, next to `provenance-c2pa`, whose own reason is temporal: a released asset with no provenance cannot be given one later. ## 5. Reading a release proof One proof per artifact, extending the existing record rather than defining a second one — because two proof records for one artifact means two answers to "was this released correctly", and the reader finds whichever the code path happened to write (`human-video-release-proof.ts`). When inspecting one, read in this order: 1. **What bytes is it about?** The final-byte binding. A proof not bound to the delivered digest is a proof about a different file. 2. **What was measured, versus what was observed?** `observed_outcome` records _that_ something was observed. It cannot say whether a value cleared its threshold by a hair or by an order of magnitude, and it cannot say the instrument could not resolve the difference at all — so `threshold_measurement` carries the value, the unit, the threshold, the comparison direction, **and the noise floor**. A `passed` threshold whose margin is inside the noise floor is not a pass anybody should quote. 3. **Which evaluator versions?** A proof written under an evaluator you have since rolled back is still true about what was measured at the time (`182.C.39.05` §7). 4. **Which gates, and were any waived?** Only four gates can be waived at all, each waiver is bounded and co-signed, and a waiver on anything else is not a waiver — it is a bug (`182.C.39.06` §2). 5. **Does the delivery still match?** Re-encoding after the proof was written breaks the binding, which is what `human-video-delivery-regression.ts` is for. ## Where this is still theory The provenance measurements above are real and reproducible. Everything they serve is not yet exercised end to end: no release proof has been written for a real generated take, because no real take has been through this pipeline.