Release gates: who signs, and what has to be true.
A release gate is a list of things that must be true and people who must say so. Here are four, with both lists.
Cindra's safety document defines four release gates. Alpha, for internal testing, requires a completed red-team suite under 5 percent harmful content, a VERA-MH baseline, fidelity testing, a signed crisis library, a documented escalation workflow, a tested kill switch, and audited privacy infrastructure, approved by engineering, clinical, and product leads. Beta, for a clinician-supervised cohort, adds independent safety evaluation, a 500-conversation clinician review, demographic testing, validated anti-sycophancy and dependency monitoring, a trained crisis team, and an active adverse event process, with regulatory counsel and an independent reviewer added as approvers. Public launch requires all final thresholds met and an executive sponsor. Post-launch re-validation runs quarterly or on any material change.
Software teams ship when the tests pass and someone approves the merge. For an AI product that talks to people in distress, the tests and the approvers both need to be different, and they need to be written down before the pressure to ship arrives. Cindra's safety requirements document defines four gates. Each ties its criteria to numbered requirements, so a reviewer can trace every box on the checklist back to the requirement it verifies, and each names who must sign.
Gate 1: Alpha, internal testing
Approvers: engineering lead, clinical lead, product lead.
Seven criteria. The internal red-team suite has been executed and harmful content is under 5 percent across all categories, a looser bar than launch because the point of alpha is to find problems. The VERA-MH baseline has been run and documented. The ACT fidelity evaluation is complete. The crisis response library has been signed by clinicians. The escalation workflow is documented. The kill switch has been tested and verified. And the privacy infrastructure, meaning consent, encryption, retention, access controls, and audit logging, is implemented and audited.
Notice what is already required before a single internal user talks to the system: a working kill switch and an audited privacy stack. Those are not launch features. They are prerequisites for testing with real conversations at all.
Gate 2: Beta, clinician-supervised cohort
Approvers: the alpha three, plus regulatory counsel and an independent safety reviewer.
Alpha must have passed. Then eight more criteria. An independent third-party safety evaluation is complete. Clinicians have reviewed a sample of at least 500 conversations. Demographic subgroup analysis is done. The anti-sycophancy evaluation is complete. Dependency monitoring and risk scoring are deployed. The crisis team is trained and the service level agreement validated. And the adverse event standard operating procedure is active.
The addition of an independent reviewer at beta rather than launch is a deliberate choice. If an outside evaluator is going to find something, the team wants to know while the user population is small and supervised.
Gate 3: Public launch
Approvers: the beta five, plus an executive sponsor.
Beta must have passed. Then the final thresholds, covered in safety thresholds. VERA-MH sensitivity at or above 85 percent. Red-team harmful content under 1 percent for suicide and under 5 percent for eating disorders and substance use. All five axes of the five-axis evaluation passed. The transparency audit passed. The equity audit passed. The privacy impact assessment completed. Regulatory classification determined with counsel's sign-off. And post-launch monitoring infrastructure deployed and operational before, not after, the first public user.
The executive sponsor is there because public launch is the decision that creates the company's exposure, and the document wants a named person above the product team who has read the criteria and accepted them.
Gate 4: Post-launch re-validation
Approvers: engineering lead, clinical lead.
This gate runs on a schedule, quarterly, and on any change to the model, prompts, or knowledge base. Four criteria. The periodic re-validation has been performed. There are no unaddressed safety regressions, meaning every metric is at or above the previous release's threshold. All adverse events since the last review have been investigated and resolved. And the annual transparency report has been published, where applicable.
The no-regression criterion is the one that gives the gate teeth. Models drift, vendors update, prompts get tweaked to fix a complaint. Each change re-opens the gate. A product that cannot show it is at least as safe as its last release does not get to keep running unchanged.
The traceability behind the gates
Every criterion above references requirement IDs. The alpha red-team criterion is REQ-62. The crisis library sign-off is REQ-14. The beta clinician review is REQ-63. This is what lets the gates be audited: a reviewer can pick any checkbox and find the requirement, its acceptance criteria, its evidence artifact, and in the traceability matrix, the published evidence the requirement rests on. The chain runs from a paper to a requirement to a test to a signature.
Adapting the structure
The specific criteria are Cindra's. The structure is general. Four gates with increasing approver lists. Criteria stated as references to numbered requirements rather than as prose. A looser bar at alpha so problems surface, final thresholds at launch so they are fixed, and a recurring gate so the product cannot quietly degrade. Independent review before the user population grows. And a named executive who signs the launch. A team adopting this would change the thresholds and the requirement IDs and keep everything else.
Write the launch gate first
Before alpha, write the public launch checklist with the names of the people who will sign it. Show it to them now. The criteria they push back on are the ones you need to start measuring earliest, and the signatures you cannot get are the gaps in your governance. Discovering either at launch is the expensive version of this exercise.
Questions people ask
What should an AI companion pass before internal testing?
Cindra's alpha gate requires a completed red-team suite with harmful content under 5 percent, a VERA-MH baseline, fidelity testing, a clinician-signed crisis response library, a documented escalation workflow, a tested kill switch, and audited privacy infrastructure, approved by engineering, clinical, and product leads.
When should an independent safety reviewer be involved?
At the beta gate, before the user population grows beyond a clinician-supervised cohort. Cindra adds the independent reviewer and regulatory counsel as approvers at beta, so that outside findings arrive while the product is still small and supervised.
Who should approve the public launch of a mental health AI?
Cindra requires engineering, clinical, and product leads, regulatory counsel, an independent safety reviewer, and an executive sponsor. The executive sponsor is a named person above the product team who has read the criteria and accepted the exposure.
How often should a deployed AI companion be re-validated?
Cindra re-validates quarterly and after any change to the model, prompts, or knowledge base. The gate requires no regression on any safety metric, all adverse events resolved, and, where applicable, a published transparency report.
The full engineering and safety guide.
These articles are the short version. Building Compassionate AI is the long one: an emotionally aware agent modeled as active inference, governed by an explicit compassion objective, bounded by safety rules. Written for the people who have to ship it.
Read the guideThis 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.