The governance gap AI-driven delivery can't outrun

The SDLC is not dying. It is migrating from documents into the execution engine. Requirements become machine-evaluable contracts. Approval gates become evidence-sufficiency rules. The phases are the same. The enforcement surface moved.

AI-driven development has accelerated this migration to the point where it can no longer remain half-complete. Most organisations understand the direction. Many have started. Almost none finish.

The reason is not technical. It is that the function which would complete the migration does not look like delivery work.

The invisible function #

Promotion governance requires rules. Most organisations centralise them: security policies, compliance requirements, quality standards, written down, version-controlled, available to every team.

This feels like governance. It is not.

Two teams subscribing to the same security rule will interpret it differently. One team’s “adequate security review” is a threat model and a penetration test. Another’s is a checklist and a sign-off. Both believe they are compliant. Both are following the same rule. Neither knows the other exists.

The missing function is interpretation binding: not just “this gate subscribes to rule X” but “in this context, rule X means this specific evaluation.” A declaration of what the rule means here, versioned and auditable, so that interpretation drift becomes visible before it becomes a failure.

This function is invisible because its output is documented understanding, not shipped software. No team is staffed to produce it. No role owns it. The work of declaring “what this rule means for this gate” looks like paperwork, not delivery. So it does not get done.

Centralised rules, without bound interpretation, produce decentralised meaning. The governance surface looks complete. The interpretation layer underneath is informal, inconsistent, and invisible until an audit or an incident traces a failure back to it.

The half-executable state #

This is why most organisations stall.

They automate the obvious: CI/CD handles build and deployment, automated tests run on every commit, static analysis flags known patterns. Execution accelerates.

The governance layer does not migrate at the same pace. Promotion decisions still depend on unrecorded judgement. Policy enforcement is still manual or periodic. Evidence is still assembled after the fact for audit purposes.

The result is machine-speed delivery under human-speed governance. Risk does not decrease. It becomes less observable. Failures surface later, appear sudden, and are harder to trace.

This condition feels like progress. Velocity metrics improve. Deployment frequency increases. The structural gap between execution speed and governance speed widens quietly, and the cost arrives late.

The half-executable state is not a transition. Left unaddressed, it is a destination. Organisations do not naturally complete the migration because the function that would complete it does not register as work. They settle at the point where execution is fast and governance is tolerable, and the distance between the two grows until a failure makes it visible.

What completing the migration requires #

The structural move that makes promotion governance executable is separating gate logic from evidence production. The gate is a rule engine. The evidence sources are a portfolio. Conflating them leads to gates that are either too rigid or too invisible.

The promotion gate is a familiar concept in delivery systems, though its formal properties are still being defined as governance becomes executable. The gate logic is deterministic: are the required evidence records present, and do they satisfy the governing rules? The evidence itself need not be. A human design review, an AI code assessment, a security scan: all are valid evidence sources. What matters is that each produces a governed record with explicit identity, scope, method, and confidence, and that the gate evaluates evidence sufficiency, not evidence origin.

That separation is necessary. It is not sufficient.

The governing rules themselves carry a distinction that most frameworks ignore. Some rules are deterministic: a test coverage threshold either passes or it does not. Some are interpretive: whether a design review is sufficient requires human judgement. Some are contextual: what counts as adequate security evidence depends on the deployment environment.

If the distinction between deterministic, interpretive, and contextual rules were made explicit, it would become the structural decision that determines what can be automated, what requires human judgement, and where the throughput constraint actually sits. Without it, organisations discover the constraint implicitly, when throughput collapses at the gate that still requires a human.

There is a further structural gap in how most governance designs handle failure. The approval path is governed: evidence is recorded, decisions are traceable, the audit trail is complete. The denial path is not. When a gate denies promotion, the record of that denial rarely carries the same completeness as the record of approval. Which rule triggered the denial, which evidence was insufficient, what the escalation path is: these are often absent.

Without governed denial, the gate becomes a bottleneck without a feedback mechanism. Teams resubmit without understanding what failed. When denial produces a governed record as complete and traceable as approval, the gate becomes diagnostic, not just obstructive.

The question that matters #

The SDLC did not die. It moved. The structural question is not whether to make the lifecycle executable. That migration is already underway.

The question is who owns the interpretation.

Separating gate logic from evidence production is the tractable structural move. Beyond that, the open design questions are the ones that determine whether governance actually scales: how to classify rules by evaluation type, how to bind interpretation to subscription, whether the denial path should carry the same governance as the approval path. These are not automation problems. They are design problems whose answers require a function that most organisations have not yet recognised as work.

Acceleration is structural. The response has to be structural too. And the hardest part of the response is not building the system. It is staffing the function that makes the system honest.