/do — inside the factory

One sentence in.
A proven feature out.

Every piece of software you've ever used was built the same way: someone decided what to make, someone made it, someone checked it, and everyone hoped. The hoping is the expensive part.

/do removes the hoping. You type one sentence — the thing you want to be true — and a loop takes it from there: it writes down what it's promising, builds it, proves it, and remembers what it learned. The human owns the sentence. The loop owns everything below it.

  1. signal — "can it do Spanish?" — a customer, in a chat, 11:04
  2. decide — worth making — the first act of intelligence — a signal is not yet work
  3. objective — answers in their language — what should become true
  4. promise — the terms, plus one command — the proof is written now, and it fails now
  5. deliverable — locale detect · translated reply — the tangible things
  6. deliverable — nothing can produce this — the second deliverable has no task under it
  7. task — create the missing work — the factory writes its own next job
  8. task — two tasks, ready — what work can produce it
  9. route — three routes tried — nothing is known yet, so it has to find out
  10. actor — an agent takes it — routed by capability, cost and trust
  11. attempt — three attempts — two were rejected before one held
  12. result — a diff — what the attempt produced
  13. proof — the same command, run again — nobody edited it — that is the whole trick
  14. resolution — accept — the result counts
  15. settle — settle — the promise closes kept
  16. deploy — live — deployed · reachable · measured
  17. record — the factory writes down what happened — asked · promised · built · by whom · which route · what it cost
  18. signal — "can it do German?" — a different customer, three days later
  19. decide — worth making — still a decision — the record does not promote its own ideas
  20. objective — answers in their language — the shape of this ask is already on file
  21. promise — the same proof, reused — red again, because German does not work yet either
  22. deliverable — one deliverable, not two — locale detection was built last time and still stands
  23. task — one task, ready — no gap — the missing work was invented once and kept
  24. route — the proven route — picked instantly — it does not search what it already knows
  25. actor — the agent that won last time — strength went up when it delivered; that is how it is chosen
  26. attempt — one attempt — the two ways that failed last time are not tried again
  27. result — a diff — what the attempt produced
  28. proof — the same command, run again — the bar did not move because the work got easier
  29. resolution — accept — the result counts
  30. deploy — live — deployed · reachable · measured
  31. record — and it writes down this one too — the third signal will be cheaper than the second
One signal entering the factory and one proven change leaving it. Nothing above is complete because something below exists.
Scroll
815 acceptance checks
300 plans written
612 jobs on the record
8 scored dimensions
0.65 the bar
01 The frame

Detroit, 1913

Ford didn't win by hiring faster men

He won because the work moved along a line: each station doing one job the same way every time, nothing advancing until the station before it finished, and a check at the end that wasn't a matter of opinion. Say "software factory" today and most people hear "AI writes the code" — the least interesting part, and the part that's already solved.

A software factory is the system that decides what work exists, what work is possible, who or what should do it, how it is proven, and what is learned from the result.

Writing the code appears nowhere in that sentence. Neither does the word software — a factory that decides what work exists and establishes that it was done isn't committed to one kind of output. Ours produces two: capability, which ships to a server, and campaigns, which ship to a market. Same questions, same record, same gates.

What most teams run instead is a workshop: a skilled person, a bench, good tools. Quality tracks whoever's at the bench and how their week is going. Every AI coding assistant on the market is a workshop with a much faster bench — which is not a criticism, ours writes most of our code, but a faster bench doesn't answer any of those five questions, and those questions are where software actually goes wrong.

Five layers · only one of them contains agents

THE WORLD
It sends the raw material
users · customers · developers · systems · markets
THE RECORD
One living graph
actors · things · paths · signals · events · learning
THE PRODUCTION SYSTEM
It moves goals toward verified outcomes
aim · promise · design · plan · build · prove
THE WORKFORCE
Agents and people
routed by capability, cost, trust and history
PROVEN OUTPUT
Software and campaigns
deployed · reachable · tested · measured · learned from

Most companies already own the raw material. They have the tickets, the docs, the code, the tests, the deploys, the analytics. What they don't have is the machine — because those things sit in eight systems that don't know about each other. The tickets can't see the deploys. The tests can't see the goal. Nothing in that pile can answer what should exist and doesn't.

The shape of the difference

Where an ordinary AI system stops

Every AI tool you've used has the same shape. It's a good shape. It's just very short — it ends the moment the text arrives, which is roughly where the interesting problems begin.

ORDINARY
prompt
response
…and it stops.
A FACTORY
something happens
an objective
a promise
deliverables
tasks
attempts
results
a resolution
proof
deployment
something happens
…and the last line is the first line.

And the question at the top is not the one you'd expect. It never asks "can an agent do this?" That question is nearly always yes, and yes is not useful. It asks four:

01
What must become true?
02
What must be produced to make it true?
03
Who or what can produce it?
04
What evidence proves that it is?

Four questions instead of one. That's most of the difference right there.

How it knows

Ten rungs, each answering one question

The factory doesn't run a state machine. It runs a derivation ladder, and every rung is derived from the one above it.

Objective what should become true?
Promise what exactly will be delivered?
Deliverable what tangible thing must exist?
Task what work can produce it?
Attempt who tried, and how?
Result what did it produce?
Proof what evidence says it is true?
Resolution was the result accepted?
Path which route delivered it?
Actor who or what did the work?

Two rules govern it, and both are load-bearing. A higher rung is never complete because a lower rung exists — a task existing doesn't make a deliverable covered, and a passing test doesn't make an objective achieved. And advancing is child-creation, not a status change: when a goal moves from unrealised to covered, nothing flips. A new object gets created underneath it, and the edge between them is the record.

The graph is the state. Not a status field.

You can read a status field for speed — a board, a list, a dashboard, grand. No gate may ever trust one. When the field and the graph disagree, the graph wins and the field gets rewritten, because a field is a cached opinion and the graph is what actually happened. Most work-tracking software has this exactly backwards: a ticket is in Todo because a human dragged it there. Nothing about the world changed. The card moved.

NO GLOBAL STATUS COLUMN — EACH RUNG HAS ITS OWN SMALL LIFECYCLE
Objective
unrealised → realised
Deliverable
uncovered → covered → proven
Task
blocked → ready → running → done
02 The engine

