The ADLC in one diagram, explained slowly
Six stages and two loops. Most of it is your existing life cycle unchanged. The parts that are new are new for a specific reason, and it is worth walking each one at reading pace.
I have been avoiding drawing this, because life cycle diagrams have a bad history. Every methodology ever sold came with a circle of arrows, and the circle of arrows was usually the least honest part of the pitch: too clean, too symmetric, no queues, no rework, no politics.
So here is the diagram with a warning attached. It is not a process you install. It is a description of what has to be true once agents are producing a meaningful share of your changes, drawn so that you can point at the parts you already have and the parts you do not.
+---------------------+
| 1. INTENT |
| what and why |
+----------+----------+
|
v
+---------------------+
+--------->| 2. SPECIFICATION |
| | done, checkably |
| +----------+----------+
| |
| v
| +---------------------+
| | 3. EXECUTION |
| | agent or human |
| +----------+----------+
| |
| v
| +---------------------+
| | 4. VERIFICATION |
| | machine, then |
| | human judgement |
| +----------+----------+
| | |
| fails | | passes
+---------------+ v
(loop A: back +---------------------+
to spec, not | 5. RECORD |
to execution) | derived from |
| ground truth |
+----------+----------+
|
v
+---------------------+
| 6. PROOF |
| signed, reversible|
+----------+----------+
|
loop B: what we learned
feeds the next intent
|
v
(back to 1)
Six stages, two loops. Let us go through it slowly, because the value is entirely in the details of where it differs from what you have.
1. Intent
Someone wants something. A customer asked, a metric moved, a regulation landed, a bug got noticed, somebody had an idea.
This stage is unchanged. It is human, it is political, it involves taste and negotiation and the ranking of incommensurable things, and no part of it gets automated in any way I find plausible. If your intent stage is broken, meaning you build things nobody wants, nothing in this series helps you. You will build things nobody wants faster and with an excellent audit trail.
I include it in the diagram only to mark the boundary. Everything downstream is in service of intent, and a life cycle that optimises stages 2 through 6 while ignoring stage 1 is a very efficient machine pointed at nothing in particular.
2. Specification
Here is the first real change, and it is the one that carries most of the weight.
In the SDLC, specification was a communication act. You wrote enough for a human to understand what you wanted, and their judgement filled the rest. The gaps were fine, because the gaps got closed by a person who would come and ask you about them. Specification was prose because prose is how humans transfer intent.
In the ADLC, specification is an interface. It is read by something that will not ask, will not notice ambiguity, and will resolve every gap silently and plausibly. So the specification has to carry its own completeness.
Concretely, this means acceptance criteria that can be evaluated rather than interpreted. Not “the export works properly” but the specific observable conditions: what the endpoint returns, what the artefact contains, what happens for a request from a different tenant, what happens when the record set is empty. Someone reading those should be able to say true or false without asking the author what they meant.
Two things people get wrong here, consistently.
Specification as communication
- Written for a human to understand
- Their judgement fills the gaps
- Gaps are fine, they get noticed
- Ambiguity surfaces as a question
Specification as interface
- Read by something that will not ask
- Every gap resolved silently and plausibly
- Conditions evaluated, not interpreted
- Attached to the work, checked at the transition
The first is thinking this means writing more. It usually means writing differently and often less. Three checkable conditions beat two paragraphs of context-setting, and the context-setting was mostly there to give a human reader enough to fill the gaps with.
The second is thinking this is a documentation exercise that lives on a wiki. If the criteria are not attached to the work and evaluated at the transition, they are decoration. The whole point is that stage 4 can check against them mechanically, and that requires them to exist as data rather than as a paragraph someone might read.
3. Execution
Agent, human, or both. Honestly the least interesting box in the diagram, which is the argument of an earlier piece in this series and I will not relitigate it here.
Two things about it that do matter.
It is no longer the constraint. Everything about how you organise should reflect that, and most organisations still allocate their attention and their headcount as though this box were the expensive one.
It is now parallel and cheap enough that rework is not a disaster. This changes the economics of the whole diagram. When execution took three days, you optimised hard to avoid doing it twice, which is why so much SDLC process is front-loaded gatekeeping designed to prevent wasted implementation. When execution takes twenty minutes, throwing it away costs almost nothing, and processes built to prevent that waste are now protecting against a cost that no longer exists while imposing their full price.
When execution took three days, you optimised hard to avoid doing it twice. Every process around it was built on that assumption.
Cheap parallel execution changes the economics of the whole diagram, and it is what makes a loop back to specification affordable. Ten years ago that arrow would have been unthinkable.
That single shift justifies loop A below, which would have been unaffordable ten years ago.
4. Verification
The stage that absorbs everything the other stages stopped doing, and therefore the one that needs the most careful design.
It has two halves and the order matters.
Machine first. Everything checkable gets checked without a human: tests, types, security scanning, and critically the acceptance criteria from stage 2 evaluated against what was actually built. Not “did it merge” but “does the thing do what we said it must.” The failure of most current setups is not that they lack automation, it is that all of their automation checks that nothing broke and none of it checks that the intended thing happened.
Human second, and only on what is left. Architecture, fit, coherence, whether this is a pattern you want repeated, whether the change is quietly making the system harder to reason about. This is irreducible and it needs people with system context, which is your scarcest resource. The entire purpose of the machine half is to make sure this half is spent on questions that actually need it, rather than on confirming that a rename was a rename.
If you take one operational thing from this diagram, take the order. Human review before machine verification is the default in most organisations and it is backwards. It spends the expensive resource first.
Loop A: failure goes back to specification
This is the arrow people skip, and it is the one that separates a life cycle that improves from one that just spins.
When verification fails, the instinct is to send it back to execution. Fix the code. Try again. That is correct when the specification was right and the implementation was wrong.
But a large share of verification failures in agent-heavy work are not implementation failures. They are specification failures wearing an implementation costume. The agent built exactly what the criteria described, and the criteria described the wrong thing, or described it incompletely, and the gap was filled with something reasonable and unwanted.
If you route those back to execution, you get a rebuild against the same flawed specification and a second failure that looks slightly different. Teams can loop this three or four times without anyone stopping to ask whether the ticket is wrong, because each individual iteration feels like progress.
So the default routing should be back to stage 2, with an explicit question: was the criterion wrong, or was it right and unmet? Answer that first, every time. This costs about ninety seconds and it is the highest-return ninety seconds in the diagram, because it is the only mechanism by which your specification quality improves over time.
5. Record
Not typed. Derived.
The state of every piece of work comes from ground truth: the branches, the pull requests, the reviews, the merges, the deploys, and the outcome of the criteria from stage 4. Nobody moves a card. The card reflects what is true because it is computed from the only artefact in the system that cannot drift.
The tracker does not go away. It stops being a system of record and becomes a system of intent plus a view of the derived state, which is a job it can actually do. This is the split that makes the whole arrangement work with the tools you already own rather than requiring you to replace them.
This box is also the one that most directly describes what GroundTruth does: read ground truth from GitHub, GitLab or Bitbucket, link every pull request to its ticket, gate done on the criteria rather than on the merge, and write the derived state back into Jira, Linear, Azure DevOps or Asana so that everyone downstream sees something true without anyone transcribing it.
6. Proof
The stage with no ancestor in the SDLC, and the one teams are most tempted to defer.
Once software is moving your tickets, gating your merges and taking actions on your behalf, there is an obvious question: what happens when it is wrong? If the honest answer is “we would find out eventually, from a person noticing,” then you have replaced a slow honest system with a fast opaque one, and that is a downgrade even though every individual metric improved.
Proof means three properties, together.
Attributable. Every automated action records what changed, what triggered it, which rule or criterion applied, and what the evidence was. “The ticket moved to done because criteria 1 through 4 evaluated true against commit abc123, at this time.”
Inspectable. A human can go and look at that, in a form that makes sense, without a support ticket or a database query.
Reversible. A human who disagrees can undo it, and the undo is itself recorded rather than being a silent overwrite that hides the disagreement.
I have put this last in the diagram because it is stage six. In implementation order it should be much earlier, arguably first, because it is the property that makes everything upstream of it safe to trust. Retrofitting an audit chain onto a system that has been running without one gives you proof from today forward and nothing about the period you actually want to ask questions about.
Loop B: outcome feeds intent
The outer loop, and the one everybody draws and nobody closes.
What actually happened after the change shipped: did the metric move, did support volume drop, did anyone use it. That feeds the next intent.
I am not going to pretend this is solved by anything in this series. It is the same loop every methodology has promised and it fails for the same reasons it always has, which are organisational rather than technical. What does change slightly is that the record is now accurate enough for the loop to have real inputs. You know what shipped and when, precisely, rather than approximately. That is a necessary condition for learning from outcomes and it is nowhere near sufficient.
Where this breaks down
The diagram is tidy. Reality is not, and here are the specific ways the tidiness lies.
It shows no queues. Every arrow in that picture is a place where work waits, and in most organisations the waiting dominates the doing by a large multiple. A diagram that shows six stages and no queue depths will lead you to optimise stages. Go and measure where work actually sits before believing anything in the picture.
Stage 2 is drawn as a box and is really a culture change. Writing checkable criteria requires the person authoring tickets to think harder, and that person often does not report to engineering and does not feel the downstream cost. Every failure of this model I am aware of failed at that boundary, not at any technical one. The box is small and the work is enormous.
Loop A can become a treadmill. I have argued for routing failures back to specification. Done badly, that produces endless refinement of criteria for a change that should have been made by a person in an hour. There is a point at which the correct move is for someone experienced to open an editor and write the thing, and any process that has no exit for that will grind on work it is unsuited to.
Not all work fits this shape at all. Research, spikes, incident response, exploratory design, performance investigation. Anything where the goal is to learn rather than to deliver has no meaningful stage 2, because if you could specify the outcome you would not need to do the work. Forcing those through this life cycle produces theatre: a fabricated set of criteria written after the fact to satisfy a gate. Have a documented bypass, use it deliberately, and watch how often it gets used, because heavy use of the bypass is a signal that the model does not fit your work rather than that your people are being difficult.
And the diagram implies sequence where there is overlap. In practice specification continues during execution, verification starts before the change is finished, and the record updates continuously rather than at a checkpoint. The stages are better understood as concerns that must all be satisfied than as steps you pass through in order. I have drawn them in a line because a line is legible, and legibility here costs some accuracy.
The takeaway
Six stages: intent, specification, execution, verification, record, proof. Two loops: failures return to specification rather than to execution, and outcomes feed the next intent.
Four of those six are things you already have. The genuinely new requirements are specification as a checkable interface rather than a prose description, a record derived from ground truth rather than maintained by hand, and a proof chain that makes every automated action attributable, inspectable and reversible. Everything else is your existing life cycle with the constraint moved and the attention reallocated.
That closes the Foundations series. From here the library goes deeper on each part: what happens to your DORA metrics when an agent is opening the pull requests, how to write a definition of done that a machine can evaluate without turning your backlog into a specification language, and the specific failure modes teams hit in the first six months of the transition.