The term. The divergence rate is the distance between the commercial edition and the one inside a compliance boundary: a FedRAMP authorization, a sovereign region, an on-prem build for one customer. Three quantities make it up. Features shipped to the commercial edition per period, the share of those that reach the boundary late or never, and the lag in days between the two ship dates. Multiply them and you have the cost the certification budget leaves out.

Example. A team ships forty features a quarter to the commercial edition. Twelve depend on a service the boundary does not have yet, so they arrive a quarter later or not at all. The ones that arrive wait a median of ninety days for change control and evidence. That is twelve features a quarter running three months behind, and that’s before anyone counts the evidence work. The real cases are in the essay: Lambda’s twenty-five months to GovCloud, Copilot’s agents missing from GCC High, GovSlack without the MCP server.

What counts. A feature is anything a customer can see or a salesperson can list. Shipped in the boundary means available to a boundary customer, with its evidence attached. A flag that stays off because a dependency is missing counts as never, until it turns on. The lag starts on the commercial ship date. Count per quarter; anything finer is noise.

What it is not. It is not the certification cost, which is priced, dated and approved before the rate starts running. It is not the provider’s service gap; that list is an input, not the rate. It is not feature parity, which is a snapshot where the rate is a speed. Also it is not an industry term, the established terms describe one environment or one change. Configuration drift is an environment leaving its declared state. Compliance drift is controls leaving what was authorized. FedRAMP’s significant change is “a change that is likely to substantively affect the security or privacy posture of a system.” They are causes of the rate, not names for it.

Who sets it. You do. The regulation defines what is inside the boundary and says nothing about how you build it, so the rate is set by where your dependencies live. A managed service has to exist inside the boundary before anything built on it can ship; an artifact you build yourself needs only compute, which is what a new boundary gets first. A copy of the stack starts with a high rate. One more deployment target, same artifact, flags scoped to it, evidence from the same pipeline run, keeps it low.

Where it lives. Before the boundary exists, as a projection next to the certification cost, in the same approval. After it exists, on the dashboard next to uptime: features shipped commercially this quarter, the share that reached the boundary, the median lag in days.

Elsewhere the term names the same shape of thing, how fast two things that start together move apart: the Lyapunov exponent in dynamical systems, the rate of sequence divergence in genetics.

I have been using the term since April for the opposite direction. In a delivery pipeline the machine writes the code but does not make the decision that matters. A person accepts that code into production, and that acceptance is the record nobody keeps.

The Four Facts

Four facts, recorded for every change that reaches production, captured while they are still true.

Who or what generated it. Human, agent, or a mix of both, with tool and model identity when an agent was involved. Most teams can only answer this by asking the author, assuming you can find one.

What a human actually reviewed. Not that somebody approved it, but how deeply they looked: read line by line, sampled, delegated to the gate, or auto-approved under policy. Recorded as an explicit state rather than inferred later from how confident the approver sounded.

The blast radius. What the change can plausibly break, in the terms the business uses: data exposure, availability, money movement, compliance surface. Somebody spends ten seconds on that question before the merge instead of during the incident call.

The owner. The named person accepting the residual risk. Not the committer by default, and not “the team”.

What It Is Not

Not git blame. Blame tells you whose name is on a line, but not what that person understood when they put it there.

Not supply-chain provenance. SLSA and in-toto answer what produced an artifact and they answer it well, but they describe artifacts rather than decisions. An attestation can prove an agent built the binary without telling you whether anyone decided that was acceptable.

Not verification. Verification tells you the code is sound, in seconds, and it keeps improving, but it says nothing about who owns the outcome. I made that argument at length in Verification Is Not Accountability.

Not a compliance artifact, though it will end up in audits. It exists so the next postmortem has a chain of decisions to walk back. Incident review has always worked that way, and agents did not remove the decisions, they removed the record of them.

Keeping It Small

Four fields, not a taxonomy. Governance efforts tend to start with a reasonable list and arrive eighteen months later at a form nobody fills in honestly, and a record filled in dishonestly is worse than none.

Mechanically it stays small too. A git trailer or a CI annotation carries the generator. Review depth is a required field on the merge template with four permitted values. Blast radius comes from signals static analysis produces today. The owner is a name. A governance layer that needs its own product will lose to the pipeline every time.

Where the Record Lives

The merge path. Your pull request and the gate sitting on it are the only point every change passes through, and the only point that can stop something.

A wiki copy goes stale within a quarter, and a governance document nobody reads is stale on the day it is written. The record has to fall out of the pipeline that is running anyway. I have had to do the reconstruction version of this in a regulated programme, and it costs many times what capturing the same evidence in flight would have.

So your gate answers two questions instead of one. May this code proceed, and is the decision record complete for this class of change. Incomplete record, no merge.

Where to Start

Four moves, and none of them is a six-month programme.

Measure the gap on one change. Pick an agent-authored change that merged into a consequential path last month, then try to reconstruct the four facts. However long that takes is the gap, measured.

Define what review depth means. Not a policy document, a short list your teams will actually pick from: read line by line, sampled, delegated to the gate, auto-approved under policy. Four values, argued about once, then put in the merge template.

Use the blast-radius signals you have. Static analysis knows when a diff touches auth, data access or payment paths, so start with those three. A risk taxonomy can wait.

Decide who declares and who owns. These are different people more often than teams expect. Whoever reviewed declares the depth, and the owner accepts the residual risk.

Most organizations owe a version of this record under SOX change management, and enterprise customers ask for it before regulators do. The question is whether you capture it while it is true or reconstruct it afterwards at several times the cost.

Traceability by design. Every AI-assisted change should carry provenance as a commit property, a git trailer or CI annotation recording the tool, the context, and whether the output was accepted as-is or modified. Tag at commit time, make it queryable, build from there. If you can’t answer “was this AI-generated, by what, and who accepted it?” within minutes of an incident, you’ve found your first gap.

Ownership as a two-sided contract. The developer owns intent, they accepted the suggestion, they clicked merge. The organization owns the environment, which tools it provides, what review standards it enforces, what quality gates it builds or doesn’t. When a CI pipeline treats AI-generated and human-written code identically, that’s an organizational decision. When review checklists don’t account for AI-specific failure modes (contextual bugs, architectural misfit, missed constraints), that’s a process gap, not an individual one. Both sides have to be explicit.

Governance in the development path, not after it. Governance checkpoints belong where decisions happen, at commit, in CI/CD, in code review. Not in a policy document nobody reads. This means trust layers, a generated utility function doesn’t need the same scrutiny as a generated authentication handler. Risk-based gates, applied automatically, with measurable signals.

The Tooling Is Closer Than You Think

What i find encouraging is that the building blocks for most of this already exist. They’re just not being assembled with governance in mind.

What to look for in governance tooling. Not every quality or security tool can extend to governance. The ones that can share specific characteristics: they sit in the code path natively (not bolted on after), they observe actual code at scale (not survey-reported adoption), they can surface AI-attribution signals and patterns associated with generated code, and they have a progression story from quality to security and to governance using the same underlying data.

The gap isn’t tooling. It’s integration and intent. Connecting provenance metadata to quality gates to ownership records: that’s the missing layer.

The Governance Control Plane

What ties this together is a control plane for engineering governance — a layer that tracks decision lineage across humans and AI, enforces policy before code ships, and makes ownership observable. Without it, accountability is retrospective. With it, accountability becomes a system property.

Where to start: Run a provenance test on a recent PR. Get legal, CISO, and platform engineering in a room to make the ownership decision explicitly. Assign the mandate to one team. Instrument your pipeline with basic AI-origin tags. Four moves, all achievable in weeks.