The Five-Gate Deployment Model: A Deployment Discipline for AI Systems

Abstract

An institution can be asked two questions about an AI system in production. The first is whether it works. The second is how it got there, and who said it could. The second question is the one a supervisor, an auditor or a board asks after something has gone wrong, and it is the one most institutions answer worst, because the machinery that put the system into production was built to move work forward rather than to record who accepted what. This specification defines the Five-Gate Deployment Model™, a deployment discipline for AI systems. No AI system reaches production, or remains there, except by passing five gates in order: G1 Data and Design, G2 Validation, G3 Approval, G4 Deployment and G5 Operation. Each gate carries entry criteria supplied by a named framework, exit criteria, a defined rejection path, one accountable person, and a required evidence record. A gate with no rejection path is not a gate; a checkpoint that can only be passed is a formality. Two properties distinguish the model from the machinery it sits beside. The accountable role at every gate is a single named person and must not be a committee. A committee can be consulted, can review, challenge, advise and decide, and it cannot be accountable, because accountability distributed across a body is accountability no member of that body carries alone. The question an authority asks after a failure is which person is answerable. And every gate passage record is an instance of the BOE Declaration: the entry criteria are the boundary the gate fixes, the deployment freedom granted on passage is the optimizer it frees, and the record is the evidence that the boundary held. That mapping is not presentational. It is what lets a gate record be joined with a validation record, a residency attestation and a vendor screening record during an incident reconstruction, rather than merely filed alongside them, because two controls that emit evidence in one shape compose and two that do not are adjacent. Two paths run backwards through the model and are part of it rather than exceptions to it. Rollback reverses gate five to gate four with the evidence of the reversal preserved, because a rollback that removes the system and its records leaves the institution unable to reconstruct what the system did while it was live, which is precisely the period an authority will ask about. Loop-back reopens gate two when an incident occurs at gate five, on the reasoning that an incident is evidence about the validation as much as about the system: a patch applied without reopening validation changes the system and leaves the assessment of the system untouched, so the institution's belief about the system becomes older than the system. The specification states plainly what would falsify the model, and states it against the hardest comparison rather than the easiest: that institutions operating five gates with a single named accountable person at each are found to deploy unfit AI systems at the same rate, and with the same severity of consequence, as institutions operating an automated delivery pipeline enforcing equivalent entry criteria with no named approver. No institution unconnected to the author has been observed operating the full sequence. No readiness instrument exists, no gate evidence templates are published, and no trademark clearance search has been completed on the name. Each of those is stated in the document rather than left to be discovered. It is a specification, not a certification scheme, and no conformity assessment body operates against it.