OctoView LabsThe life of a change
Abstractions are easy to admire and hard to trust. Here is what actually happens when a piece of work moves through Topos, step by step. Every step below is a recorded fact in the ledger, which means every step can be shown to someone else, later, without asking anyone to remember.
1. It begins as an intent
Nothing substantive starts as a commit. It starts as a registered intent: a plain-language statement of what is being attempted, why, and which parts of the system it is allowed to touch. The blast radius is declared up front and enforced as a lock; two pieces of work that would touch the same files serialize instead of colliding. An intent is the unit the operator governs. Work without one is a finding, not a feature.
2. The design is attacked before it is built
The design an agent produces does not go to a person first. It goes to adversarial review: separate reviewers whose instruction is to break it, and an external architect that rules on it. Designs fail here regularly, and that is the point. In one recorded case five independent reviewers voted three to two to reject a mechanism the building agent was proud of. The rejection is in the ledger and the mechanism stayed out of the codebase.
3. A named human opens the gate
The design that survives review reaches the operator as a short brief in plain sentences. Approval is a signed policy act by a named person, recorded durably. The machine cannot open this gate for itself, and the configuration that defines the gates is locked against the agents that work under them. This is the moment accountability attaches, and the record shows exactly when and to whom.
4. The work decomposes, under a budget
Approved work may split into children, and each child is governed like its parent: its own phase, its own record, its own gate where one is required. Decomposition is bounded so that planning cannot become an end in itself; a task must eventually build or come back and say so. The graph below is a real family from the live ledger.
5. The result must prove itself
The agent that built the change does not certify it. A separate verifier re-derives the result, and the completion claim must carry evidence: a content hash anchoring what was produced, tests that demonstrably fail when the change is broken, and for hardened work, mutation probes showing the tests can bite. A claim that cannot prove what it asserts is refused at the ingest boundary, and the refusal itself is recorded. On a busy day the system refuses over a hundred such claims. Those refusals are the immune system working, and they stay on the record.
6. A person walks the change before it lands
Nothing merges on machine consensus alone. The operator dissects the change with the evidence in front of them before it reaches the main line, and pushes carry sign-off. Slower than auto-merge, and deliberately so: the human is the constitutional layer, and this is where the constitution meets the code.
7. The record outlives everyone's memory
After the change lands, the story of it does not live in anyone's head or in a chat scrollback. It lives in the ledger: the intent, the rejected first design, the signature, the children, the verdict, the refusals along the way. Months later, the question "who authorised this, what verified it, what evidence do you hold" is answered by replay, not archaeology.
What this feels like in practice
Bruising, some days. Work gets refused. Designs die in review. The operator signs more than a rubber-stamp culture would ask. We run our own development this way, all of it, and we publish the uncomfortable parts. The trade is simple: a slower yes that stands up to scrutiny, instead of a fast yes that dissolves under the first hard question.