Change-Intent Governance: The Missing Layer

Two kinds of control planes dominate the 2026 platform tooling landscape. An internal developer platform — Backstage, Port, Cortex, OpsLevel — holds the catalog: what services exist, who owns them, how they depend on each other. And, increasingly, an AI agent governance layer — MCP gateways, model gateways, human-in-the-loop approval flows, runtime observability — watches what agents are allowed to do, one tool call at a time.

Both layers are real and both are worth having. But there is a concrete question neither of them can answer: this change that is about to land — which projects does it affect, who approved it, and where is the evidence?

The catalog cannot answer, because it governs inventory, not change. The agent gateway cannot answer, because it governs actions, not intent. The answer lives in a layer most stacks do not have. I have come to call it change-intent governance, and this essay is about why AI-native delivery turns it from a nice-to-have into a requirement — and what a minimal implementation of it looks like. My vantage point, stated up front, is a single-person AI-native delivery practice: small, but it runs into this gap at full speed.

What the two existing layers actually govern

An internal developer platform governs what exists. Its catalog of services, owners, and dependencies is assembled by integrations that sync from source repositories, CI systems, and cloud providers — which means it is a belief about the portfolio, continuously re-derived, and it drifts whenever the sync lags reality. More to the point, the IDP's self-service layer is built to execute. Some platforms go further: Port's workflows can compute a blast radius over the catalog graph and pause for a human approval when it crosses a threshold — the closest thing this layer has to change-aware gating, and worth having. But the prediction is written back into the same overwritable catalog it was derived from, as a property the next sync or the next writer can silently replace, and part of the judgment is delegated to an LLM-scored risk field. What is still missing is the evidentiary form: an impact claim computed deterministically from an immutable, identified snapshot, and an approval bound to that exact computation in an append-only record that neither the platform nor the requester can rewrite.

The agent governance products emerging this cycle govern what is happening at runtime. A gateway can allow or deny a tool call, require a human to approve a sensitive action, and log every request an agent makes. That is genuinely useful — and it is scoped to the granularity of a single action by a single agent. A tool-call log can tell you an agent wrote to a file. It cannot tell you which portfolio-level change that write belonged to, what the change was expected to affect, or whether anyone accepted responsibility for the whole of it.

So the catalog governs what exists, and the gateway governs individual actions as they happen. A proposed change — with its predicted impact across project boundaries and an accountable decision about it — is at best a property written into the catalog, where the next sync can overwrite it. It is never a record that stands on its own evidence.

IDP / service catalog

What exists

“What do we have, and who owns it?”

Mutable catalog, continuously re-synced

Change-intent governance

the missing layer

What is about to change

“Which projects does this affect, who approved it, and where is the evidence?”

Immutable snapshot + append-only ledger

Agent gateway

What is happening right now

“Is this tool call allowed?”

Per-action request log

Why the gap became load-bearing

When humans wrote most of the code, this gap was tolerable, because the git log was reviewable at human speed. A tech lead could hold the week's changes in their head; "what does this touch?" was answered by reading the diff and knowing the codebase.

AI-native delivery breaks that assumption. When agents produce most of the code — which is how my own operation runs — change volume grows past what any person can reconstruct from commit history. The failure mode is not one bad change slipping through review. It is that the organization loses the ability to answer after the fact which changes touched which projects on whose authority, because that information was never recorded as a first-class artifact — it existed only as context in someone's head, or in an agent session that has since been discarded.

I made the general argument in Accountable Generation: as generated output gets cheap, governance has to attach to intent, because intent is where accountability lives. This essay is that argument applied to the layer between projects. Within a single repository, intent-level governance is a code review discipline. Across a portfolio — where one change ripples through dependency edges into projects owned by other people, or by other agents — it needs machinery.

What the machinery has to provide

Strip the problem to what an auditor, an incident review, or a future maintainer actually needs, and the requirements are surprisingly few. These are properties of the record, not features of any particular tool:

• A portfolio snapshot as evidence, not as live belief. Project boundaries, dependency edges, and source-of-truth claims captured at a point in time, so that every downstream judgment can cite the snapshot it was derived from. This is the opposite of the IDP's continuously synced catalog: a snapshot can be stale, but it cannot drift silently, because its identity is part of the record.
• Impact derived, not asserted. "This change affects these projects" should be computed from the snapshot's dependency edges and source-of-truth rules, so the claim is reproducible from evidence rather than typed into a ticket from memory.
• Change intent as an append-only record. A proposal, the approval or rejection it received, the remediation plan if one was required, the runner sessions that executed work, and the evidence they produced — each an explicit record with an actor attached, none of them editable after the fact. Not a wiki page. A ledger.
• A read-only posture toward source repositories. The governance layer observes and records; it does not reach into repositories and mutate them. This keeps the audit trail trustworthy — if the layer had write access to the repositories it observes, it could also alter the evidence of what happened — and keeps the blast radius of the governance layer itself at zero.
• Actor-gated writes. Every record that enters the ledger names who put it there. "The system decided" is not a recordable state; every decision is an explicit record by a named actor, human or agent.

None of this replaces the catalog or the agent gateway. It sits between them: it consumes the kind of topology the catalog knows, and it gives the agent layer's actions something to belong to — a governed change with an owner.

A reference implementation

I maintain an open-source reference implementation of this layer: aine-control-plane (Apache-2.0, v0.7.0 at the time of writing). It is a dependency-free Python core plus a reference HTTP transport and a local React UI, built around exactly the requirements above: Registry snapshot ingest with project, dependency, and source-of-truth views; impact analysis derived from those snapshots; append-only SQLite evidence and audit storage; and change-request, approval, remediation-plan, and runner-session workflows where every decision is an explicit, actor-attributed record. The core has no source-repository mutation APIs and makes no network calls.

I should be equally clear about what it is not, because this is the part positioning writing usually overstates. It is a reference implementation, not a SaaS — there is no hosted tenant, no billing, no hardened multi-user deployment; the reference transport binds locally. It is the work of a single-person operation, shaped by running one AI-native delivery practice, not by a hundred enterprise deployments. And it does not compete with the layers on either side of it: if you need a service catalog, you still want an IDP; if you need runtime enforcement of agent behavior, you still want that gateway. What it offers is the contract for the layer between them — portable schemas, conformance tests, and a working demonstration that the layer can be small.

Three questions for your own stack

The cheapest way to test this argument is against your own organization:

1. When a change lands across more than one repository, is its blast radius recorded, immutably, as a claim someone approved — or only discoverable, after the fact, by an engineer reading diffs?
2. If an auditor picks one significant change from last quarter, can you produce the chain — proposal, impact, approval, execution evidence — or would you be reconstructing it from chat logs and git archaeology?
3. As agents take over more of your code production, is your answer to the first two questions getting better or worse?

The catalog answers what you have, and the gateway answers what the agents are doing right now. Neither answers which change touched which projects on whose authority, backed by records that cannot have been quietly rewritten. That is a separate layer, and the point of the reference implementation is to show it can be small — small enough to add before an audit or an incident forces the question.