Every consultancy has a slide about its way of working, and most of them say nothing. Mine is a single file, copied into every project I build, and it settles one question before anybody writes a line of code. Here is the rule, four systems that run on it at wildly different scales, and an honest account of what it costs.
In short
- The rule is not about accuracy. It is about which component in a system is allowed to create a fact that cannot be taken back.
- It holds at four very different scales: filing a receipt, writing a job application, placing a trade, and running a company of agents.
- In each one the model reads, weighs and drafts. Ordinary code enforces the limit, and a human confirms the handful of actions that produce facts.
- The doctrine is not a habit or a preference. It is a file that ships with every project and briefs the agent before it does anything.
- It is not free. It costs duplication, latency, and a permanent temptation to hand the model a little more authority every time you watch it be right.
If you open almost any project folder I have built in the last couple of years, there is a file at the top called `CLAUDE.md`. It is the first thing the AI reads when it starts work, and it is about seventy lines long. It is not documentation. It is a brief.
Roughly the same seventy lines appear in a personal trading system, an expense-filing tool, a job application builder, and a framework for running autonomous digital companies. Those four systems have almost nothing in common. One of them files receipts. One of them risks real money. One of them writes cover letters. One of them operates a hierarchy of AI agents with a budget.
They share one rule, and the rule is not the obvious one.
The rule
The obvious version of this rule, the one that gets repeated at conferences, is "keep a human in the loop". It sounds responsible and it means almost nothing, because it does not say where the human goes, and putting them in the wrong place is worse than leaving them out. A human asked to confirm every step becomes a person clicking Next, which is not oversight, it is theatre with an audit trail.
The version I actually build to is narrower and much easier to apply:
Anything that creates a fact must be deterministic. Anything that forms a judgement can be probabilistic.
A fact, here, means a change in the world that cannot be quietly undone. Money moves. A message is sent. A file is published. An order is placed. A record is written that somebody else will now rely on.
A judgement means everything else. Reading, extracting, weighing, ranking, summarising, drafting, objecting, explaining. All the work where being wrong produces a bad suggestion rather than a bad outcome.
The reason this is worth stating as a rule rather than a preference is that it survives contact with wildly different problems. Here it is at four scales.
Scale one: a receipt
The smallest of the four is an expense tool. You drag a photo of a receipt onto a window, and it ends up in Xero.
The model does the genuinely hard part. It reads a crumpled photograph and extracts the vendor, date, total, currency and a suggested category, and it returns a confidence rating on its own work. That is a real capability and nothing deterministic would do it better.
Then the rule takes over. The extracted fields land in a review panel, where low-confidence extractions are flagged for a second look. When the fields are right, the tool creates the bill in Xero as a draft. It attaches the original image. And it stops.
It does not approve the bill. It does not pay it. Approving happens later, by a human, inside Xero itself. The model that read the receipt has no route to the action that moves money, and the account it authenticates with is scoped so it could not take it anyway.
That last detail matters more than the policy. A rule the code cannot break is worth ten rules that everyone agrees to follow.
Scale two: a job application
The second system tailors a CV and cover letter to a specific job advert. It is the one where the model does the most creative work, and the constraints are correspondingly heavier.
The brief for it runs to forty-one numbered rules. Rule one is the only one that would matter if the rest vanished: never fabricate. Do not invent experience, skills, qualifications, dates or achievements. Rephrase and re-emphasise what the person genuinely has, and nothing else.
That is not a stylistic note. In a system whose entire job is to make somebody look as good as the evidence allows, the failure mode is not a clumsy sentence, it is a plausible invention that gets discovered in an interview. The model is very capable of producing one, so the boundary is drawn explicitly, at the top, before anything else is said.
The rest of the rules do the same work in smaller ways. Two pages maximum, verified by opening the rendered file and checking pagination rather than trusting an estimate. Contact details in the body of the document, not in the header, because screening systems strip headers. Fixed output filenames. Source documents never modified, only copied. A fit assessment produced for every application, in one of four defined levels, so the judgement is recorded rather than implied.
The pattern is the same as the receipt, dressed differently. The model writes. The rules constrain what it is allowed to write. Deterministic scripts render the final documents. Nothing is submitted to an employer by the system at all, ever, because sending is the step that creates a fact.
The interesting constraint is rarely "be accurate". It is "here is the specific way you are able to fail, and here is the thing standing in the way of it".
Scale three: a trade
The third system trades. It reads research, evaluates strategies, and places orders against a broker.
I have written about this one at length elsewhere, so the short version will do. A deterministic strategy raises a candidate trade. The model is given the research and the macro calendar, and asked one narrow question: should this be vetoed? It can say no, and it can lower a confidence score. It cannot place a trade, size one, or raise a limit.
Everything that grants permission is ordinary code reading ordinary numbers. A daily loss ceiling. A cap on position size. A count of open positions. On the live account, a human approval queue that expires and rejects by default.
Same rule again. Judgement to the model, permission to the code, and the human on the edge where the fact gets created.
Scale four: a company
The fourth is the one that sounds like it should break the pattern, because the whole point of it is autonomy.
It is a framework for running digital companies: hierarchies of AI agent roles, a chief executive at the top, a few layers of managers and workers below, operating against goals with real budgets and producing real deliverables. The agents hold meetings, with an agenda, a chair, a turn limit and minutes. They spend money on their own API calls. They can recruit new roles.
If ever a system were going to abandon the rule in favour of pure autonomy, it would be this one. Instead the rule scales up and turns into governance.
There is an explicit autonomy line, written into the founding decisions. Four things require a human: a new goal and its budget, recruitment of new roles, a budget top-up, and anything leaving the system. Everything inside a funded goal runs autonomously against that budget.
Underneath it, the same deterministic machinery as everywhere else. A hard monthly spending ceiling as a backstop. Per-goal budgets delegated downward, from the chief executive to managers to individual tasks, with every API call metered against the task that owns it. A branch that exhausts its budget escalates upward automatically, and only reaches a human if the whole goal runs dry.
Note what the four human gates have in common. A new goal commits money. Recruitment commits recurring money. A top-up commits more money. Anything leaving the system creates a fact in the outside world. They are not the four most important decisions in the company. They are the four that cannot be taken back.
The agents make thousands of consequential judgements that a human never sees, and that is fine, because a judgement inside a funded goal is recoverable. The budget is the thing that makes it recoverable, and the budget is enforced in code.
What actually recurs
Set the four side by side and the common element is not a technology or an architecture. It is a question, asked early, of every component:
Does this create a fact?
If yes, it is deterministic, with an explicit limit, and where the consequence is severe it also gets a human. If no, it can be probabilistic, and it should use the best model available, because the whole value of the arrangement is that the judgement side can be ambitious.
The test is unglamorous, which is why it works under pressure. It does not require anybody to estimate a model's accuracy, predict how capability will change, or agree on how much they trust AI in the abstract. Those conversations never converge. This one converges in about a minute, because "does this move money" has an answer everybody agrees on.
Why it is a file, not a habit
The part I would most want to transplant into somebody else's practice is not the rule. It is that the rule is written down and shipped.
An operating model that lives in the head of whoever founded the company is not an operating model, it is a personality. It cannot be handed over, it cannot be argued with, and it degrades every time somebody is in a hurry.
Putting it in a file that the AI reads at the start of every session changes its status. It becomes something an agent is briefed on before it does anything, which means the constraint arrives before the work rather than during the review. It can be version controlled. It can be quoted back at me when I am the one trying to cut a corner. When it turns out to be wrong, the fix is an edit in one place rather than a habit that has to be unlearned across four projects.
It also makes the doctrine legible to whoever comes next, which for a small consultancy is not a theoretical concern.
What it costs
I would rather set out the bill than pretend there is not one.
Duplication, and quite a lot of it. The CV system has a separate build script per application, roughly twenty companies with four scripts each. They are nearly identical. A more elegant system would have one parameterised script and a configuration file. The reason it does not is that each script is a permanent, readable record of exactly what was produced for that application, which matters when somebody asks in an interview why a line was phrased a particular way. That is a real trade, and on a different project I would probably trade it the other way.
Latency. Every judgement step is a model call, and model calls are slow compared to the code around them. In the trading system this is genuinely a cost, because a signal waits on a round trip before it can proceed.
Rigidity where the model is right. The deterministic gates sometimes block things the model had sensibly approved, because a threshold cannot see context and a model can. Each of those is a small, visible waste, and they accumulate into a persuasive argument for loosening the gate.
The standing temptation. This is the real one. Every time you watch the model reason correctly about a situation your hard-coded rule handles crudely, you build a little more of the case for giving it authority. The pressure is constant and it always feels like an improvement rather than a compromise.
The answer is not that the model cannot be trusted. It is that the value was never in any individual judgement being correct. It is in the shape of the arrangement, which stays safe on the day the model is wrong, or slow, or unavailable, or quietly returns something plausible and incorrect. Give that shape up in exchange for a series of good days and you have traded a property for an average.
One question, asked early
Adoption programmes stall in a predictable way. They begin with an argument about whether AI is good enough, which cannot be settled, and they end with either a pilot nobody scales or a rollout nobody trusts.
The way past it is to stop asking how much you trust the model, and start asking what each part of the system is allowed to do when it is wrong. That question has answers. It produces an architecture instead of a percentage, it survives the model changing underneath you, and it works the same way whether the thing at stake is a receipt for a coffee or a company with a budget.
Write the answer down. Put it where the work starts, not where the work gets reviewed. Then let the model be as clever as you can afford on one side of the line, and keep the other side boring enough that anybody can read it in a single sitting and tell you exactly what it will do.
DCCO is an independent technology consultancy working across the UK and Europe. Founded in 2009, it covers AI adoption, rapid software development, and vendor-neutral advice on digital signage, DOOH, and IT and AV transformation.