The engine

Two movements, and only two

Every turn is one of two moves, and which one fires is a presence check rather than a judgment call.

Does the work already exist?
YES → EXECUTE

Run it

A task is ready, so it runs. A result has no proof, so it gets verified. This is the half every task runner already does.

NO → ELABORATE

Create it

No promise under the goal, so it writes the promise. No deliverables under the promise, so it derives them. No task under a deliverable, so it writes the task.

The usual model is while tasks exist: execute tasks, which is fine until you hand it a fresh objective. A fresh objective has no tasks. It has nothing. The loop terminates immediately, having done nothing, correctly.

So the factory has to manufacture its own missing production structure. That's why one sentence is enough to start, and it's the single most useful property the thing has.

ONE TURN OF THE REALISATION LOOP
objective realised? no → write the promise
deliverables covered? no → derive them
tasks exist? no → plan them
a task ready? yes → execute it
work running? yes → wait
dependency cycle? yes → escalate
everything proven? yes → complete

One bound goes on ELABORATE, learned the hard way: a rabbit hole is not a loop. A loop returns. An unbounded elaborator finds a gap, elaborates it, finds a gap inside that, and never comes back. So: go a little way in, come back, say what you found, file it, don't descend.

Not one cycle

Four loops, different owners, different clocks

The temptation is to draw all of this as one big cycle. It isn't one. Collapsing them is how you get a system that can't tell "we haven't decided" from "we haven't built it."

1

Signal loop — creates work

world → signal → objective
the business loop — humans, heavily
2

Realisation loop — creates the structure of work

objective → promise → deliverable → task
the factory
3

Execution loop — performs the work

task → route → actor → attempt → result
the workforce
4

Proof loop — decides whether it counts

result → verify → resolve → deploy
the gates

back to the world → a new signal

LEARNING

Watches all four and reweights every route they used. It isn't a fifth loop in the line — it's the thing reading the other four.

The first loop is the business loop, and it contains the first act of intelligence in the whole system: a signal is not yet work. A customer complaint, a failed deploy, an observation from a support call. It becomes work only when someone decides this is a change worth making. Anything that promotes itself straight from idea to build has skipped that decision, and you find out which ideas those were later, expensively.

Structural
what is missing?
changes the shape of the work
objective → deliverable → task
Operational
can this be completed?
changes execution state
ready → running → resolved
Epistemic
do we know it worked?
changes belief
hypothesis → evidence → proven
Structure is not execution. Execution is not belief.

Merge any two of those and you get a system that can't distinguish "we haven't decided what this needs" from "we haven't run it yet" from "we ran it and we don't actually know if it worked." Three different problems, three different fixes — and the third is the one that quietly ships broken software.

STRATEGIC CLOCK
What should we build?
humans, heavily
signals · markets · customers · taste · risk
PRODUCTION CLOCK
How do we build it?
the factory, increasingly alone
objectives · promises · deliverables · tasks · proof
LEARNING CLOCK
What did we learn?
every close
results · failures · cost · retries · routes

Humans keep the first — direction, taste, values, risk tolerance. AI assists there and should not replace it. The factory takes the second, increasingly alone. The third runs on its own, and it's the part that compounds.

03 The line

The generator you type into

The line is not the operating system

The thirteen-station line isn't the factory's master lifecycle. It's one particular elaborator — the thing you run when the structural loop points at a hole and says a capability is missing here. The factory inspects the graph, finds the gap, and calls a generator to fill it.

THE FACTORY LOOP ASKS
What is missing?
THE LINE ANSWERS
Here is how I create it
A sentence
the thing you want to be true
A promise
the terms, plus one command of proof — written while it still fails
The fan-out
scouts read in parallel · one mind decides · many hands build
The gates
tests, types, eight scored dimensions, a bar — below the bar, it goes again
The proof runs once more
the same frozen command — kept, or not yet
The record
every result routes the next round

Idea to reality, station by station

Thirteen stations, and the tests come before the code

This is the line, in order. Read it top to bottom and you have watched a sentence become something deployed — and you can see the two places where it refuses to work the way software normally gets built.

01 AIM the sentence, and how big a job this is
02 PROMISE the schedule of work, each item with its own check
03 SURVEY what already exists — expose, extend, build, or drop
04 DESIGN the shape of the thing, before anyone types
05 DOCS the full doc set — written first, because the docs are the spec
06 PLAN the cycles, the waves, the order
07 TEST drawn from the docs — written before the code exists
08 BUILD make the docs and the tests true
09 VERIFY types, tests, links, secrets — the shell, not a model
10 PROVE the frozen command runs against the shipped thing
11 TEACH reconcile any drift, so every doc ends true
12 SHIP it deploys
13 LEARN the record changes, and routes the next one

The docs are written at station five, before the code exists. Not notes, not a stub — the full set, in the reader's language. That is the spec. Then the tests are drawn from those docs at station seven, still before anything is built. So by the time BUILD starts, the thing it has to satisfy is already written down and already failing. Build's job is to make the docs and the tests true.

Which is the opposite of the usual order, where code is written, then tested, then — if there is time — documented. Do it that way and the documentation describes whatever got built, the tests assert whatever it happens to do, and nothing in the pile can tell you the feature is wrong. Written first, all three disagree loudly when it is.

The second refusal is at station ten. PROVE runs the command that was frozen at station two, against the deployed thing, unedited since the promise was made. VERIFY at nine asks whether the code is sound. PROVE asks whether the promise was kept. A cycle can pass one and fail the other, and it is the second one that decides.

The line prunes itself to the size of the job

Thirteen stations for a typo would be a ceremony, and a ceremony nobody believes gets skipped entirely. So the walk is cut to fit the work — and the cut is a rule, not a mood:

PATCH 3 of 13
AIM → BUILD → VERIFY
a typo does not need a promise
FIX 8 of 13
adds SURVEY · DOCS · TEST · PROVE · LEARN
plus INVESTIGATE when it is code we did not just write
FEATURE 13 of 13
the full spine
nothing skipped
SCHEMA 13 of 13
FEATURE, with substrate reconcile at maximum
the brain is involved

