How a request becomes finished work.

The cycle in numbers

• 1way in: every request enters through one role
• 4fields a card must carry before work may start
• 4verdicts a criterion can receive; exactly one lets work through
• 3attempts to fix, then a human takes over
• 2labelled valves around the merge check, both leaving a trace
• 1human gate on the whole cycle: production

One door in

Every development request goes to the product role first. Not to whoever is free, not straight to the agent that would build it. A request that lands anywhere else is redirected before anything is built.

What the door is for: nothing gets built without a story, stated acceptance criteria and a place in the order. The chain after that runs by itself. The product role turns the request into a story under an epic and sets the business priority. The delivery role breaks the story into tasks, estimates them and names an owner. Sprint order is agreed between the technical, product and delivery roles. None of those steps waits for the owner of the company to answer anything.

REQUEST
   |
   v
INTAKE         epic + story, success metric, kill criterion
   |
   v
REFINEMENT     criteria that are checks; numbers re-read at source
   |
   v
BREAKDOWN      tasks, estimates, an owner per task
   |
   v
SPRINT         only complete cards are promoted
   |
   v
EXECUTION      one agent, one worktree, criteria in the brief
   |
   v
ADJUDICATION   per criterion, computed - not narrated
   |          |
   |          +---> failed: back to the queue, with the whole verdict
   v
PRODUCTION     a human clicks. Every time.

The stop list is short and written down, because "ask the owner" is how an autonomous system quietly turns back into a queue in front of one person. Work stops for a kill or a pivot, a new epic, a reordering of work already committed to a sprint, anything irreversible or outward-facing, and a genuine conflict between two business instructions. Everything else moves, with the assumption named on the card in one line.

The default state is movement. Stopping is the exception that needs a reason.

A card that is not finished cannot be started

This one is not a convention people are asked to honour. The transition out of the backlog is refused in code, for every writer alike: a human in the interface, an agent over MCP, a script against the API.

The same check runs when a sprint starts, so an incomplete card stays in the backlog rather than starting a sprint that looks full. That is how the rule was found: a sprint start that promoted zero cards out of five, which reads as a broken tool until you read the list of what each card was missing.

Criteria are the contract, and they are addressable

A criterion has to be a check that returns true or false: a query, a passing test, a command with a defined exit code. A criterion that cannot be written that way is a wish, and a wish does not enter the order.

Criteria live in their own field, and only from there do they get stable identifiers - AC1, AC2, AC3. That identifier travels through the brief the agent reads, the judge's answer, the ledger and the note that comes back. Before identifiers existed, the judge answered in its own prose and nothing compared that prose to the card. A judge that silently skipped one criterion of five produced a verdict indistinguishable from one that graded all five: a missing adjudication looked exactly like the absence of a problem.

Human visual inspection is allowed as a criterion, but as a separate and declared class that holds the card open rather than as something an agent may tick. And a card carrying more than fifty criteria is rejected as a defect of the card, not honoured as a very thorough contract.

One more step before a card is ready: if its justification rests on a number or a claim about the state of the system - a count, a share, the name of a field, "this mechanism does not exist" - that claim is re-read at source at refinement time, and the reading is stamped on the card with its date and the command behind it. Not because cards go stale with age, but because every reading is a snapshot. Two of the five drifts we documented were under a week old.

The verdict is computed, not narrated

When the work comes back, a separate model role grades it against each criterion by identifier. It never grades its own work, and it never returns a single overall opinion.

Acceptance is the conjunction over every criterion, computed in code: all met, coverage exactly one to one, or the work does not pass. Every branch that meets uncertainty blocks. There is no input shape - absent, malformed, duplicated, unrecognised - that widens what gets accepted.

The fourth verdict exists because "I could not check" once came back as "you fabricated this".

The way back is part of the machine

A rejected verdict used to be a row in a ledger nobody read. Now the card moves itself back to the queue with the whole verdict attached, and the loop has a hard end.

• The return note carries everything: every blocking criterion with its text, every flag, every suggestion and the judge's reasoning in full. There is no truncation, because "you failed, work out which part" is not a hand-back.
• Three attempts, then a human - the limit is a setting, clamped between 1 and 10 so that a typo cannot recreate the incident it was introduced to prevent. After the attempts are spent you change the method, not the number of tries.
• Only a finding against the work spends an attempt. A verdict that does not cover the criteria, or one whose blockers are citations the judge could not reach, goes to a human with the executor's budget untouched.
• An acceptance is also a result, so it also writes a note. Until that was fixed, a card the judge had passed and a card it had never looked at were the same row on the board: no note, nothing said.
• Nothing closes itself. An accepted card stays in review, because closing work is the human gate and an automatic "done" answers a question nobody asked.

The board cannot disagree with the repository

A required check refuses to let a pull request merge unless the card it names sits in review with a written self-assessment. The record of the work and the work itself land together, or neither lands.

It was built from a measurement, not a worry: on one day in August four merged changes sat on a board that still showed them as backlog or todo with an empty self-assessment. The work was in the main branch; the record of it was not. Closing that loop depended on an agent remembering, in its last turn, to move a card. A discipline fails quietly, and this makes the bad state unreachable instead of forbidden.

• If the gate cannot reach the system that answers, it fails closed. A gate that opens when it cannot see is a gate plus a way around it, and the way around it is to make the API time out.
• Two valves exist for documentation-only changes and for hotfixes. Both print an audit line, and the label itself records who applied it and when, where it cannot be edited away quietly.
• What happens to the code from there - the hooks, the tests, the queue that retests every pull request against the main branch as it is right now - is a separate sheet: four gates to production.

Make the bad state unreachable. Rules people have to remember are the ones that fail in silence.

What is enforced, and what is still discipline

A page about evidence should hold itself to it, so here is the line between the parts of this cycle that a machine refuses to break and the parts that still depend on someone doing the right thing.

Enforced in code: the four fields before a card may start, the promotion rule when a sprint opens, the per-criterion adjudication and its conjunction, the return path with its counter, and the merge check. Still doctrine: the single door in, the short stop list, and the reconciliation of task states before a story is closed. Each of those three is a candidate for the same treatment, and the order in which they get it is decided by which one fails first.

One known hole, stated plainly. Before the judge sees a dossier, a mechanical pass checks that the cited files, tests and commits exist - no model, no judgement, just existence. It reads the deployed source tree, which is frozen at whatever commit was last deployed, so work merged after that deploy is missing from it. A real commit and an invented one produce the same answer there. We did not fix that by pretending the snapshot is current; we gave the judge a way to say "I had no means to check", which routes the card to a human rather than to an accusation.

What this buys in practice

• Work is taken in, broken down and scheduled without the owner in the loop, and the places where the owner genuinely decides are named rather than discovered.
• Ambiguous work cannot start. The cost of an unclear criterion is paid at refinement, where it is cheap, instead of after a build, where it is not.
• A rejection is specific, addressed and costed: which criterion, whose problem, which attempt of three.
• The board and the repository cannot drift apart, so a status read from the board is a fact rather than a hopeful summary.

Predictable output is a property of the cycle, not of the model running inside it.