Per-track operator training programs for the V1 launch. Each program defines learning objectives, a curriculum with assessment, scenario rehearsals, certification criteria, tabletop drills, and an ownership chain.
| # | Track | Owner | Refresh |
|---|---|---|---|
| 1 | Support operators | support lead | annual |
| 2 | Moderators | T&S lead | 6 months |
| 3 | Reviewers | editorial lead | 6 months |
| 4 | Persona operators | T&S persona lead | 6 months |
| 5 | Model operators | platform-engineering model-ops lead | 6 months |
| 6 | Privacy operators | privacy lead | 6 months |
| 7 | Compliance operators | compliance lead | 6 months |
| 8 | Product | product lead | 6 months |
| 9 | Launch support | reliability lead + release captain | per-launch |
Cross-track conventions#
- Every program includes a scenario rehearsal under live or staging conditions, a scored assessment per module, and a certification gate with a documented sign-off chain.
- Crisis routing, AI-disclosure compliance, evidence preservation, and audit-grade case notes are shared modules; an operator certified on one track is expected to recognize but not necessarily disposition cases on adjacent tracks.
- RBAC and policy-training currency (within 90 days) is a precondition for handling any production case across every track.
- Well-being protocols are mandatory for any track with potential exposure to graphic content, crisis content, or sustained adversarial material; the moderator program documents the canonical well-being protocol that other tracks adopt as needed.
- Each program records certification status against the operator in the audit registry; expirations and re-cert windows fire as scheduled reminders.
Release-gate dependency#
General Availability approval cannot be granted until every track listed above
has at minimum one certified operator on the staffing roster and a documented
call-out plan for the surge rota. Compliance operators verify this dependency at
the launch gate per docs/launch/go-no-go.md.
Updating the programs#
A program is updated when:
- A policy delta changes the canonical disposition decisions in the track.
- A new runbook (in
docs/runbooks/) introduces a procedure the track must execute. - A new domain, persona, model, or workflow target enters the promotion pipeline.
- A regulator update changes the obligations the track operates under.
- A postmortem identifies a training gap.
The owner listed in the table above is accountable for the update. Every update requires review by the cross-track stakeholders listed in the matching program file.