The tier is decided once, at AIM, and everything downstream reads it.

04 A cycle, end to end

All five acts, start to start

What actually happens to one sentence

The parts have been described one at a time. This is them running — one sentence going the whole way down, from something a person said to something the system can prove, and the whole way back up as a change in what the record knows.

Five acts. A signal becomes an objective, because someone decides it matters. The objective gets a promise underneath it, and the promise gets deliverables, each with its own check, all of them red. The work gets made and the making gets watched — who did it, how many attempts it took, what it cost. The checks get run. One comes back red, goes round again as new work, and settles. After that the record is different, and the next piece of work like it routes differently.

The sentence is an example. Nothing that happens to it is — every move below is one the machine already makes, shown at the only scale where you can watch all of them at once.

Act I · Signal → Objective
ends with a sentence someone accepted as work
Act II · Objective → Promise → Deliverables
ends with a frozen promise and four checks, all red
Act III · Task → route → actor → attempt → result
ends with six results nobody has verified yet
Act IV · Result → Proof → Settlement → Deploy
ends with 4 of 4, exit 0, settled, live
Act V · Deploy → the record → a new signal
ends where Act I began, with a better record

Five acts. The last one hands you back to the first.

Act I

The world speaks, and someone decides it matters

The world sends raw material all day. Almost none of it should become work.

The world talks all day. A support call, a failed deploy, a sales objection, a line in the analytics, a competitor’s move, a developer’s aside on the way to something else. All of it is raw material, and almost none of it should become work.

That refusal is the first act of intelligence in the whole factory. A signal is not yet work. It becomes work only when somebody decides this is a change worth making — and everything downstream is expensive, so none of it is any use spent on the wrong sentence.

Which makes capture the hard part. A board will not take an idea until you know where it goes, and it asks at the exact moment the idea arrives. So the thought that occurs to you mid-sentence, about a ticket you are not looking at, mostly never gets recorded — not because it was weak, but because placing it cost more than having it.

So there are two layers. The board, deliberate and ordered, where work is split and merged and reparented. And underneath it a cheaper one: say the thing, tag it, walk away. The world already knows how to answer who handles this — give a thing a tag and it reaches whoever handles that kind of work. What it cannot yet answer is where does this belong: the draw that would take an untethered idea and pull it to the piece of work it concerns is designed and not built. It would route. It would not promote.

Splitting an idea in two is not a text edit either — the parent stays, two children are derived beneath it, and both inherit its reason for existing.

Then somebody reads one line and decides it matters.

/do "A user can create an AI assistant without code"

The factory now has an objective.

THE BOARD
deliberate · ordered
Projects, tickets, order
what the work is and where it sits
Split · merge · reparent
changes the shape, not the text
The price
you must know where it goes
THE TAG STREAM
cheap · unplaced
Say it · tag it · walk away
no destination required
Something else finds the place
you were never asked to aim
The price
none — which is the entire point

Layer two exists because layer one charges you for placement.

TWO QUESTIONS, TWO TARGETS
Router who handles this? → an actor, who acts on it
Magnet where does this belong? → the objective or task it sits under, which collects it
Running today give a thing a tag and the world reaches whoever handles it
Designed the draw from an untethered idea to the work it concerns — not built

Same weighted paths, two different targets. Only the first one runs today.

Something happens in the world
a support call · a failed deploy · a line in the analytics
Tagged, and drawn to where it belongs
still just an idea, now in the right place
Is this a change worth making?
the first act of intelligence, and it is a person’s
No
it waits where it landed
nothing is lost, and nothing is spent
Yes
/do "A user can create an AI assistant without code"
an objective the factory has accepted

The draw would route. It would never promote.

Act II

An objective arrives with nothing underneath it

So the first thing the factory builds is the contract.

The sentence is accepted. Now look underneath it: nothing. No plan, no deliverables, no work of any kind — an objective is a thing that should become true, and on the day it arrives that is all it is. This is where ELABORATE fires. The factory cannot execute work that does not exist, so it manufactures the missing structure, and the first piece it makes is a promise.

A promise is the statement of work an engineering agency signs with a client. It names, exhaustively, what the client receives, and each item carries its own check — one command that exits clean only when that item is delivered and wired, not merely present. The acceptance test is then not written at all. It is the join of every check, in schedule order, unchanged. Nobody authors the proof; it falls out of the schedule, which is what makes it impossible to promise more than you check, or to check less than you promised.

Two rules do the rest. Not listed is not promised — an item that never made the schedule is out of scope by law, written down as such rather than discovered as a gap six weeks later. And the terms freeze at the making. After this they cannot be edited, which is the entire value of writing them.

Then the part that looks like a mistake and isn’t. Every check is run immediately, and every one fails. A proof that is green the day you write it is not a proof, it’s a description of something that already exists. Four red checks, each red for its own reason, are the first honest inventory of what this objective is missing.

And a promise existing does not make the objective realised. It only means the factory now knows what it owes.

Objective
"A user can create an AI assistant without code" — accepted
Look underneath
no promise · no deliverables · no tasks · nothing
ELABORATE
the missing structure gets manufactured, not waited for
Promise
the schedule of work, each item carrying its own check
Deliverables
four named things the client receives

EXECUTE runs work that already exists. Nothing exists here yet, so the other move fires.

THE SCHEDULE
A builder screen, no code field do-prove.sh --route /build/assistant
Try it before publishing bun test assistant.test.ts -t "draft replies"
A published assistant, own address do-walk.sh assistant --agents
Editable after publish bun test assistant.test.ts -t "republish keeps the address"
Out of scope voice calls · team seats · custom domains — not promised, so not owed

Four red checks, four different reasons — no route, no test, no published record, no edit path. That list is the map of what doesn’t exist.

THE PROOF IS THE JOIN
do-prove.sh --route /build/assistant && bun test … -t "draft replies" && do-walk.sh assistant --agents && bun test … -t "republish keeps the address"
one command settles the contract

Nobody wrote this line. It is the four checks above, verbatim, in schedule order — and today it exits red.

Act III

The work gets made, and the factory watches how

Four deliverables become six tasks, two graphs, and a stack of receipts nobody has read.

