Running the loop

In a demonstration every call returns. In production some do not. The payments system takes forty seconds instead of four, the connection drops, and the software is left with a question it cannot answer from its own side: did the payment go out or not. A timeout is not a failure. It is the absence of information. Software that treats it as a failure and simply tries again will, on a bad day, pay a supplier twice, send a customer two letters or raise two credit notes against one invoice, each of them correct on its own.

The defence is to make every action that changes state safe to repeat; engineers call such an action idempotent. The usual mechanism is a key built from the case and the step — this claim, this payment instruction — sent with the request, so the receiving system recognises a second attempt and returns the result of the first instead of acting again. Where the target system cannot do that, the software must do it itself. Before retrying, it reads the state, looking for the payment with that reference or the letter logged against that case, and retries only once it has confirmed the first attempt did not land.

Not every error deserves a second attempt. A system that was busy, a record held open by a colleague, a connection that dropped: these are transient, and trying again a little later is reasonable. A failed validation, a refused authorisation or a supplier that does not exist will fail the same way every time, and retrying them only fills the log and delays the person who has to act. Separate the two kinds in the design, cap the number of attempts, wait longer between each one, and when the cap is reached, stop and hand the case over with a note of what was tried.

Partial failure is harder. A change of supplier bank details needs the new details written, the approval recorded and the supplier notified. If the software stops after the first step, a live record holds new bank details with no approval against them. Record each step as it completes, against the case, so that a restart resumes after the last confirmed step instead of repeating the ones that landed. For steps that must not be left half-done, decide in advance whether a stopped case is completed or undone, and write the undo down as a procedure someone could follow.

None of this shows in a demonstration, because a demonstration runs once on a quiet system. Ask to see three things: the target system running slowly, a timeout that arrives after the action has in fact landed, and the process being stopped between its second and third steps. The right answer is a record of each step and no duplicate. If the answer is that it has not happened yet, it will at production volume, and the first instance will be found by a supplier or a customer rather than by you.

Every agent will meet cases it should not decide. The question is whether it knows. Software designed around the path that works will, when an input does not fit, do what software does with input that does not fit: take the nearest match and carry on. A remittance advice that pays three invoices in full and part of a fourth gets matched to the three, and the balance is written off as a small difference within tolerance. Nothing failed, so nothing was flagged. That is the most expensive kind of error, because it looks exactly like success.

So the stop conditions come first, written as a list a process owner can read and argue with. A typical list: a check on the outcome does not pass; two pieces of evidence conflict; the case falls outside the written rules; the amount or the consequence is above the agreed threshold; the next action is irreversible or customer-facing and the rules do not decide it; retries are exhausted; the case has taken more steps than a case of its kind should. Each condition is tested against past cases where it applied, like any other behaviour.

One pattern needs a specific warning. When the software is unsure, it is tempting to ask the model again, or to ask it differently, until an answer passes. Asking again produces another sample, not new evidence. If two attempts at the same question disagree, the disagreement is the finding: the case is ambiguous, and ambiguity is what a person is kept in the process to decide. Treat disagreement between attempts as a stop condition, never as a vote to be won by asking more times. Voting also hides the problem from the record, which then shows one confident answer instead of several that disagreed.

How it stops matters as much as when. The case is left in a known state with no half-done action: complete up to a named step, or rolled back to where it began, and the record says which. The hand-over carries what was read, what was tried, which condition triggered the stop and what decision is needed from the person. It goes to a named queue with an owner and a time to respond, not to a shared inbox where it ages quietly until the supplier telephones.

Then watch the rate. The share of cases that stop is one of the most useful figures you have. If it falls towards zero on a process you know to be messy, and nothing about the input has changed, the software is more likely guessing than improving. If it climbs, a rule has changed, an input format has shifted or a system upstream is failing. Either movement is a reason to look at cases, and neither is noticed unless a named person owns the number and reads it every week.

The review queue is where the person you kept in the process does their job, and it is usually designed last, by whoever built the software, in an afternoon. The result is a list of cases with a status and a button marked approve. The reviewer opens each case, reconstructs what the software did from a log written for engineers, finds the invoice in one system and the purchase order in another, and decides. That is slow and tiring, and after a few weeks of it the review becomes a signature.

Design each item around one decision. Not 'review this case', but a question with a small set of answers: does the remittance reference match invoice 4471 although the amount differs by a bank charge — accept the match, reject it, or send it back for information. If a case needs two decisions it becomes two items, because a combined decision cannot be recorded, counted or checked cleanly, and an approval of the whole hides which parts were actually looked at. The answers offered must cover the answers reviewers really give, including the awkward third one.

