Companion to The Divergence Tax. That essay makes the argument; this is the definition.
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.