Four deliverables came out of the promise, each with its own red check. None of them is work yet. Work is what you get when you ask of each one what could produce this, and write the answer down as a task.

Six tasks came out of the four. And the moment they exist, a second set of edges appears that must never be merged with the first.

Derivation says why a thing exists: this task is here because that deliverable needs it. Dependency says when it may run: minting the assistant’s public address can’t start until saving a draft has finished, and those two tasks sit under different deliverables entirely. The edges cross. They answer different questions, and a system that keeps only one of them cannot tell "nothing justifies this" from "nothing has unblocked it." Both look like a task sitting still. They need opposite fixes. One waits; the other gets deleted or gets a parent.

A task is not a result. It is an instruction to attempt a result, and the attempt is a separate thing with its own record. Blocked, ready, running, done — that is the task. Started, failed, succeeded, and what it cost — that is the attempt.

Then the crew. Scouts read in parallel: the form components already in the codebase, the publish path, how public addresses are handed out today. One mind read all three reports and made the call none of them could — the draft and the published assistant are one record in two states, not two records. Then hands edited at once, a file each.

Rendering the assistant at its address took three attempts. Two failed, the third landed, and every one wrote its own receipt: route, duration, cost. Seventeen pence for a job the cheap route usually does for six.

Six results are in hand. Nobody has checked a single one.

DERIVATION
why does this exist?
deliverable → task
the task is here because that deliverable needs it
answers
is this work justified?
broken looks like
a task nothing above it claims
the fix
delete it, or give it a parent
DEPENDENCY
when may it run?
task A → task B
B cannot start until A has finished
answers
is this work startable?
broken looks like
a task waiting on something unfinished
the fix
wait

Same objects. Different edges. Merge them and "unjustified" and "not unblocked" become the same red.

FOUR DELIVERABLES, SIX TASKS
A builder screen with no code field
deliverable 1 · covered
Build the form, no code field
task · done
Save a draft assistant
task · done
A way to try it before publishing
deliverable 2 · covered
A preview room that talks to the draft
task · running
A published assistant with its own address
deliverable 3 · covered
Mint the public address
task · ready — waited on "save a draft", under another parent
Render the assistant there
task · blocked — needs the address
Editable after publish, same address
deliverable 4 · covered
Republish to the same address
task · blocked — needs the render

A snapshot part-way through. One dependency crosses between parents — exactly the edge the derivation graph cannot see.

A task sitting still
it has produced nothing, and it isn’t running
Unjustified
nothing above it says why it should exist
delete it, or derive it from a deliverable — no amount of waiting fixes this one
Not unblocked
something it depends on hasn’t finished
wait, or go and unblock the thing before it — nothing is wrong; it isn’t its turn

Two reds that look identical on a board and mean opposite things.

Act IV

The verdict

Six results in hand. The frozen proof runs once more, and one of them comes back red.

Six results in hand, and four checks to answer to. That mismatch is the whole act. A successful execution is not a proven deliverable: the agent finished, the build went green — and every one of those sentences is about us rather than about the person who wanted an assistant.

So the promise is opened and the four checks are run. They are the same four commands written into the ticket at the making, before a line of code existed, and nothing about them has been touched since. That is the point of freezing them. A check edited after the fact proves whatever the edit wanted.

Three come back green. One does not: the published assistant answers at its address, and the greeting isn’t on the page — the publish wrote the draft rather than the live copy. The proof is all four joined by an and, so three greens exit 1. The verdict is the join, not anyone’s reading of it.

A red is not a dead end. The deliverable drops back to uncovered, which is more useful than failed, because it names what is missing. That becomes new work: one task, one attempt, and then the same command runs again, unedited, and comes back green. Four of four. Exit 0.

The criteria could be written that early because they name the thing being built rather than the code — a route, a greeting, an address that survives a republish. Written that way, one line reads twice: as a command a shell runs, and as a script that drives the running product the way a person would. Only the first reading is wired today. And some proof can’t be read either way — whether that builder screen looks right needs a person to look, which runs at human speed, so it is priced at design time rather than discovered here.

Then it settles — off chain always, on chain on testnet — and only then does anything deploy.

THE JOIN, RUN ONE
Builder screen do-prove.sh --route /build/assistant · green
Try before publish bun test … -t "draft replies" · green
Published address do-walk.sh assistant --agents · red
Editable after publish bun test … -t "republish keeps the address" · green
The join 3 of 4 · exit 1 · not settleable

Four deliverables, four checks, one exit code. Three greens are not a kept promise.

A RED GOES BACK ROUND
Red verdict
/a/demo answers, and the greeting is not on the page
The deliverable drops to uncovered
not failed — unproven, and now specific
One task, one attempt
publish the live copy rather than the draft
The same check, unedited
do-walk.sh assistant --agents
4 of 4 · exit 0
the join nobody touched

The check is never rewritten to fit the result. The result is rewritten to fit the check.

OFF CHAIN
every promise, today
The frozen proof runs once more
at close, the whole join, unedited since the making
Kept or broken, recorded
the route that delivered gains weight, the one that failed gains drag
The verdict is public
and it routes the next piece of work
ON CHAIN
testnet
The same proof, hashed
the terms were frozen on the day the promise was made
Settle, or reject
the contract asks one question: does this satisfy the condition it holds?
What it does not yet check
that every deliverable underneath was covered and proven — designed, not built

One verdict, submitted twice. Only one of the two is final.

Act V

The factory is different afterwards

The cycle ends. The record doesn’t.

It deploys, and nothing announces itself. What changed is in the record.

The route that carried the work gains weight. The route that needed three attempts to do a job the cheap route usually does for 6p — 17p, in the end — gains drag: it delivered, and it was dear, and those are two different facts, so both are kept. Routes nothing touched this cycle fade a little. Nobody writes any of that down. It is what closing a cycle is.

And the same cycle taught two things at once. About the work: publishing has a draft copy and a live copy, and the greeting was written to the wrong one. About itself: the check that first came back green had read the draft — it asked its question from an address no stranger will ever load, so it passed while proving nothing. The first lesson makes this feature right. The second makes the next twenty right.

