# How a system is built, and kept right.

Every system is drawn before it is built, measured against a baseline before anyone relies on it, and kept current after launch. People decide wherever the company says they should. Below are the rules behind that, including the ones that exist because something broke.

## Drawn before it is built

Every system starts as a drawing: the stages the work passes through, where it reads from and writes back to, where a person decides, and one line saying what the system never does on its own. The drawing is agreed in the Consult, before any part is built, and it stays the reference. A change to the system is a change to the drawing first.

- **capture**: Where the work comes in.
- **route**: Where it goes, by the company's own rules.
- **sign-off**: Where a person decides.
- **one record**: Where its history is kept.
- **visibility**: What is moving and what is stuck.

Boundary: It never closes a step the company has marked for a person.

## The interlock

Every system has a line it cannot cross, drawn in the Consult. Sometimes the line is a person. Sometimes it is a rule: a sender with no model in it, a view that only reads, one state per thread.

Where the line is a person, the drawing carries one sign: the interlock. There, the system prepares the work, puts it in front of the right person, and waits. It chases what is waiting. It never closes the step itself.

Which steps carry the interlock is the company's call, made in the Consult and changed whenever it wants: anything sent in its name, anything that spends money, anything a person should see first.

## The baseline comes first

Before anything is built, the Consult measures how the work runs today: how long it takes, where it stalls, where it goes wrong. That is the baseline, and the system is judged against it.

Each part is tested against a fixed set of cases with known right answers before it goes live, and it goes live only when it does better than the baseline on the measures agreed in the Consult. The same measures keep being read after launch.

## Running it is part of the work

The services under a system change, the models move, and the company changes: a new product, a new market, a new rule. Each change is a re-set. The drawing is updated, the tests run again against the baseline, and the system goes back into service.

The loop from a change to a system running again used to take months. It takes days now, which is why staying to run it is worth it.

## Told against ourselves

Each of these rules came from a failure in a system OCTYN runs. The first one is the one that cost the most.

- **A bounce rate circuit breaker stopped a campaign, as it should have. Nobody noticed for three days. (2026-09-11)**: Every system writes to one ledger, and a tripped worker is a first class state in the morning brief.
- **A send worker with a model inside it errored, sent the wrong mail, then reported a send that had not happened.**: Nothing with judgement in it is allowed near a send. A small deterministic service polls, marks each job as it goes, and confirms every send.
- **Two cascading deletes silently removed records that had been expensive to collect.**: Both became restrict. A delete that would lose data is blocked, and says what it is blocking.
- **A model asked to make the same call twice gave two different answers.**: Gates are typed functions with tests beside them, so the same input decides the same way every time.
- **A model can return text that was never in what it read, an email address included.**: Nothing a model returns is trusted unless the text is literally present in the page it was given.

## What is yours

Your data, specs, configuration and system code. OCTYN's general tooling and methods stay OCTYN's. The documentation to run the system yourself comes with it, so taking it over is always an option.

## Related

- [The Consult](https://octyn.co/consult)
- [The three families](https://octyn.co/systems)
- [Who builds it](https://octyn.co/firm)

Canonical: https://octyn.co/method