Not a chatbot that writes code. A shop where the words are load-bearing: what you said is screened, rewritten through a vocabulary that has been ratified and measured, and compiled into a bounded instruction. Only then does a model see anything, and what comes back is admitted or refused before it touches a file.
Here is the whole of it, in four steps, from a sentence somebody typed badly to work a program can check.
Every screenshot below is this system running. So is every product named further down — and so is this page, rendered by a program in the same workspace it describes.
1Type it the way you would say it, typos and all. What comes back is a user story and acceptance criteria you can argue with. The models on offer include ones that run on your own machine, and the sentence you actually wrote is kept beside the rewritten one.
2It asks, in plain words, until the shape is complete. Each answer adds one strand to the canvas, and the last question is always the one about why — a chain that produces a file but cannot say what it is for does not get to close.
3The conversation becomes a sprint with criteria that are rows, not prose. Each one starts UNSATISFIED and has to be satisfied by something nameable. Nothing is approved until a person clicks approve.
4The drawings are rendered from the requirement rows, so they cannot drift from what was agreed. The page names its own open questions rather than smoothing them over — what is still undecided is written down as undecided.
What makes it different
The boundary in the middle of those four steps is the product. It is called imp — the part that stands between a person's language and a machine's, and keeps a record of both. A model proposes. imp admits. The model never writes.
A vocabulary the machine enforces. Most tools ship a rules file and hope. Here the words are rows in a database, ratified one at a time, compiled into commit-time hooks that refuse. 252 terms are ratified today. Every run records which version of the vocabulary it was working under, because a name is a fact the model treats as true, and a misleading name is not missing information — it is misinformation.
Disclosure decides the model. A document is broken into structural pieces on your own machine before anything leaves it. What may cross the boundary decides which model is allowed to answer — local and private, or hosted. Every run stores the hash of exactly what the model was shown, so prove nothing privileged left this building is a query, not an assurance.
The cost runs the other way. A tool priced by effort earns more when you consume more of it. This one is built on the opposite rule: anything that repeats stops being a prompt and becomes a tested program. The machine is asked once per genuinely new problem, and the answer is compiled so no future run pays for it again.
What it is made of
Not a demo. A working library, built and tested over years, that the machine assembles into products.
445registered crates
865,878lines of Rust
12,866tests
252ratified terms
Every one of those numbers was measured on 2026-09-18 with a command recorded alongside it. See what they count.
Why an imp
Because the BSD daemon has been sitting on the corner of a manual page for forty years reminding everyone that the thing doing the work in the background is small, horned, and not especially sorry. An imp is a familiar: it does what it is told, inside a boundary somebody drew. That is the whole design, and it is why the mascot came before the marketing.
