watch it run
The body in motion.
The organism pages show you the anatomy, one system at a time, standing still. This page runs a real job through all of them. One worker takes a single task from claimed to deployed, and every step it takes lands on a permanent record. The systems are the anatomy. This is the body in motion.
Open the coding loop below and watch it run, or press play and let it run itself.
software · the deep end
The hardest kind of work, run in the open.
Software is the most revealing kind of work to run this way: it has the most steps, and the steps the loop keeps are exactly the ones most AI tools skip. The coding and research loops are live below. Design runs the same governed way, next. The same system runs your team’s work too, with fewer steps.
loop 01 · governed buildLIVEShip code, safely
Watch an AI write production code and land it on your main branch through a loop that checks its work at every gate.
Ship code, safely
Watch an AI write production code and land it on your main branch through a loop that checks its work at every gate.
the governed build loop
Watch an AI ship production code to your repository, reviewed by an outside set of eyes, on the record.
This is the loop that built the page you are reading. Below is the whole of it, one step at a time, with the record each step writes down. Nine steps in, one change is live and nine records are on the ledger.
the scary part
Letting an AI touch your codebase is the scary part.
So main is protected. Your change arrives as a request, never a push, and only lands after passing every gate.
every step · 01 → 09
One task, nine governed steps.
This shows the loop as its core moments: claim, pull request, an outside review, merge, recap. A cell works down the rail; each step names the safeguard that keeps it safe. Open "show all nine steps" for the full run, or press play to watch it and pause on any step to read it.
- claimthe Skeleton
One owner at a time. The task state machine will not let two cells hold the same work.
on the recordrepo.tasks · proposed → active · claimed_by, claimed_at
- isolatethe Immune System
A lease with a fencing token. A stale worker cannot write over a live one.
on the recordagent.worktrees · lease acquired · leased_by, fencing_token
- buildthe Bloodstream
Every change is a commit on a branch, never a silent edit to main.
on the recordgit · commits on the feature branch
- open a PRthe Bloodstream
Main is protected. Code arrives as a request, not a push.
on the recordgithub.pull_requests · draft → open
The author never approves their own work. The reviewer is a different system.
on the recordgithub.pr_reviews · verdict recorded
No finding is ignored. Each one is answered on the record before merge.
on the recordrepo.task_comments · every finding answered with proof
A dependency the merge cannot skip. QA has to pass first.
on the recordrepo.tasks · a QA task gates the merge
The gate is mechanical. An open finding blocks the merge.
on the recordgithub.pull_requests · merged, merge SHA recorded
- deploy + recapthe Nucleus
Nothing is done until it is deployed, smoke-tested, and written down.
on the recordagent.session_summaries · deployed, smoke passed, recap
loop 02 · researchLIVEGather and verify
Watch a worker answer a question with sources, checked by a second pass, and land the finding on the record.
Gather and verify
Watch a worker answer a question with sources, checked by a second pass, and land the finding on the record.
the governed research loop
Watch a worker research a question and land a finding that carries its own proof.
A research question runs the same governed way as code. Every source is captured, every claim is tied to where it came from, and the finding lands on the record for the next worker to read back before it starts.
the scary part
An AI that makes things up is the scary part.
So no claim is taken on trust. Each one is tied to the exact source it came from, and a separate pass tries to refute it before it is written down. A claim that cannot show its source, or cannot survive a second look, never lands. The finding on the record carries its citations with it.
every step · 01 → 05
One question, five governed steps.
A cell works down the rail. Each step names the safeguard that keeps it honest and the record it lands. Press play to watch the whole pass, or pause on any step to read it.
- claim the questionthe Skeleton
One owner at a time. The task state machine will not let two cells hold the same question.
on the recordrepo.tasks · proposed → active · claimed_by, claimed_at
- gather and citethe Nucleus
No claim without a citation. A statement with no source does not get written down.
on the recordops.knowledge_base · back_refs · every claim cited to its source
A claim survives only if it holds up to a second look, not because it was stated confidently.
on the recordrepo.task_comments · each claim checked, weak ones dropped
- the finding landsthe Nucleus
Findings live in the record, not in a chat log that scrolls away.
on the recordops.knowledge_base · finding recorded with its sources
- read backthe Senses
Recall is by meaning, not by remembering a file name. The finding surfaces when it is relevant.
on the recordpgvector · embedded, recalled by meaning
the receipts
Every finding lands as a record you can read back.
Findings are not lost in a chat log. Each becomes a decision, a lesson, or a knowledge entry, with its sources attached, and stays recallable by meaning.
loop 03 · designLIVEDesign to a written system
Watch a worker produce a design pass held to the color, type, and motion rules this site runs on, reviewed against that written system before it ships.
Design to a written system
Watch a worker produce a design pass held to the color, type, and motion rules this site runs on, reviewed against that written system before it ships.
the governed design loop
Watch a worker design against a written system, not by taste, and land the direction on the record.
This is the loop that designed the page you are reading. The color, type, motion, and spacing are named values in one versioned file, so a design pass is held to a system the whole site shares, not to one worker's opinion. Below is the whole of it, one step at a time, with the record each step writes down.
the scary part
An AI designing by taste, with no system to hold it, is the scary part.
So nothing is designed fresh from opinion. The worker reads a written system first: every color, type size, and motion curve is a named token in a versioned file. The pass is built from those tokens, held to the written rules for contrast and copy, and reviewed by a separate set of eyes before it ships. One change to the system re-themes the whole site, because nothing hardcoded a value it was told to read.
every step · 01 → 07
One pass, seven governed steps.
This shows the pass as its core moments: claim, design to the tokens, held to the written rules, an outside review, the direction recorded. Open "show all seven steps" for the full run, or press play and pause on any step to read it.
- claim the passthe Skeleton
One owner at a time. The task state machine will not let two cells hold the same pass.
on the recordrepo.tasks · proposed → active · claimed_by, claimed_at
- gather referencesthe Nucleus
References come first. The build does not start on a blank guess; it starts from what is already on the record.
on the recordops.knowledge_base · references captured before any pixels
- read the written systemthe Genome
The system is written down and versioned. A worker reads the tokens; it does not pick fresh values per page.
on the recordgit · src/styles/theme.css · the versioned token source
- design to the tokensthe Bloodstream
Components reference tokens, so one change to the system re-themes every page, the light chapters included.
on the recordgit · commits that use tokens, never raw values
The rules are mechanical checks, not taste. A failing contrast pair or a stray em dash blocks it.
on the recordcontent-voice + WCAG AA · contrast and copy checked
The author never approves their own design. The reviewer is a different system.
on the recordgithub.pr_reviews · verdict recorded
- the direction landsthe Nucleus
The direction lives in the record with its rationale, not in a chat that scrolls away.
on the recordops.decisions · direction recorded with its rationale
the receipts
The system that themed this page is one versioned file.
The colors, type scale, and motion curves on every page here read from one token source. Change a token and the whole site re-themes, the light chapters included, with nothing hardcoded to drift out of sync. The palette, type, and motion below are those live tokens.
the palette
the type scale
- Governed
- Governed
- Governed
- Governed
the motion
Writing the code is the easy part.
The governed loop keeps going where most AI tools stop.
inside the factory
Most AI writes code. This runs the whole build.
The loops above are one part of a larger process, one that runs from the first idea through design and build to keeping the thing alive in production. Every phase is enforced by the system itself, so an autonomous worker cannot skip the parts that are boring and load-bearing. The choices teams usually make by accident in production, keeping test and live apart, deciding who owns what, deciding who can see which data, are forced early, where they are cheap to change.
- discoverywhat to build
- designhow it looks
- architecturehow it is builtcaught missingThe factory found this phase missing in its own record, and is now filling it.
- buildwrite the code
- environmentstest kept apart from live
- betaa few real users
- GAopen to everyone
- operatekeep it alive
the part that earns the trust
The factory found its own missing step.
One phase was missing: architecture, the step where the shape of a system gets decided before the first line of code. Nothing outside the factory pointed this out. The system read its own record, saw the gap, and is filling it. That is the proof the process improves itself.
Building a product is one kind of work this runs. Keeping a system healthy, carrying a piece of research, delivering an analysis, standing up operations: each has its own defined process, not one generic loop pointed at everything.
the rules run on every write
the steps most agents skip
Writing the code is the easy part.
Most agents stop at “it wrote code.” The governed loop keeps going, and the four steps it refuses to skip are the ones that make the output safe to land on your main branch.
an isolated worktree, with a lease
the governed loop: Every worker runs in its own checkout. Parallel workers never overwrite each other.
most AI tools: edit your files in place
an independent outside reviewer
the governed loop: A different model reviews the code (OpenAI’s Codex), not the one that wrote it.
most AI tools: let the model check its own work
a gate that can say no
the governed loop: A failed check blocks the merge. Green is earned, not assumed.
most AI tools: nothing blocks a bad change
a recap on every close
the governed loop: The next worker reads back what happened. Nothing is lost between sessions.
most AI tools: lose the context between runs
the receipts
This is the loop that built this site.
These are real, not illustrative: this page's build record from the platform database and GitHub as of Aug 6, 2026, the coordination ledger from that database on Aug 24, 2026, the authorship split from the platform git history.
this page
47
10
39
and across the platform
73%
done means verified
Nine verified records, one live change.
Nine steps in, the rail behind the cell is a column of nine verified records and one change is live. That is a company you own doing a day of work in the open, with a receipt for every step. The same governed loop runs research and design work too.
You just watched the whole loop run.
Every step wrote a record, and the records are public. See the records themselves, or bring us the work you want run this way.