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.
- 01captureWhere the work comes in.
- 02routeWhere it goes, by the company’s own rules.
- 03sign-offWhere a person decides.
- 04one recordWhere its history is kept.
- 05visibilityWhat is moving and what is stuck.
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.
- 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.
See how it would map to your company.
The first conversation is with the people who would build it. If there is a fit, the Consult comes next.