How to write a safety requirements document for AI.

A system prompt is not a safety spec. This is what one looks like, section by section, so you can write your own.

Most AI products that touch people's wellbeing have a safety story. Few have a safety document. The difference matters because a story lives in slide decks and changes with whoever is telling it, while a document has numbered requirements that can be tested, traced to evidence, and signed off before a release.

Cindra's Product Safety Requirements Document, or PSRD, is a 1.0 draft, and it is being shared here as a structure rather than a finished answer. The numbers in it are initial proposals pending clinical and regulatory review, and the document says so repeatedly. What transfers to another team is the shape, and the shape is the point of this article.

1. Scope, intended use, and what the product is not for

Start with a table describing the product in one line per attribute: product type, target users, delivery mode, intended role. Cindra's reads as an ACT-informed wellness and skills companion, for adults with mild to moderate stress or anxiety, delivered by conversational AI, as adjunctive support that complements rather than replaces human care.

Then the exclusions, each with a reason. This is the section most teams skip and most need. Cindra lists minors, active psychosis, acute suicidality, active eating disorders, active substance use disorders, severe personality disorders, and three excluded uses: diagnosis, psychotherapy, and crisis intervention. Every exclusion cites the evidence behind it. We cover this section in who should not use your companion.

Close the scope with assumptions and dependencies. Cindra's include operating at ASL-MH Level 3 rather than autonomously, the existence of a qualified human crisis team, and a regulatory classification to be settled by counsel before launch. Writing these down turns unstated bets into visible ones.

2. Principles

Eight lines, each a sentence or two, that govern every later decision. Cindra's are human-connection-first, transparency, ACT protocol fidelity, crisis conservatism, anti-sycophancy, clinical oversight, continuous monitoring, and evidence-grounded design. The test of a good principle is whether it would ever cost you something. Crisis conservatism, which says to err toward escalation when in doubt, costs false positives and staff time. That is what makes it a principle rather than a slogan.

3. Hazard classification

A table of hazard classes with severity, likelihood, key mitigations, and verification evidence. Cindra identifies ten, from suicide facilitation (catastrophic, medium likelihood) to misrepresentation as a human (major, low). The table does two jobs: it forces the team to name what can go wrong before writing requirements, and it links each hazard to the test that would show the mitigation works. Hazard analysis for AI companions walks through all ten.

4. Numbered requirements

The body of the document. Each requirement gets an ID, uses SHALL or SHALL NOT, and carries a priority of MUST or SHOULD. Cindra's 90 requirements fall into 12 domains: identity and claims, crisis response, prohibited content, therapeutic fidelity, anti-sycophancy, anti-dependency, human oversight, model architecture, evaluation, privacy, equity, and post-launch monitoring.

A good requirement is specific enough to fail. "Cindra SHALL be safe" cannot fail. "Cindra SHALL NOT generate crisis responses using open-ended LLM generation; crisis responses SHALL come from a preapproved, clinician-written library" can. So can "Cindra SHALL disclose its AI identity at the start of every new conversation and at least once per session." Write toward the second kind.

5. Acceptance criteria

Each domain ends with four fields. The pass condition states what success looks like. The test method states how it is measured. The minimum threshold is the floor below which the release is blocked. The evidence artifact names the document that proves it.

For crisis detection, Cindra's pass condition is VERA-MH sensitivity of at least 85 percent with a 90 percent target and a false negative rate under 5 percent. The test method is the automated benchmark plus a clinician-reviewed red-team suite of 200 or more escalating scenarios. The minimum threshold is zero instances of lethal-means information across 10,000 test conversations and crisis resources in 100 percent of confirmed-risk conversations. The evidence artifacts are the benchmark report, the red-team report, and the sign-off on the crisis response library. The full set of thresholds is in safety thresholds.

6. Release gates

Four gates, each with criteria drawn from the requirements and a list of who must approve. Alpha for internal testing, beta for a clinician-supervised cohort, public launch, and post-launch re-validation. The approver list grows at each gate; public launch needs engineering, clinical, product, regulatory counsel, an independent safety reviewer, and an executive sponsor. Release gates covers the criteria.

7. Traceability matrix

A table mapping each block of requirement IDs to its evidence source, the strength of that evidence, and the citation. This is what lets a reviewer ask "why is REQ-37 in here?" and get an answer that points at a paper rather than at a meeting.

8. Evidence calibration

The section most documents lack and the one that builds the most trust. Cindra grades its own evidence base. The ACT evidence and the clinical suicide-prevention standards are established. Purpose-built AI, VERA-MH, and domain-specific constitutional AI are promising but early. The claim that safety training disrupts therapy, and the long-term dependency harms, are preliminary. The governance frameworks are proposals. A document that admits which of its requirements rest on a single preprint is a document a regulator or an independent reviewer can work with.

9. Open decisions

A list of what leadership has not yet decided, with options and impact. Cindra's has ten, including regulatory classification, the crisis escalation recipient, the human review SLA, data retention, and dependency thresholds. Putting unresolved questions in the safety document, rather than leaving them implicit, is how a draft stays honest about being a draft.

Document control

Version, date, classification, review cycle, next review date, and a change log. Cindra reviews quarterly or on any material change to scope, model, or regulation. Boring, and necessary, because a safety document that is not maintained is a historical artifact.

This article describes an engineering and clinical-safety approach and the published evidence behind it, much of which is early. It is not legal, regulatory, or clinical advice. Thresholds quoted from Cindra's requirements document are initial proposals pending clinical and regulatory review.