Six Gates, Not One Checkmark

A release checklist with six boxes and one signature is not six checks. It is one person's judgement, repeated six times, because the same mind that ticks box one also ticks box six. That arrangement looks rigorous on a changelog and fails in exactly the way a single point of failure always fails: quietly, and only once it matters.

One list, six kinds of risk

Most software teams that ship AI systems inherit a habit from ordinary software release management: one release checklist, ticked off by one person, before the build goes out. For a web app that updates a cart icon, this is proportionate. For a platform that handles model inference, customer data residency, and automated decisions, it conflates six genuinely different kinds of risk into a single pass or fail signature.

Production readiness is an engineering question: does the build survive load, does rollback work, are the logs useful when something breaks at three in the morning. Design and UX is a different question entirely: does the interface tell the user what the system is doing and not doing. SOC 2 readiness is a compliance question, measured against a published trust-services framework, not a feeling that things are probably fine. Security and sovereignty is an infrastructure question: where does data actually go when the system runs, not where the documentation claims it goes. IP, licensing and provenance is a legal question: what can we truthfully claim to own, cite, or license. AI governance is a model-behaviour question: does this specific model, at this specific version, clear the thresholds we set for it, and who signs off when it does not.

A single reviewer, however conscientious, is not a security engineer, a compliance lead, a UX researcher, an IP solicitor and a model evaluator at once. Asking one person to tick six boxes does not produce six checks. It produces one person's confidence, repeated six times.

Six gates, six owners

We ship our own SIOS platform through six release gates, each tied to a named standard and a named owner domain. None of the six is ceremonial. Each one has blocked a release in the past, including gates most teams would assume were a formality.

• Production Readiness (engineering): owned by the engineering lead for the subsystem shipping. Evidence is a passing automated test and load suite plus a documented rollback path, not a verbal assurance that it works on one machine.
• Design & UX (design): owned by the design lead. Evidence is a usability and accessibility review against our interface standard, signed off by someone who did not build the screen.
• SOC 2 readiness (compliance): owned by the compliance owner, mapped against the relevant trust-services criteria, with control evidence attached rather than asserted.
• Security & Sovereignty (security): owned by the security lead. Evidence includes a runtime-tested check in continuous integration that proves no data egress occurs during inference, not a written statement that none should occur.
• IP, Licensing & Provenance (legal/IP): owned by the IP owner. Any patent claim in release material must cite a specific filed UK application number. We hold 104 filed applications covering approximately 2,340 claims at the UK Intellectual Property Office, and none of them is described as granted, because none of them is.
• AI Governance (governance): owned by the governance lead. Evidence is per-model evaluation results against set thresholds, red-team sign-off, confirmation that human-in-the-loop controls are live where required, and that the actions the system took are sealed into an audit record it cannot rewrite afterwards (we use our own Open Audit Record format for this: a hash-chained, post-quantum-signed receipt that any vendor could adopt, not a lock-in feature).

Named owner: accountability is a person, not a process

A gate without a named owner is not a gate, it is a line item. The difference matters on the day a release is good everywhere except one place. If the checklist just says security: pass, nobody outside the room knows who decided that, on what basis, or who to ask when it turns out to be wrong six months later. Naming the owner by role, not just by sign-off, means the security gate is always answered by whoever currently holds the security brief, not by whoever happened to have write access to the ticket that week. When a gate fails, the owner is also the person who can explain why, which is a different thing from the person who can explain why they approved it anyway.

Evidence attached: a passing run, not a promise

Each of our six gates requires an attached artefact, not a tick. For production readiness that is a CI run with a timestamp and a result. For security and sovereignty it is a step that actually attempts to exfiltrate data from a running inference session and confirms the attempt fails, executed on every build, not audited once at launch and assumed to hold ever after.

# ci/no-egress-check.yml (illustrative)
- name: attempt-egress-from-inference-pod
  run: |
    start_inference_session --isolated
    probe_outbound --target external --expect blocked
    probe_outbound --target metadata-service --expect blocked
  on_failure: block_release

For IP and provenance, the artefact is the application number itself, checked against our own filing record before it appears in any public material, not a marketer's recollection of how many patents we hold. For AI governance, it is the evaluation report for that model version against its threshold, plus the red team's sign-off, both time-stamped before release rather than written up afterwards to match whatever shipped.

Independent gate: six judgements, not one repeated

This is the part that is easy to simulate and hard to actually build: independence. A release manager who personally ticks security: pass after reading a report someone else wrote is not running an independent security gate, they are running a literacy test on a report. The gate is independent only when the person who can block the release on security grounds is the person whose job is security, and that person did not write the feature being reviewed. The same split holds across all six: the engineer who built a capability does not clear its own UX gate, and the product manager who wants a ship date does not clear the governance gate for the model being shipped.

Six gates owned by six different domain experts is not slower than one checklist ticked by one generalist, it is differently shaped. It fails faster, in private, before release, because the person most likely to catch a security problem is looking specifically for security problems, not reading down a list where security is item four of six and starting to skim by item three. One checklist conflates six risks into one person's judgement. Six gates, each with a named owner and attached evidence, make that judgement six separate, accountable, and genuinely independent decisions. That is the difference between a release process and a formality.