For decades, software engineering has been obsessed with the concept of the "Single Source of Truth." We believed that if we could only capture the requirements perfectly — in a PRD, a Figma file, or a Swagger doc — the implementation would naturally follow.
But documents are static. Code is fluid. In the gap between the two lies the most expensive part of building software: the maintenance of alignment. We don't need better documents. We need a better way to describe intent through change.
Specs are snapshots. Systems evolve.
The standard response to the document-code gap has been spec-driven development: write a spec before generating code, hand the spec to an agent, validate the output against the spec. This is better than prompting. It is better than no spec at all. It is still producing snapshots.
A specification is a description of what the system should be at the moment the spec was written. Every spec is born expiring. The moment the first test reveals an edge case, the moment a new regulation arrives, the moment a downstream consumer changes their contract, the spec lags. The catch-up work eats the gains from faster generation.
Teams running spec-driven tools at scale see it immediately: the snapshot goes out of date within hours. Not weeks. Hours. Faster than anyone can re-take it.
The fix is not better snapshots. The fix is to stop pretending the system has a fixed state worth snapshotting. The interesting artifact is not what the system is. It is how the system changes.
What the delta actually captures
Treat the declaration as a record of evolution rather than a description of a state. Each change to the system becomes a declaration of intent: what field is being added, what policy is being enforced, what failure mode is being notified, what constraint is being tightened. The declaration does not describe a version 2 of the user. It describes the delta from version 1 to version 2.
A delta declaration names the change, the reason, the constraints that must hold across it, and the signals that tell a human when something went wrong. It is small enough to review in one sitting, specific enough to validate against, and structured enough that an agent can act on it without guessing. When a developer, an AI agent, or a reviewer reads it, they are not seeing a snapshot that has already aged. They are seeing a trajectory.
Deltas compose. Ten deltas applied in sequence produce the current state, and the current state is always recoverable from the declarations that made it. Snapshots do the opposite: they go stale and the history behind them evaporates.
Killing the synchronous workflow
The document-first approach creates a waterfall, even in "agile" teams. Designer hands to developer. Developer hands to QA. QA hands to ops. Each handoff is a lossy compression of intent. The originator knows why the field should default to false. The implementer sees a checkbox in a Figma. The reviewer sees a PR diff. The ops engineer sees an alert at 3 a.m. with no idea what the constraint was supposed to guarantee.
By focusing on the delta, the handoffs collapse into a single shared artifact. The declaration moves with the change. The reviewer of the declaration is reading the same thing the agent used to generate code, the same thing CI will validate against, the same thing the incident responder will read when the alert fires. Nothing is compressed between stages because the stages share the source.
This is the operational difference between a spec and a delta. A spec goes into a PR, gets approved, and then nobody reads it again. A delta stays live. It is the artifact every downstream consumer queries, for the life of the system.
What review becomes when the delta is the artifact
Review today is a conversation about code. Is this the right implementation? Does it match the style guide? Did we miss an edge case? Those questions are worth asking, but they are downstream of a question nobody is forced to answer first: is this the delta we meant to declare?
When the declaration is the primary artifact, review happens upstream. Is the change scoped correctly? Does it contradict an earlier declaration? Does the constraint it introduces conflict with a contract we already have? These questions are faster to answer than questions about code, because the declaration is smaller, and they catch the mistakes that matter most — the ones that produce architecturally correct code solving the wrong problem.
The review of the generated code still happens. It becomes a check that the implementation matched the delta, not a hunt for the intent the implementation should have honored. That is a smaller, more tractable job, and it is the one current review processes are actually good at.
The delta outlives the document
A document is finished when someone signs off. A delta is finished when the next one supersedes it. The system has no "done" state. Every change is either declared and reconciled, or it is invisible drift.
Teams that treat specs as the artifact end up maintaining two things that disagree: the spec and the code. Teams that treat the delta as the artifact end up maintaining one thing: the declaration that every agent reads, every reviewer approves, every CI check enforces. The document-versus-code gap closes because there is no document to disagree with the code. There is only the declared change, continuously applied.
Stop writing better documents. Start declaring better deltas.
Specs drift because they describe states. Deltas survive because they describe decisions. We're building the tooling that makes the delta the live artifact, not the stale document.