The next piece of work shaped like this one is routed by those weights, toward what held and away from what didn’t, with nobody in a room deciding. That accumulating record is the thing that can’t be bought, because it is made of what worked in this organisation rather than of general knowledge.

One honest line. The router is switched off. With one worker per capability the choice is degenerate, and routing on a handful of samples hardens noise into belief that then gets injected into every decision after it. We record the evidence and switch it on when the sample is real.

Then someone signs up, types one sentence about her shop, and by evening an assistant is answering her customers. She writes back to ask whether it can do Spanish.

That is a signal. It is not yet work. Which is where we came in.

ABOUT THE WORK
what this feature needed
Publish writes two copies
a draft and a live one
The greeting landed on the draft
the page a stranger loads was bare
Worth
this one feature
ABOUT ITSELF
what the factory needed
A green check that read the draft
it passed, and it proved nothing
The join caught it, not a person
a weak check is now a known shape
Worth
the next twenty features

One cycle, two students. The second one is the compounding half.

WHAT ONE CLOSE WRITES
the route that delivered gains weight
the route that took three goes gains drag — it delivered, and it was dear: 17p against the usual 6p
routes nothing used fade a little
the deliverable that came back red kept as its own attempt, not tidied away
the cycle itself dated, costed, and attributed to what ran it

Nobody types any of this. It is what closing a cycle is.

It deploys
nothing announces itself
Someone signs up
she types one sentence about her shop
An assistant answers her customers
the promise, in somebody else’s hands
"Can it do Spanish?"
that is a signal
Not yet work
someone still has to decide it’s a change worth making

Which is where the first act began.

Nothing in those five acts needed a hundred agents. Strip it to the smallest version that still closes: one objective, one deliverable, one task, one attempt, one result, one proof, one learning. That is already a factory. Everything larger is that shape run again inside itself — a deliverable that turns out to need three of its own, a failed check that comes back as new work with a promise of its own underneath it.

So the thing to scale is not the workforce. It is the recursion. A hundred agents with no ladder under them is a hundred workshops; one loop that can create its own missing structure will build the second, and the tenth, and the ones nobody has thought of yet.

Which is why it starts so small — and why everything after this is about what it takes to keep it honest at scale.

05 The gates

ONE CYCLE, FOUR WAVES

Then it fans out

One agent doesn't build a feature. A crew does — each member the cheapest one that can do its job well. Scouts read the territory in parallel and report back in facts. One mind — the strongest model, exactly once — makes the decisions, because understanding is the one thing you never split. Then many hands edit at the same time, one file each.

And the checking is ruthless, because most of it is free. Before any model scores anything, the shell does: tests run, types compile, links resolve, secrets are swept. A model can be charmed. An exit code can't.

Everything is scored, nothing is vibed

Every cycle ends in numbers: tests passed out of total, new type errors (must be zero, forever), and eight weighted dimensions composited against a bar. Below the bar, the cycle doesn't close. It goes again.

Green is earned, never declared. "Done" is not a feeling here; it's an exit code.

Every cycle leaves the system stronger

Most codebases accumulate mess the way kitchens do — a little each day, invisibly, until someone declares a cleanup. This loop runs a ratchet instead: every change must leave the names more consistent, the parts fewer, the pages reachable, the docs honest — or it doesn't land. The ratchet can tighten. It can never loosen.

And the loop remembers

Every finished cycle strengthens the path it took — this shape of work, that model, this approach. Every failure weakens one. The next piece of work is routed by those weights: toward what was right last time, away from what wasn't, no meeting required.

So the system that builds the product is also learning which of its own moves are good. The code improves, and so does the judgment that produces the code.

The rubric

Eight dimensions, fixed weights

Scored on every cycle, in the same shape every time. The bar is how much each one counts.

Security 0.20
no secrets, every boundary validated
Structure 0.15
no type errors, no dead names, every handler closes its loop
Simplicity 0.15
minimum code for maximum feature
Integration 0.15
wired, never orphaned
Speed 0.10
100 Lighthouse, all four categories
Code-reuse 0.10
compose before you construct
Test-coverage 0.10
one assertion per documented claim
UX 0.05
good, not merely correct
Goal-fit 0.30

Sits on top of all eight and carries more weight than any of them. The eight are reweighted underneath it. The gate is 0.65, and below it the cycle does not close.

You'll notice Stability isn't on that list. It used to be. We retired it as a named axis because it was a word rather than a measurement: type errors, dead names and silent returns moved to Structure, test pass rate moved to Test-coverage. A dimension you can't put a number against is a mood.

Two of the eight are there for reasons worth stating. Code-reuse scores composing over constructing, because a system that adds a new primitive every time it meets a new problem stops being one system. UX is folded into the code score deliberately, so a technically flawless cycle that ships a miserable experience cannot pass clean.

The target is 1.0, and the score is an instruction

The target on every dimension is 1.0, not "no regression." Anything below 1.0 has to produce a specific instruction, with a file and a line, and that instruction becomes input to the next cycle. The rubric is a map forward, not a verdict. 

security:    0.85  all boundaries validated
  → improve: api/provision.ts:31 missing
    parse on the slug param
simplicity:  0.70  net +34 lines; one helper
                   added outside scope
  → improve: inline formatDate at
    lib/slug.ts:12, saves 9 lines
structure:   1.00  clean
composite:   0.87  pass

A 1.0 means there is nothing to improve — say "clean" and move on. Everything else owes the next cycle a sentence it can act on. The score is written into the record as a vector rather than a single number, so you can watch simplicity slide over twenty cycles while the composite stays comfortable, which is exactly the drift a single number hides.

Some things aren't scored — they're disqualifying

A weighted average has one dangerous property: a catastrophe becomes a deduction. Score badly enough on security and the arithmetic still lets you through on the strength of your test coverage. So a short list bypasses the composite entirely and fails the cycle outright.

  • a hardcoded secret or API key
  • eval() or unsanitised HTML injection
  • a test failing on a file this cycle touched
  • Lighthouse dropping more than 5 points
  • fabricated proof

That last one is the one to keep if you could only keep one. A check that looks like evidence and isn't is worse than no check, because it spends the trust a real check earns.

The distinction underneath all of it

Quality is not fit

