Release-Gate.

What this is

The Release-Gate workflow is the procedure that decides what's allowed to ship. It specifies the gate (the eval suite plus traditional tests, a refuse-policy check, accessibility, and any feature-specific metrics), it documents per-feature thresholds, and — critically — it enforces those thresholds in CI so a release that fails the gate cannot deploy without an explicit, documented override.

The procedure

1. Spec the gate. Write the checklist. What runs on every PR? What runs on every release? What blocks merge vs. blocks deploy?
2. Document thresholds per feature. Each AI feature has a documented score-below-which-we-don't-ship. The threshold is reviewed quarterly.
3. Wire CI to enforce. Eval suite runs on every PR. Threshold breach blocks the merge — not advisory, enforced.
4. Document the override policy. Sometimes you ship over a failed gate. When you do, who approved it, when, and why — written down, audited, dated.
5. Review thresholds quarterly. Drift them up as the feature matures. A threshold that doesn't move is a threshold no one is paying attention to.

What gets scored

The five questions on the readiness self-assessment that score this dimension are the five rungs of the procedure above. Yes on a question means the artifact named in that step exists on disk in your repo today.