Home The record The technology The method Send me your process

The technology

From a process you describe to a process that is proven.

The home page shows what it does. This page is how it holds — the checks and the machinery, in the order they fire. Ten stages: the first four at authoring, once; the rest on every run.

Before it runs

Everything is settled before anything is written

The interview pins down the terms, the definition of done, and the evidence a finished run must leave — the home page shows one. Then the company’s policy is loaded in ahead of the first word, and each new rule is checked against the ones already there, so a contradiction surfaces at authoring rather than in the middle of a run months later.

One detail the home page skips: most automation fails on the thing nobody thought to say out loud — which is why the interview refuses to move on until it has everything a stranger wouldn’t know.

Anything that never changes is settled while the process is written, not on every run

If a step would look up the same answer every time it ran — a fixed rule, a stable reference, a format that hasn't moved in years — that answer is settled during authoring, shown to you for approval, and written into the process directly. The step disappears.

A run should never pay to rediscover something already known.

The plan is written, and then it is proven

An AI writes the process as a structure of typed steps. Before it is allowed to run, a compiler checks it: is every value assigned on every path, is every branch of every decision covered, does anything get produced that nothing uses, does every check actually look at the thing it is checking.

If it doesn't hold, the AI is told exactly which step and which line, in the vocabulary of the process rather than of a compiler, and it fixes it and tries again.

You also get the process as a diagram. An operations manager who has never seen this system can read it and tell you whether it is right — before it touches anything.

What each step can see is fixed in the plan, not decided mid-run

Steps do not share a conversation, a scratchpad, or any memory of each other. Each one receives exactly the named values the plan routed to it, and hands back a result in a declared shape that is checked before anything downstream is allowed to see it. Nothing travels between steps that the plan didn't route.

Text arriving from outside — an email, a customer's message, a document someone uploaded — lands in a named slot, as data, in the one step that asked for it. Whatever it tries to say, it cannot enlarge its own reach: it cannot make that step do something the plan didn't give it to do, it cannot change which branch the process takes, and it cannot travel to a later step that was never wired to receive it. Prompt injection isn't eliminated here — it is contained. The blast radius of a poisoned input is the one step that read it.

The same compartmentalisation is why information doesn't leak sideways between steps. A step that was never given a value cannot disclose it — not because it was told not to, but because it never had it.

Under the hood

How a plan earns the right to run.

This is the maintenance plan from the home page, replayed exactly as it was authored. The AI writes the plan in a formal language; the compiler refuses every draft it cannot prove; the AI fixes what was refused and submits again — until nothing is left to refuse.

The authoring loop draft 3 · verified
work # 1 · triage
do @reasoning=high
: Read what the tenant reported. Classify the trade and the urgency.
end work → TRIAGE : Triage
 
work # 2 · vendor
do @reasoning=high
: Choose a vendor for $(TRIAGE.trade) from the approved list.
verify → ( 'pass' | 'fail' )
? $($$.name) is licensed for $(TRIAGE.trade) and has no open disputes.
end work → VENDOR : Vendor
 
decide # 3 · the limit
evaluate
? Is $(VENDOR.estimate) over the owner's approval limit?
end decide → LIMIT : ( 'over' | 'within' )
 
switch $(LIMIT) # 4 · approval
when 'over'
interact with owner
: Ask the owner to approve $(VENDOR.estimate). Wait for the answer.
end interact → APPROVAL
when 'within'
work do
: Record the standing approval — $(VENDOR.estimate) is within the limit.
end work → APPROVAL
end switch → APPROVAL : Approval
 
interact with tenant, vendor # 5 · the slot
: Converge on an access window that suits both.
end interact → SLOT : Slot
 
work # 6 · the work order
do
: Raise the work order — $(VENDOR.name), $(SLOT), the access note.
end work
 
notify tenant # 7 · tell the tenant
: Expect $(VENDOR.name), $(SLOT). Include the access note.
end notify
 
interact with tenant # 8 · confirm
: After the window: is the repair done?
end interact → CONFIRMED : Confirmation
 
work # 9 · report
do
: Report the cost and the outcome to the owner — include $(CONFIRMED) and the photographs.
end work
VERIFIED · draft 3 · 9 steps · every value assigned on every path

The diagnostics are written for the AI, not for you — it reads them, fixes what it got wrong, and submits again. A person is consulted only when a fix turns on something the AI cannot know: which of two readings of a rule you actually meant. What matters is that every draft that could not be proven was refused, automatically, before anything ran.

Every time it runs

Each step runs on its own agent, at its own depth

A step that needs judgment gets the most capable model. A step doing something mechanical gets a fast one. That choice is made per step when the process is written, not per run and not for the whole job — so you are not paying for deep reasoning to confirm a postcode.

Every step that acts is judged before its result is used

A separate evaluator — its own agent, with its own instructions — looks at what the step produced or did, and returns a verdict with a reason. Until it passes, the result goes nowhere.

The evaluator judges the task, never the tooling. It has no access to what other steps said or did, so it cannot be talked into a pass by the thing it is checking.

Data is collected from more than one place, and checked against what you asked for

Where a step gathers information, it tries genuinely different sources in order, merges what it finds without duplicates, and stops when a separate check confirms the result actually answers the question. If every source comes up empty, the run stops and says so in the words the plan carries for exactly that case — it does not invent a plausible answer.

It talks to people, and waits

A step can open a conversation with a specific person and hold there for hours or weeks, then carry on where it stopped. Another can run rounds with several people at once until they converge on something, letting those who may opt out do so.

Each person sees only their own conversations, in one place, across every process that is waiting on them.

It survives being interrupted

Progress is committed step by step. A restart, a dropped connection, a deployment mid-run: the process resumes at the last completed step rather than starting over or, worse, silently repeating something that had already happened.

It writes down everything, including what it cost

Every prompt with the values that went into it, every result under the name it was published as, every verdict and the reasoning behind it, every message to a person, and the cost — to a fraction of a cent, per run.

See a complete record →

What it deliberately does not do

Each of these is a deliberate boundary. None is a gap waiting for a later version.

It doesn't decide what it wasn't told to decide
The process is fixed and readable before it runs. It does not improvise a new step because a run went sideways — it stops, in the words the plan carries for exactly that case.
It doesn't hide a failure
A stop that was designed for is reported in plain language. A stop that wasn't is reported as a failure with the technical detail kept for whoever has to fix it — never dressed up as a result.
It doesn't practise anyone's profession
In regulated work it collects, tracks, reminds, escalates to a human and reports status. It does not advise, decide a case, or file anything. That boundary is written into the process as a standing decision, so it is visible in the diagram and checked like anything else.
It isn't a chatbot with tools
Nothing here depends on a model choosing well in the moment. The structure is fixed and proven first; the models fill in the parts that genuinely need judgment, and each one is checked.

File handling

Processes that work on documents run against a versioned workspace: every run gets its own, changes are committed step by step, and any earlier state can be restored. This is built and is being wired into the document-heavy processes now.