Production doesn't finish when an agent says "done." It finishes when the system can establish that the promise was kept — and the gap between those two is wider than it looks. Watch where the claim quietly changes:

task build the product listing page
execution the agent wrote the page
outcome the build succeeded
evidence a page exists at /products
proof GET /products returns product data
verdict pass

Every line is true. Only the highlighted two are about the customer.

A task can succeed on every measure it owns while the deliverable it was meant to serve remains unproven — which is why a deliverable has three states rather than two: uncovered, covered but unproven, proven. A failed proof isn't a dead end either. It goes back round as new uncovered work, because "we tried and it didn't establish the thing" is information about what's missing.

A beautifully implemented feature that solves the wrong problem is a failure.

So fit is scored separately, and a fit of zero prevents settlement no matter how good the code is. The factory has to be able to say: the implementation is excellent, the objective was not achieved, this does not count.

Seven questions, and they're a climb

Did the thing get made · does it satisfy the promise · does it work · is it reachable · does it preserve what must not break · is it safe · is it actually the thing we wanted. They look like a checklist. They're a climb — each one is answerable only from a certain height, and the last cannot be answered from the height that answers the first.

A5 The watcher
not built
are the loops themselves healthy?
sees: all the loops, over time
A4 The architect
not built
what does this do to everything else?
sees: the backlog, not the ticket
A3 UAT
not built
does the application work?
sees: the running thing, driven as a person would
A2 The adjudicator
not built
is that red actually red?
sees: all six verdicts at once
A1 Six perspectives
built
is this right from where I stand?
sees: one ticket, from one angle
A0 The script
built
did it get made, does it work, did anything break?
sees: the diff — blind to the UI

Higher isn't smarter. It's looking at more.

Climbing from A1 to A2 is where the gap we haven't closed lives. Six reviewers each return red or green, and a red is a claim, not a veto — it means the work is wrong from that reviewer's angle, and the thing above them has information none of them has: the other five verdicts. It needs two moves a score can't make, overrule and tweak. Today's gate is a weighted mean. An average can't overrule, because a hard red just drags the number down a little; it can't tweak, because a number carries no instruction. The perspectives get collected and then thrown away, and what survives is their arithmetic.

Three proofs, three clocks

Not all proof is machine-checkable, and pretending otherwise is how a line stalls. Whether a UI looks right needs a person to look. Whether a campaign worked needs the world to answer. Both are named at design time rather than discovered at proof time — priced in advance, they're a known cost on a known deliverable.

Software proof
a command exits 0
answered by the machine
seconds · deterministic
Visual proof
a person looks
answered by a human
minutes · judged
Market proof
a number moves
answered by the world
weeks · statistical

Market proof can't be made deterministic and shouldn't be pretended into a script. What it can be is named up front — this campaign is proven when this many of these people do this thing by then — and the deliverable sits at "covered but unproven" for as long as it takes, honestly. Discovered at the end instead, there's a tempting way out: settle on the thing you can check today, which is that the campaign shipped. It shipped. It ran. Every send landed. That's the same gap as above, one clock further out, with more money on it.

The part worth defending hardest

The question your checks cannot ask

Picture an electrician finishing a house. Every socket tested. Every switch tested. Every light tested. The report comes back clean, and it's an honest report — everything that was installed works.

But nobody put a light in the hallway.

There's no fault to find. The tests can't fail, because a thing that doesn't exist can't be tested. The report is green and the hallway is dark.

EVERY CHECK YOU OWN
tests does this work?
linters is this well-formed?
monitors did this fail?

All presence checks. They reach for a thing and report on what they find.

WHAT A LADDER CAN ASK
deliverables no task serves
goals nothing is building
work nothing can start

Because every rung is derived from the one above it, you can walk the structure downward. Absence stops being an absence of information and becomes a list.

That gap has a price, and it's in our own record rather than in a hypothetical. Four separate times we built a capability, tested it, shipped it, wrote it up as delivered, and never wired it: the scheduled handler nobody imported, the cron triggers nobody registered, the learning jobs nobody seeded, the feature flag nobody switched on. Every one passed every gate we own. Nobody was careless. The checks cannot ask that question.

A green board says everything you built works. It doesn't say you built everything.
06 The memory

The moat

The factory is a routing system

The core question is not which model is smartest. It's: which route is most likely to deliver this particular work, at acceptable cost and risk?

A ROUTE
tool → model → skill → agent → workflow → verification
DELIVERY IS NOT EFFICIENCY
Attempt 1 failed
Attempt 2 failed
Attempt 3 succeeded

Delivered — but the route that delivered it was expensive, and a system that only records "succeeded" has thrown away the interesting half.

So delivery is tracked separately from efficiency. Not "this agent worked," but a route with a profile:

strength 73
resistance 4
delivery rate 0.94
attempts per delivery 1.2
cost per delivery 6p

A route can be reliable and dear, or cheap and flaky, and those are different tools for different jobs. You only get to make that choice if you kept both numbers. Every success strengthens the route that produced it, every failure adds resistance, and unused routes fade:

random routes
tested routes
successful routes
cheap successful routes
trusted highways
THE MECHANISM, RUN BY HAND

That accumulating map is the moat, and it isn't the agents — agents are interchangeable and cheaper every quarter. What the factory has learned about how this particular organisation builds software is not. It isn't storing history; it's learning the topology of work.

One restraint worth stating, because it looks like a missing feature and isn't: the router is switched off. With one worker per capability the choice is degenerate, and routing on a handful of samples hardens noise into belief that gets injected into every future decision. We record the evidence from job one and switch the router on when the sample is real.

07 The other output

The other generator

A deliverable doesn't have to be software

A working checkout is a deliverable. So is a funnel that turns strangers into customers, and the second one is no less real for being unbuildable by a compiler.

THE LINE

A capability is missing

Thirteen stations, aim to learn. Out: deployed software, proven by a command that exits 0.

THE PLAYBOOK

A market is missing

A foundation, then ten stages. Out: a campaign in market, proven by a number that moves.

The playbook runs on your business, not on a plausible example of one. A URL or a pasted document goes in; the intake never calls a model, because the extraction is deterministic. The foundation is written into the workspace as the company's context, and the ten stages after it all read it — hook, gift, identify, engage, sell, nurture, upsell, educate, share, refine — each saved as its own asset.

