Confirmation Closes the Circle

Validation, in part 7, ended the cycle's technical story: every requirement traced to a receipt, every gap listed with a severity, a go/no-go decision on the table. What usually happens next is nothing. The code ships, the ticket closes, the next piece of work starts, and everything the cycle just taught you — which requirements the agent kept missing, which work packages needed four loops, what the release now quietly forbids — evaporates. Confirmation is the phase that catches that knowledge before it goes, and it is the phase I see skipped most often, because its outputs never look like progress.

The phase only the big jobs earn

Confirmation is the C in PREVC, and it is the one phase reserved for the LARGE routing — full products, major features. That is deliberate. A bug fix does not need a retrospective and a constraints document; the scale routing exists precisely so the ceremony lands where it pays, and nowhere else.

When it does run, Confirmation is two distinct sub-steps: a process retrospective, which looks backwards at how the cycle behaved, and a release step, which looks forwards at what the shipped code now imposes on everything that follows. Both are necessary for the workflow to be circular rather than linear — drop either one and PREVC degrades into a pipeline with a nicer name.

A retrospective with named suspects

The retrospective I run is not the free-form “what went well, what went badly” session. It interrogates each phase of the cycle with questions that phase must answer:

The Validation row is the one that pays rent. A gap is never just a gap; it has a phase of origin, and the classification tells you where next cycle's effort belongs. A requirement that was never captured is a Planning failure — the intake did not surface it. A requirement that was captured but left woolly enough for the agent to misread is a Review failure — refinement should have removed the ambiguity while it was still cheap. A requirement that was clear and still built wrong is an Execution failure — the inner loop's review step let it through. Three failure classes, three entirely different fixes; averaging across them (“we had eight gaps”) tells you nothing worth acting on.

The second half of the retrospective is what separates it from a team ritual: every observation becomes a candidate for encoding into the harness.

• A convention you corrected this cycle and last cycle belongs in a context file, so no future cycle corrects it again.
• A category of requirement the agent always misses belongs in a planning checklist that rides along at intake.
• A pattern of over-engineering that keeps recurring belongs in a constraint document the agent reads before it writes a line.
• A breakout constraint that was consistently too loose or too tight gets recalibrated in whatever template sets it.

A retrospective observation that does not change an artefact is a mood, not an improvement. Agents do not absorb team norms by osmosis. The only retrospective output a future agent will ever see is the one you write into the files it reads.

Old roots, credited properly

None of this is new under the sun, and the credits are worth getting right.

The obvious ancestor is the Sprint Retrospective from Schwaber and Sutherland's Scrum Guide — the event where the team inspects how the sprint went and identifies the most helpful improvements to its effectiveness. Kaizen, the Japanese continuous-improvement philosophy, contributes the compounding argument: small, systematic adjustments made every cycle beat occasional dramatic overhauls. PMI's post-implementation review contributes the discipline of asking, after delivery, whether the work achieved its objectives and what the lessons were — PREVC simply asks it per cycle rather than per project, which makes the learning loop weeks shorter.

And then there is PDCA, which deserves its own paragraph because it is so routinely mis-credited to a single name and a single decade. The Plan-Do-Check-Act cycle originated with Walter Shewhart at Bell Labs in the 1920s; W. Edwards Deming popularised it in 1950s Japan, and Deming himself came to prefer PDSA — Study rather than Check, on the grounds that checking implies inspection while studying implies learning. Confirmation's retrospective is the Act step of that lineage applied at cycle granularity: standardise what worked, change what did not. The difference in an agent workflow is where the standardising lands — not in team habit, but in machine-readable artefacts.

Release writes two documents

The second sub-step is release, and it is a writing exercise stapled to a deployment. Two documents come out of it.

Limitations answer the question: what does this release not do? Which scenarios are known but deliberately unaddressed? What assumptions does the code make about its environment? These are not confessions of failure — they are conscious scope boundaries, made visible so that whoever builds on this code next, human or agent, does not have to rediscover them by breaking things.

Imposed constraints answer the harder question: what does this release now forbid? I document four categories:

• New dependencies — libraries, services or APIs that future work must now account for.
• API contracts — interfaces that downstream consumers depend on and that can no longer change without coordination.
• Performance baselines — response times, memory ceilings, throughput numbers that someone will notice regressing.
• Architectural decisions — schema shapes, module boundaries, communication patterns that are now load-bearing and expensive to move.

Suppose the cycle just shipped Relayline, an invented webhook dispatcher. Its limitations might read: retries are capped at five attempts with fixed backoff; delivery order is not guaranteed across endpoints; the service assumes a single region. Its imposed constraints: consumers now depend on the shape of the delivery-receipt payload; dispatch latency has a p95 the dashboard watches; the outbox table is now the integration point that three other services read. None of that appears in a code review. All of it is exactly what the next cycle's agent needs to know and cannot infer.

That last clause is the whole argument. In traditional development, imposed constraints live in developers' heads and travel as tribal knowledge. An agent has no tribal knowledge. Every constraint you do not write down is a constraint the next agent will violate — not out of carelessness, but because, from inside its context window, the constraint does not exist. Confirmation is the point in the workflow where process discipline and context discipline turn out to be the same discipline: each release updates the persistent information environment that future agents operate within, and skipping the update guarantees drift.

The circle, closed

Now the shape of the whole thing becomes visible. The retrospective's observations become harness improvements. The release's limitations become the next cycle's requirements — a known-but-unaddressed scenario is just a requirement with a delay on it. The release's imposed constraints become the next cycle's context, fed into Planning's intake alongside everything else the agent must know. Confirmation's output is Planning's input. PREVC is not a pipeline with a start and an end; it is a circle.

The design intent is that the circle accelerates: each pass improves the harness, the checklists and the templates, so each subsequent Planning starts richer and each Review has less to fix. I will be honest that “design intent” is doing some work in that sentence — how much acceleration I can actually evidence is a question I owe you, and it gets a straight answer in the final part of this series.

Before the ledger, though, the comparison the whole series has been implying. Next, PREVC against the methodologies — where the circle sits against PDCA, Scrum, waterfall, spec-driven development and the V-Model.