# Safety Review Pass — V1 Launch Gate

> Gate owner: Trust & Safety Lead. Required for §33.1. Cannot be satisfied by
> Security Pentest signoff alone.

The safety review pass is a **joint sign-off** from the Lilith content safety
council, the Trust & Safety operations board, and the Privacy review board. It
is independent from — and additive to — the security pentest signoff in
`docs/security/pentest/signoff.md`.

## 1. Mandate

The three boards verify, jointly and independently, that OSHUN V1 will not ship
with any of the following risk classes:

1. **Crisis-flow regressions** — degraded handling of self-harm, suicide, abuse,
   child-safety, or violence-incitement signals.
2. **Bypassable safety gates** — paths that route external model output,
   user-generated content, or persona output to launch surfaces without passing
   Lilith, Sophia, and Isis release gates.
3. **Grounding-rate regressions** — assistant or Metis answers below the
   published grounded-evidence thresholds in `docs/launch/quality-review.md`
   §1.8.
4. **Persona drift outside policy envelope** — persona behaviour exceeding the
   persona-tone-policy bounds in `libs/oshun/persona-policy-lilith/` (tone
   bands + cross-product harness) and `libs/oshun/persona-registry/`
   (calibration rubric).
5. **Privacy regressions** — PII leakage, retention exceeding policy, DSAR
   (export / delete) failures, cross-tenant data exposure.
6. **Moderation backlog or queue-failure** — review-queue p95 dwell exceeding
   the SLA published in `docs/runbooks/moderation-surge.md`.
7. **Provenance gaps** — published content that cannot be traced to source,
   model, prompt, reviewer, and policy version.
8. **Watermark verification failures** — generated assets missing the Lilith
   watermark or failing offline verification.

## 2. Board composition

### 2.1 Lilith content safety council

| Role                                      | Required signatory |
| ----------------------------------------- | ------------------ |
| Lilith safety policy lead                 | Required           |
| Senior content reviewer (rotating)        | Required           |
| Persona policy lead                       | Required           |
| Crisis-flow specialist (clinical advisor) | Required           |
| Child-safety reviewer                     | Required           |
| Localization / regional safety reviewer   | Required           |

### 2.2 Trust & Safety operations board

| Role                       | Required signatory |
| -------------------------- | ------------------ |
| T&S operations lead        | Required           |
| Moderation operations lead | Required           |
| Appeals operations lead    | Required           |
| Research integrity lead    | Required           |
| Legal counsel              | Required           |

### 2.3 Privacy review board

| Role                            | Required signatory |
| ------------------------------- | ------------------ |
| Privacy lead                    | Required           |
| Privacy operations lead         | Required           |
| Data-protection officer (DPO)   | Required           |
| Records-of-processing custodian | Required           |
| Privacy counsel                 | Required           |
| Tenant-isolation auditor        | Required           |

A board cannot self-certify with substitutes for absent signatories. A signoff
is invalid if any required role is unfilled.

## 3. Inputs (evidence packet)

All three boards receive the same evidence packet, assembled by the release
captain. The packet **must** contain:

- Dogfood evidence snapshot (`docs/releases/v1/verification/dogfood/`).
- Latest red-team exercise report (`docs/security/red-team/YYYY-MM-DD.md`).
- Quality review pass (`docs/launch/quality-review.md`) with AI eval scores for
  grounding, pedagogy, safety, persona-tone, and rights.
- Moderation backlog and SLA compliance for the last 30 days
  (`docs/releases/v1/verification/moderation/`).
- Crisis-flow drill log (every published crisis flow exercised twice with
  operator + system + clinical-advisor present).
- Persona-tone audit (`docs/releases/v1/verification/persona-tone/`).
- DSAR drill packet (`docs/releases/v1/verification/dsar/`).
- Tenant-isolation audit (
  `tests/security/tenant-isolation/bff-tenant-isolation.security.test.ts`
  passing + a manual audit narrative).
- Watermark verification audit
  (`docs/runbooks/watermark-verification-failure.md` exercise + offline-verifier
  evidence).
- Provenance audit (random sample of 100 published items each from Tara,
  Veritas, Nyx, Nisaba, Metis showing full source → model → prompt → reviewer →
  policy-version chain).

## 4. Review process

Each board independently runs a **2-week review**:

- **Week 1, days 1-3** — packet ingestion + clarifying-question round with
  release captain.
- **Week 1, days 4-7** — independent verification (the boards may request
  additional drills or evidence).
- **Week 2, days 1-3** — synchronous joint session with all three boards to
  reconcile findings.
- **Week 2, days 4-5** — written signoffs published to
  `docs/releases/v1/verification/safety-review/YYYY-MM-DD/`.

## 5. Decision

Each board independently issues one of:

- **PASS** — proceed to private beta.
- **PASS-WITH-CONDITIONS** — proceed only after named blockers close. Conditions
  are tracked at `docs/releases/v1/verification/safety-review/conditions.md` and
  re- verified before go/no-go.
- **HOLD** — do not proceed. The release captain re-opens the dogfood drill or
  extends evidence collection.

A single HOLD blocks the gate. All three PASS or PASS-WITH-CONDITIONS required
to satisfy §33.1.

## 6. Signoff template

```
# Safety Review Signoff — Lilith Content Safety Council
# date: 2026-MM-DD
# signatories: <name> (role) ... (one row per required role in §2.1)

## decision
[ PASS | PASS-WITH-CONDITIONS | HOLD ]

## conditions (required if PASS-WITH-CONDITIONS)
- <blocker id> — <description> — owner: <name> — due: <YYYY-MM-DD>

## evidence reviewed
- dogfood snapshot: docs/releases/v1/verification/dogfood/<date>/
- red-team: docs/security/red-team/<date>.md
- quality review: docs/launch/quality-review.md (rev <sha>)
- ... (every artifact in §3)

## findings (top 5)
1. ...
2. ...

## scope dissent (if any)
- <signatory name>: <dissent statement>
```

The Trust & Safety operations board and Privacy review board use the same
template with their respective signatory rosters.

## 7. Reopening conditions

The safety review reopens automatically if **any** of the following occur
between signoff and GA:

- Any S0 defect in §4 risk classes from `docs/launch/dogfood-drill.md`.
- Crisis-flow regression detected in production-mirror or beta.
- DSAR drill failure.
- Tenant-isolation test failure.
- Moderation backlog SLA breach for > 24 h.
- Persona-tone audit failure (drift > 2 σ from envelope).
- Watermark verification failure rate > 0.1 %.

A reopened safety review starts a new 2-week cycle. No GA can proceed during an
active reopened review.

## 8. Cross-references

- Quality review: `docs/launch/quality-review.md`.
- Private beta: `docs/launch/private-beta.md`.
- DSAR runbook: `docs/runbooks/privacy-incident.md`.
- Crisis flow runbook: `docs/runbooks/grounding-failure.md`.
- Watermark verification: `docs/runbooks/watermark-verification-failure.md`.
- Persona rollback: `docs/runbooks/persona-rollback.md`.
- Moderation surge: `docs/runbooks/moderation-surge.md`.