The machine: an array of feed heads aimed at one lock gate and store, a clock ring with every scheduled job around it, banks of rule gates, explainer lanes and checks, and a record strip running underneath.

Many moving parts. One clock.

Not an illustration. This is the real system, part for part and line for line. Only the names are taken off.

A private system I built, for work where a confident guess costs real money. Live feeds land in one store, every scheduled job wakes on one clock, rules decide in code, and language models only put results into words. What it's for stays private. This page is how it's built.

// one to one

Every part is real. Every line is real.

parta part the system really runs
linea connection it really has
pulsemoves only along real lines, on the real rhythms, sped up

Built from the system's own component graph, not drawn to look like one. Parts that are switched off aren't drawn. It isn't a live feed: it's the real structure, with the names taken off.

// feeds

Every feed is named.

Each feed keeps its own rhythm and its own name, so one that goes quiet gets called out instead of averaged away.

// store

Many writers, one lock.

Several processes write to the main store. A lock lets them in one at a time, so a write lands whole or waits its turn.

// clock

One clock. Every wake-up answers.

Every scheduled job wakes on the same clock, and each wake-up ends in a written outcome, including the ones that were refused, paused or crashed.

// rule gates

Rules are code. Every branch is kept.

A gate splits the flow, and every branch carries on to the record: what passed, what was refused, and what couldn't be told either way.

// explainers

Language models write words. Nothing else.

The explainer lanes turn stored results into sentences and have no path to the gates. Steps that don't need each other run side by side, and a step whose input failed is skipped, on the record.

// checks

Every sentence is checked.

Digits, vocabulary, traceability, citations, grounding. A sentence that fails is dropped, and output that can't pass is replaced by a plain version written by code.

// record

The record only grows.

Outcomes go in as new rows and are never rewritten, including the ones nobody can confirm.

// delivery

Reserved before it's sent.

The reservation is what stops a second copy. Delivered means the channel accepted it, not that anyone read it.

// all of it

All of it, at once.

The whole system on one screen, one to one: every part a real part, every line a real connection, every pulse on a real path. A health watch reads it from outside, and each night's backup is restored on a scratch copy before it's trusted.

Point at any part, or tap it, to see what it is and what it connects to.

Follow one reading in.

Through the lock, into the store, past the clock.

Into the record, where it stays.

// break it on purpose

Break it on purpose.

These are failures it was built for. Each button replays, in this model, what the real system does.

Pick one. What the real system does shows here.

The silent feed is named, even though coverage still reads full. The hole it leaves is marked unknown, not filled in.

The collectors run on their own and keep writing. The main process comes back, restores what was pending, starts the clock, then reads what the collectors gathered from where it left off. Nothing lost, nothing doubled.

Nobody can say whether it arrived, so the record says unknown. It is not retried: a retry could turn a possible miss into a likely duplicate.

// the rule underneath

It can't tell you what it doesn't know.

In a system where a confident guess is the worst possible answer, everything that has to be exactly right is decided by code: hard values, yes or no, nothing in between. The same input always gives the same answer, so any past run can be replayed and checked.

Language models are used only to put a stored result into words, and those words are checked before anyone reads them. A thing either happened or it didn't, and anything less than certain is named as exactly that. That doesn't make it infallible. It makes it unable to bluff.

code decides

yes or no, on the record

no path from here to a decision

a model explains

checked words go out; a sentence that fails is dropped

Two lanes. Everything that has to be exactly right travels the top one, through gates written in code. A language model works in the bottom one, putting results into words: here one sentence fails its check and drops into the tray, and the rest go out.

Rendered for this page, then animated from the render: an unbranded box standing in for the small computer it all runs on.

// what it proves

What it proves about how I build

It works or it doesn't. Nothing here is patched up or polished to look like it works. There's no show to put on: a part does its job, or it's broken and gets fixed.
Every moving part gets picked apart. Down to the smallest detail. A part is called good only when there is nothing left on it to pick at.
Failure is planned for before it happens. Nothing new goes live until its edge cases have been tried and every failure point I can find is handled as if it will happen, so it's stopped before it can break anything.
Going live is a procedure, not a push. A backup first. The moving parts shut down gracefully, in order. The new code goes in, everything starts again in order, and each part is spot-checked. If a step fails, it stops there: nothing restarts half-updated, and the backup taken first is ready to restore. The problem is fixed, and then it goes again.

If your business runs on a process with this many moving parts, and nobody can say for certain what it did overnight, that's the kind of system I build.

Tell me about yours