Two things make that a generator rather than a document. It's derived, not authored — it plays the part on the market side that an objective plays on the build side, the rung you walk downward from to find what should exist and doesn't. And it promotes into a skill the workspace's own agents can be routed to. A document tells a person what to do. A promoted playbook is a thing the workforce can be assigned.

Execution has the same shape as a build, which is the point. Approving compiles the card into a real workflow — the same workflow every other kind of work in the system uses — and starts the run. Marketing gets no special primitives:

tool email · SMS · social · content
condition replied? which segment?
delay the spacing between touches
sell suspends until checkout resumes it
human sits in front of the first send

A campaign that sells something suspends at checkout exactly the way a build suspends waiting on a person, because at that level of the machine they're the same event. Building is autonomous: brief in, campaign out, no one asked. Sending is not, and is not going to be. A human step stands in front of the first send when the budget is real. An agent that can spend your money and mail your list without asking isn't a more advanced product than one that can't — it's a different appetite for risk, and that belongs to the owner.

See the ELEVATE playbook
08 The boundary

The verdict

What belongs on a chain, and what doesn't

The obvious mistake is to try to put the factory on a ledger. Don't. A learning system on a chain is expensive, rigid, and wrong in that order. The useful split is constitutional against executive.

The contract decides

  • is this valid?
  • was this allowed?
  • is this obligation satisfied?
  • can this settle?
  • can this money move?
a constitution

The factory decides

  • what should we do next?
  • who should do it?
  • which model, which route?
  • what is the cheapest way?
a government

Neither should try to be the other, and the failure mode of most on-chain ambition is a constitution attempting to run the roads.

THREE LAYERS · ONLY A HASH CROSSES
The graph
meaning · memory · routing
flexible · learning · probabilistic
The line
orchestration · stations · gates
the production system
proof hash
The chain
the promise · frozen terms · the acceptance condition · the settlement
simple · deterministic · final

The chain is not the loop — it's the boundary around it. The contract doesn't watch the work. It stands at four doors, and the loop runs freely between them.

1

The promise is created

Terms frozen, acceptance condition recorded, deadline set, any money staked against it locked. After this point the terms cannot be edited — which is the entire value of putting them there.

2

Work is authorised

Before a task runs: does it exist, does it belong to this promise, is it actually ready, is this actor allowed, does the spend ceiling permit it. Five questions, none of them about whether the code is any good.

3

Evidence is submitted

The execution produces a result and a commitment to it goes up. Not the logs, not the prompts, not the diff. The evidence and the reference.

4

Settlement

The final invariant, checked rather than asserted — and once it lands, no transaction can un-land it.

That last door deserves writing out, because it's the whole argument in five lines: 

promise settleable =
      every objective realised
    ∧ every deliverable covered
    ∧ every deliverable proven
    ∧ proof satisfied
    ∧ no unresolved obligations

No giant complete_everything function. Small composable predicates, each one answerable, joined with an ∧. The contract doesn't need to know how to complete work. It needs to know whether completion is true.

A goal is not complete because the system finished doing things. A goal is complete because the system can prove the promised state now exists.
Incomplete
Structurally complete
everything that should exist, exists
Evidentially complete
everything that should be proven, is
Settleable
the five predicates all answer true
Settled
a one-way door

"Done" stops being something anyone writes down. It becomes a ladder an object climbs, where each rung is checkable by someone who doesn't trust you. No agent gets to declare completion. No founder does either, which is the part I actually like.

0 Promised terms hashed, proof frozen, proof verified failing
1 Building the loop is running cycles
2 Proven the proof command ran green
3 Settled kept — reputation compounds
4 Broken the verdict lands honestly — also final

The promise state machine. States 3 and 4 are one-way doors.

The honest part

One declaration, read twice

The contract is not hand-written. The same schema language that runs the platform's brain defines the promise — a few lines declaring who promises, who attests, what was promised, and how reputation accrues: 

relation promise,
    relates maker,       # who promised
    relates oracle,      # who attests
    owns terms-hash,     # sha256 of the promise file
    owns proof,          # the settlement command
    owns promise-state,  # 0…4, the ratchet
    owns strength,       # kept work adds weight
    owns resistance;     # broken work adds drag
schema/sui.tql
the single source
codegen
promise.move
on-chain law — generated, never edited
substrate-client.ts
the typed caller

The generated contract's header says GENERATED — DO NOT EDIT, and a test pins the emitted lines. To change the contract you edit the schema and regenerate. What the loop enforces and what the chain enforces cannot drift — they are the same declaration read twice.

And notice what the promise owns: strength and resistance — the exact two weights every routing path in the system carries. A kept promise and a proven route compound the same reputation, because they are the same vocabulary. Deliver, and the system sends you more work. Break your word, and the work quietly routes away.

What it will not allow

A contract is worth what it refuses

Everything above is what the contract permits, and permission is the boring half. The useful half is the calls it throws out — because those are the ones that would otherwise let a party mark its own homework, move a verdict after the fact, or hand itself a reputation it never earned. Watch it get drawn, minted, performed, and then attacked.

  1. two parties — a promise with one party is a note to self
  2. and the one who attests — the maker cannot mark its own homework
  3. what is being promised — a file, not a feeling
  4. the terms — hashed, so they cannot drift after the fact
  5. the acceptance condition — one command — the same one the loop runs
  6. the state it starts in — nothing is claimed yet
  7. reputation starts at zero — it is earned here, never granted
  8. and so does the drag — a broken promise costs the same vocabulary it would have earned
  9. the chain keeps the time — a caller who supplies its own timestamp supplies its own truth
  10. and one field it writes only once — settled_at — the moment the door closes
  11. maker calls create_promise(…, clock, ctx) — accepted. minted — the terms are now frozen — a shared object: both parties read it, neither owns it
  12. maker calls advance(to: 1) — accepted. Building — the maker narrates its own progress — and only its own
  13. maker calls advance(to: 2) — accepted. Proven — the work is done and the proof is green — off chain
  14. anyone else calls advance(to: 2) — aborted, ENotMaker. a stranger tries to move it — anyone may read a shared object. that is not the same as writing one.
  15. maker calls advance(to: 3) — aborted, EStateRegression. the maker tries to settle itself — advance can never cross into settlement — the whole point of two parties
  16. anyone else calls settle_promise(kept: true, …) — aborted, ENotOracle. someone else tries to attest — a verdict from an address nobody named is not a verdict
  17. oracle calls settle_promise(kept: true, amount: 999999) — accepted. even the oracle is bounded — an honest oracle asking for too much gets 10,000 — the clamp does not care who asked
  18. oracle calls settle_promise(kept: true, …) — accepted. Settled — kept — strength rises, settled_at is written from Clock, an event goes out
  19. maker calls advance(to: 2) — aborted, EAlreadySettled. the maker tries to reopen it — the same wall, reached from the other entry point
  20. oracle calls settle_promise(kept: false, …) — aborted, EAlreadySettled. the oracle tries to change its mind — the party that was trusted to decide is not trusted to decide twice
  21. final, and final for everyone — the record cannot be edited by the people it is about