Put the evidence on the screen: the clause the software relied on, the record it matched, the figure it could not reconcile, and the source document itself rather than the software's summary of it, because the summary is the thing under review. Order matters too. If the proposed answer is the first thing the reviewer sees, the job quietly becomes checking that it looks plausible. Show the question and the evidence first and the software's proposal after, marked as a proposal. If the reviewer has to leave the screen to find a fact, the item is not ready for the queue.

Record the answer in a form you can reuse. A choice from a fixed list and a short reason code — amount outside tolerance, reference belongs to another supplier, not covered by the rules — can be counted, compared between reviewers and turned into test cases. Free text on its own cannot. Record, too, what the reviewer was shown, because the screen will change and a decision only makes sense against the evidence it was made on. An auditor asking about a decision taken in March needs March's screen, not today's.

Finally, size the queue to the people who work it. Decide how many items a reviewer can decide properly in a day, and treat a queue that exceeds it as a fault in the design rather than a staffing detail. Order items by consequence and by age, not by arrival. Give every item a time by which it must be decided, and say what happens when that time passes: it goes to a named person. It does not wait indefinitely, and it is never approved by default.

The review queue shows you the cases the software doubted. It tells you nothing about the cases it got wrong while certain. Those pass straight through, commit, and surface later, if at all, as a supplier dispute, a complaint or an audit finding. A process in which a person only ever sees the escalated cases has no measurement of its most important error, the confident one, and a sponsor who reports an error rate from the queue alone is reporting on the easy half.

The remedy is a sample. Each week, draw a set of completed cases at random and send them through the same review screen as escalations, with the same one-decision design. The software makes the selection, not the team, because people choosing cases to check choose the interesting ones. Do not mark the items as samples: an item labelled as unlikely to be wrong gets a lighter look. Add a separate stratum for the cases that matter most — the highest values, a new counterparty, the first weeks after a rule change — and check more of those.

Size the sample to what you need to know, not to what feels diligent. A modest random sample decided properly every week tells you more than a large one skimmed once a quarter. Raise it for a period whenever something changes: a new model, a new supplier layout, an amended policy, new instructions. Lower it only when the measured rate has been stable long enough that you would defend the figure to an auditor, and raise it again the next time anything moves. The aim is a figure you can trust, not one that merely reassures.

Every error found, in the sample or in the queue, becomes a new case in the set with known-correct outcomes from Module 01, its correct end state written as a check that runs without a person. The set then grows from production rather than from what the builders imagined. The discipline that matters is simple to state: no fix goes live until the case that prompted it is in the set and the whole set has been run again. Fixing one case by editing the instructions is how three others quietly break.

Watch the reviewers as well. Each week, give a small number of items to two reviewers independently and compare their answers. When they decide the same item differently, look first at the rule, not the people, and read the disagreements with the process owner. Some will be carelessness. The rest point to a rule that was never written precisely enough, and each one settled in writing becomes a rule the software can follow and a case with an outcome everyone has agreed.

A person working a queue has natural limits. They tire, they notice when something looks odd, and they cannot send four thousand letters before lunch. Software has none of these limits unless you give them to it, and it does not stop at the end of the day. A misread rule applied at machine speed does more damage in an hour than a careless clerk manages in a month. So the first control for anything left running is a set of caps it cannot exceed, whatever it decides.

Caps come in a few kinds. A rate: so many actions a minute, and no more than one message to the same customer in a day. A value: no payment above the agreed threshold without a person. A step budget: a case that has taken more steps than any case of its type should is stuck, and stops. A spend cap on the model and the systems it calls, per case and per day. All of them are enforced in the code that performs the action, not in the instructions given to the model, because instructions are advice and code is a limit.

The off switch is a single control, held by named people, that stops the software taking any new action and leaves every case in flight in a known, recorded state. It needs narrower versions too: stop sending but keep reading, stop one action type, stop one counterparty. A switch nobody has pressed is a hope. Test it on a schedule, as you would a fire drill, and time how long it takes from the decision to stop to the last action landing.

Stopping is half of it; undoing is the other half. Module 01 asked for a written reversal for each action. Running unattended adds a harder case, reversal in bulk. If a changed rule was misapplied for three hours before anyone noticed, you need to find every case it touched, see what was done to each and what has happened since, and correct them in order without undoing legitimate work. That is possible only if the record exists, and it is worth rehearsing once, on a copy, before you need it.

So every step leaves a record tied to the case: when it happened; what was read, and which version of the document; which rule applied; what the software proposed; which system it called and what came back; who approved it, if a person did; and which versions of the software, the instructions and the model were running. The record is append-only, kept in the client's own systems and readable without the builder's help. It is how you answer a complaint, an auditor and your own question of what went wrong, and every other control in this module depends on it.