Why this matters

You cannot diff against a reference you never located. The failure mode is not disagreeing with the canon — it is never meeting it, then discovering afterward that the pattern you improvised has a name, a published shape, and a documented list of parts.

In the companion case, the planner was an instance of a named pattern: fan out work across items, then reconcile the results. The published version of that pattern includes the reconciliation step. The build had the fan-out and no reconciler, and nobody knew there was a second half to skip.

The structure

Write one sentence describing what your system does mechanically, with no product language in it. Not “helps staff update copy” — instead “code retrieves candidate text, a model proposes replacements, code decides which land.”

Then find the published guidance for that shape. It exists more often than not:

• Code orchestrates the model through fixed paths, versus the model choosing its own tools — that axis is workflows versus agents, and the pattern catalogue that goes with it names routing, sectioning, evaluator, and orchestrator.
• Retrieve in code, generate once against what was retrieved — RAG, with two decades of published failure modes.
• Work that outlives one request — durable execution, with an entire vocabulary of queues, ticks, and resumability.
• Deciding who holds the turn and when the system may take one — mixed-initiative interaction, which is older than any of this.

Your turn

Produce two artifacts: the mechanical sentence, and a link to the reference guidance for its class.

Why this matters

A review that asks “is everything written here true?” cannot fail on an absence. In the companion case the adversarial fact-check fired correctly every single time it ran — and no claim asserted an answer for long-running work, so nothing could fail on its missing.

The diff is what converts an omission into a visible decision. You are not required to adopt anything. You are required to have answered.

The structure

Take the reference guidance from Exercise 1 and walk its elements one at a time. For each, write one line: adopted, with a number, or rejected, with a reason. Silence is not an allowed answer.

For an agent-shaped system the list is six:

retrieval-scoped generation   what the model sees is chosen by code, not the model
per-request model-call budget a number, in the spec
wall-clock deadline           a number, under the shortest timeout upstream
async for over-cycle work     anything that can outlive a request leaves it
idempotent mutations          survives being submitted twice
observability per model call  count, latency, cost — recorded, not assumed

Your class will have a different list. The format is what transfers.

ELEMENT:  per-request model-call budget
STATUS:   adopted
VALUE:    40 calls, 40s deadline
BECAUSE:  a request touching a dozen pages made hundreds of calls in one
          page load and hung the browser

ELEMENT:  async for over-cycle work
STATUS:   rejected
BECAUSE:  v1 scope is a single page of edits; revisit when cross-page
          planning lands

Your turn

Run every element. Count how many you could not answer without going and looking something up. That count is the size of the gap between what you specified and what your system’s class expects.

Why this matters

This is the backward-facing half, and it answers the question everyone now has about code an agent wrote: how do I know any of this is good?

Not by reading it. Reading rewards code that looks confident. In the companion case the test suite sat at over a thousand green assertions while both defects were live, because the suite never made an HTTP request and could not see a redirect, a resubmit, or a wall clock.

What predicted quality was where each layer came from. The layers built in response to something measured — a serialization round-trip that corrupted 13 of 39 pages — held under deliberate abuse. The layer built from an assumption about how planning should work is where all seven problems lived. Same author, same process, different pedigree.

The structure

List your system’s layers. For each one, name the specific failure it was built in response to. Be concrete: a bug, an incident, a measurement, a corrupted record. “Best practice” is not a pedigree. “Seemed right” is not a pedigree.

LAYER:     write path (byte-offset splice, content hash)
PEDIGREE:  measured — round-trip serialization corrupted 13 of 39 pages
VERDICT:   keep

LAYER:     planning (per-item model calls, request-lifetime execution)
PEDIGREE:  assumption — nobody derived this from a job anyone observed
VERDICT:   suspect; test first, expect to replace

Your turn

Sort your layers into traceable and untraceable. Then spend your testing time on the untraceable ones — that is where the defects concentrate, and it is a far better targeting signal than intuition about which code looks weakest.

Why this matters

A written rule loses to an editor who believes they already checked. The diff you just ran was a rule, and rules decay — you will run this one carefully today and skip it in four months on a Friday.

The only durable version is a check that fails a build.

The structure

Pick the single element from Exercise 2 you were most surprised to find missing. Write the smallest gate that would have caught it.

The gates are usually unglamorous, and that is the point:

• A test that submits the same mutation twice and asserts the second is a no-op, not an error.
• A counter on model calls per request that throws above a threshold, so exceeding it is a failure rather than a slow afternoon.
• A required field in your spec template for each element on the class list, so an empty one blocks the merge.

Your turn

Land one gate. One is enough — a gate that exists beats four you described.