The promise contract, drawn and then tested. Five of the calls below are refused — by the address that sent them, by the direction they tried to move, or because settlement had already happened. Every guard, state and function name is projected from schema/sui.tql; the addresses and hashes are placeholders.
09 The rules

Why it works

Three rules, none negotiable

1

Every action ends in a recorded result

Success, failure, or dissolved — nothing ends silently, so nothing is lost.

2

Time is structural

Tasks, waves, cycles — never days or sprints. A calendar can’t be measured into memory; a cycle can.

3

Every loop reports numbers

If you can’t measure it, you can’t route around it.

Follow those three long enough and something quietly remarkable happens: the loop starts earning autonomy. Good scores, cycle after cycle, open the gates one by one — until the system is picking its own next promise, building it, proving it, and asking a human only when something genuinely needs a human.

All of it, on one page

The blueprint

A signal enters. A proven change emerges. The factory remembers what happened and becomes better at the next signal.

↺ one loop · every rung derived from the one above it
The world
A signal
An objective
A promise
A deliverable
A gap
elaborate →
A task
A route
An actor
An attempt
A result
Proof
Reject
→ learn
Accept
→ settle
Deploy
A new signal

↺ and the world answers again

10 Where this is

Where this actually is

Plainly, since the whole argument is that green boards lie

Running today

The line, station to station. Many jobs at once, each sealed in its own copy of the repo. Contracts whose acceptance is a command rather than an opinion — 815 of those checks across our contracts. The gates that refuse. 300 plans written and 612 finished jobs on the record, measured in this repo on 29 July 2026. Settlement off chain always, and on chain on testnet.

Running today, on the market side

The playbook end to end: a URL in, deterministic extraction, the foundation written as the workspace's context and ten stages saved on top of it, promoted to a skill the workspace's agents can run, rendering at one address that prints as a book. The campaign path: one brief, ten parallel stages streaming in as they land, approval compiling the card into a real workflow, with email, SMS, social and content agents on the far end and a human gate in front of the money. And client software on the same stations — a moving company whose website and chat agent are built from one fact set, nine deliverables each with its own command, settled kept.

Designed and not armed

The half that would make marketing compound. Refine is generated as an asset — a plan for what to test next — and nothing yet writes a campaign's results back onto the playbook entry that produced it. The market generator sits exactly where the ladder sits: it runs, it produces real output, and the loop that would let it learn from what happened is a design rather than a row. A campaign that can't tell you whether it worked is the marketing version of a green board.

Landed since

The ladder itself, as rows rather than files. Our own contract for this work carries seventeen deliverables and sixteen checks, and on the day we wrote it every one was red, each for its own reason, verified against production. On 29 July 2026, fifteen were green against the live cluster, none were red, and one could not run — it needs a scratch database, because the gate it proves must never be proven against production. Objective, deliverable and attempt are types the database accepts rather than words in a design document, the write path is a receiver rather than a migration, and the board that says so is generated by the same command, not typed.

Not started

The adjudicator above the reviewers. The watcher above the loops. The thing that keeps the line running with nobody starting it. All queued behind the write path on purpose: a daemon that guarantees a worker for every ready job is worth nothing while the ready-job question returns nothing, and worth less than nothing while a human fills the board in by hand — then it just makes a hand-cranked process look automated.

For most of its life the factory was the fifth instance of the pattern it exists to prevent: deployed, validated, serving nothing. The only difference between it and the four before it was that a check said so, out loud, on a day when nobody went looking. That check has since gone green — the ready-job question returns a job, and the downward query returns gaps — so the claim narrows rather than disappears: it answers, and nothing yet acts on the answer. The daemon above it is still not started, and it is worth building now for the first time, because the thing it would have had to poll no longer comes back empty.

The bet

Generation is already fast enough to be dangerous

Most of the industry's effort is going into making generation faster. The scarce thing is proof, and proof isn't a model problem. It's a structure problem.

The claim is that whoever gets the structure right ends up holding something the model vendors can't commoditise, because it's made of what worked in one specific system rather than of general knowledge. And a structure that can only hold code is holding half a business: the same ladder has to carry the campaign that sells the thing, or the record stops at the door of the room where it's decided whether any of it was worth building.

That was falsifiable, and one event tested it — the day the downward query ran against the live graph and named those four dark wires without being told about them. Not four it was handed. Four it went and found. It ran on 29 July 2026 against the production cluster and came back with five rows: the four wires, and the hand-seeded tracer the test itself had planted, which it could not tell from the real ones and correctly did not try to. It could have come back empty, in which case we'd have built an expensive way to say "all good" while the four wires stayed dark behind a green board. It didn't. The board is public, it is generated rather than written, and it prints the receipt it was generated from.

A workshop that keeps its promises

Not artificial intelligence as a better autocomplete — a factory that keeps its promises, keeps score, and keeps getting better at both. ONE is customer zero: the first thing the factory builds is the factory, and the second is the market for it.

The fastest way to believe it is to hand it a sentence. The second fastest is to read the board it keeps on itself — including whatever is red on it today.

Read the factory's own board Walk the ELEVATE course See the contracts on-chain