The AI SDLC / Part IV / §19
Section 19 of 44 3 min read

The Four Gates

Intake, merge, release, and operational action — each a pass-or-fail decision, never a scorecard.

Gates are the points where the framework’s controls actually bind. Each is a pass-or-fail decision, not a scorecard—partial satisfaction is failure, because a gate that admits partial satisfaction is a checklist.

Figure 7Where the controls bind
GATE 1Intake

An agent is granted a task and a scope

Owner
Engineering leadership
GATE 2Merge

A change enters the trunk

Owner
Platform, not convention
GATE 3Release

A change enters production

Owner
Release authority
GATE 4Autonomy

Tier, scope, or authority increases

Owner
Review body

The four action boundaries defined in Section 2, expressed as gates with owners. Controls placed before a boundary are preventive; controls placed after it are forensic.

19.1 Gate One — Intake #

01

Intake

Applied when an AI participant is granted a task and a scope. Owned by engineering leadership.
  • Agent registered with a unique identity and a named accountable human
  • Autonomy tier assigned and approved at the required authority level
  • Scope enumerated: repositories, paths, tools, environments, data classes
  • Execution isolation configured; egress default-deny with an owned allowlist
  • No standing credentials in the execution context; credential lifetime documented
  • Qualification completed for the tier requested, with criteria and approver recorded
  • Work class registered with a declared, demonstrated oracle that the agent cannot modify
  • Turn and budget ceilings configured; termination reasons emitted as typed telemetry
  • Entry and stop conditions defined for the work class, configured to halt rather than alert
  • Review cost for the class estimated and confirmed against available capacity
  • Concurrency limits set for the target repositories, with scope partitioned by path
  • Decommission criteria and review date defined

19.2 Gate Two — Merge #

02

Merge

Applied to every change entering a protected branch. Enforced by the platform, not by convention.
  • Change attributable to an identified principal; agent-authored change signed and session-linked
  • Agent cannot approve its own change; enforcement verified, bypass actors reviewed
  • Review performed at the tier the change’s risk classification requires
  • Configuration, dependency manifest, and infrastructure changes reviewed as privileged code
  • New dependencies allowlisted; versions resolved by policy and pinned with integrity hashes
  • Concealed-character scan clean on configuration and instruction files
  • Static analysis and secret scanning blocking, with findings adjudicated rather than suppressed
  • Tests independent of the generating context; suite sensitivity verified by mutation or property testing
  • Held-out verification signal passed where the work class carries one; visible-to-held-out gap within threshold
  • Evaluation gate passed where the change touches a model-backed capability
  • Architectural constraint checks passed, including duplication threshold
  • Requirement traceability identifier present

19.3 Gate Three — Release #

03

Release

Applied to every promotion into production, including model version changes with no code change. Owned by the release authority.
  • Release manifest identifies agent-authored components and model versions
  • SBOM produced, covering AI components where present
  • Artifacts signed; provenance verified rather than merely emitted
  • Separation of duties preserved across generation, approval, and deployment; verified this quarter
  • Non-functional gates passed: accessibility, performance, resource ceilings
  • Evaluation thresholds met with intervals reported, not point estimates
  • Rollback trigger defined on quality distribution, with measured time-to-effect
  • Operational readiness confirmed: telemetry, cost attribution, kill switch tested
  • Approval recorded and attributable to a named human

19.4 Gate Four — Autonomy Expansion #

04

Autonomy Expansion

Applied whenever an agent’s tier, scope, or authority increases. Owned by the review body; never automatic.
  • Operating evidence produced for the current tier: defect rate, rework rate, scope adherence, conflict rate, incident involvement
  • Review integrity metrics within threshold for the affected repositories
  • Findings triage capacity sufficient at the projected volume
  • Absorption capacity modeled at the new volume and confirmed available
  • Blast radius at the new scope enumerated and bounded
  • Controls required by the new tier implemented and verified, not planned
  • Oracle strength adequate for the new scope, given that verification degrades with scope rather than with model quality
  • Reward-hacking indicators within threshold: visible-to-held-out gap, escalation rate, oracle-modification attempts
  • Kill switch tested at the new scope with measured time-to-effect
  • Risk acceptance signed at the tier-appropriate authority, with a review date
  • Termination conditions defined for the expanded scope

The fourth gate is the one organizations most often skip, because expansion usually happens by accretion rather than by decision—a scope widened here, a repository added there, a bypass actor configured to unblock a deadline. Expansion by accretion is how an A1 deployment becomes an A3 deployment without anyone approving an A3 deployment.

PDF↓