# Review, escalation, and incident response

Phase 182, `182.C.39.06`. Review and escalation rules, non-overridable gates,
subject requests, takedowns, and incident response.

## 1. Who may see what

**A reviewer does not need the original to do the review.** The review question
is "is this output acceptable", and the output is the take. The reference
photograph the subject enrolled is an _input_ — and it is the most sensitive
artifact in the system, while the review queue is the highest-traffic surface
that touches this data (`human-video-reviewer-access.ts`).

So biometric originals and provider payloads are released only when the role
**and** the case both require it, not when either does.

Escalation out of the building splits by audience, and the overlap is smaller
than it looks (`human-video-escalation-export.ts`):

- **Support** is inside our trust boundary and outside the tenant's. They may
  see which tenant, which job, and what failed. They do not need the likeness.
- **A provider** is outside both. They need the request shape, the parameters
  and the error — and **the tenant's identity is not their business**. A
  provider who can correlate failures to named customers has been handed a
  customer list.

The two policies differ on the tenant identifier, which is the field everybody
assumes is harmless. Every export stays audit-safe: a reader can tell what was
removed.

## 2. The gates nobody may override

"Non-overridable" is a **list**, not a principle, because every gate looks
overridable at two in the morning. Four gates may be waived
(`human-video-quality-waiver.ts`):

`quality-aggregate`, `audiovisual-sync`, `encoding-conformance`,
`output-shape-valid`.

Each of those protects **the buyer, who is in the room** and can decide the
video is good enough for them. Twelve may not be waived, and each one names the
person it protects — because "not waivable" invites a request for an exception,
and naming the absent person does not:

| Gate                    | Who is not in the room                                                                       |
| ----------------------- | -------------------------------------------------------------------------------------------- |
| `consent-evidence`      | the person whose likeness this is did not agree to be in this decision                       |
| `identity-preservation` | waiving it ships a video of somebody who may not be who it claims                            |
| `safety-scan`           | the people a harmful video reaches are not party to this                                     |
| `exact-speech`          | putting words in a real person's mouth is the harm this phase exists to prevent              |
| `synthesis-disclosure`  | the disclosure is owed to the viewer; a tenant cannot waive an obligation that is not theirs |
| `rights-and-license`    | the rightsholder is not in the room                                                          |
| `provenance-c2pa`       | a released asset with no provenance cannot be given one later                                |
| `final-bytes-binding`   | without it the proof is about nothing in particular                                          |
| `provider-lineage`      | the record of what produced these bytes is not a quality property                            |
| `watermark-coverage`    | the mark is a disclosure control rather than a quality one                                   |
| `policy-compliance`     | a policy a reviewer may waive is not a policy                                                |
| `human-review-ready`    | waiving readiness for review is waiving the review                                           |

A waiver on one of the four is still **bounded and co-signed**: it expires
(seven days maximum), it carries a queryable reason code rather than free text
alone — free text cannot answer "how often does this happen" — and it needs a
second approver when the person asking is the person who owns the job.

## 3. Subject requests

**A subject is not a tenant, and every index in this system is built the other
way round** (`human-video-subject-requests.ts`). A tenant knows which packs
belong to which subject because they enrolled them; we know it only through the
authorization. So "everything about this person" is answerable **only as far as
the authorizations reach**, and anything enrolled under a subject reference
nobody linked is invisible to our search while being perfectly visible to
whoever holds it.

The operational consequence: **state the reach**. A partial search presented as
a complete answer is the failure mode, and the module refuses an answer that
does it.

Two categories answer differently from the rest:

- **Embeddings are ours, and are returned to nobody.** A vector means nothing to
  the subject and everything to whoever else ends up with the export, so
  including one in an access response hands a biometric identifier to whoever
  the email reaches. They are deleted on request; they are not exported.
- **Released assets** cannot be recalled, only accounted for. See §4.

Subject requests do not run through the creator support queue. The subject is
not the customer, and a queue ordered by customer value orders these wrong.

## 4. Takedowns

A takedown destroys what we hold: origin objects, derived renditions, evaluation
frames — the frames extracted for review are the likeness too — and the face
embeddings, which outlive the images they came from.

It does not reach provider-side copies, CDN edge caches, signed links already
issued, or anything already downloaded (`human-video-revocation.ts`).

**Never report a takedown complete while copies remain.** Telling a subject
their likeness has been removed when it is still served from three caches is
worse than telling them nothing, because it ends the conversation. The reach
report lists the unreachable locations by name, and a zero-retention provider
class is the only case where the provider-side line is genuinely empty.

## 5. Incident response

Six drills, and the clock on each starts **before anybody notices**
(`human-video-incident-drills.ts`): a leaked URL is reachable from the moment it
leaks, a takedown obligation starts at the subject's request rather than its
triage, a revocation is in force from the instant it is made.

- Containment is timed from onset, with the detection lag reported **beside**
  the response rather than folded into it. A drill measures response and cannot
  measure detection, because it begins by announcing itself.
- Four of the six need a subject, and the only honest one is synthetic: the
  drill must not create the harm it rehearses.
- Two cannot be undone, so they never point at production releases.
- A drill expires on **change** to the path it covers, not on a calendar.

During an incident, remember which control is which: a **quarantine** follows
automatically from a catalog diff and nobody signs it; a **kill switch** has a
person's name on it and blocks submission only, leaving already-paid work to
finish being evaluated.

## Where this is still theory

No drill has been run, no subject request has been answered, and no waiver has
been issued. The lists above are enforced in code and untested by events.