What it records
Which stage, which actor, which model, how many tokens, when, and whether it passed or failed. Enough to reconstruct exactly what the system did and prove it later.
The build · reason codes, traces, receipts
Inside the build.
The front page describes the flow. This page is what it actually does. The reason codes that route every exception, the trace of a single record, the shape of a receipt, and a script that breaks the whole thing on purpose so you can watch it fail properly.
01 · Run it
Three commands. No key, no network, no cost.
It runs offline in under a second, which was a deliberate choice. A demo that depends on an API key and a live model is a demo that fails in the room.
$ python flow.py # full run, one record traced, KPI table $ pytest test_flow.py -v # 20 tests $ python break_it.py # break it deliberately, three ways .................... [100%] 20 passed in 0.13s
02 · The reason codes
Every exception carries a code, and every code is counted.
Not a message somebody has to interpret. A constant that routes the record and can be tallied, so the exception volume is a number rather than an impression.
| Code | What it means |
|---|---|
| CURRENT_MEMBER | The record belongs to an active paying member. Outreach to a member is the failure this whole rule set exists to prevent. |
| MISSING_JOIN_KEY | There is no matchable identity, so membership can never be checked. The rule cannot run, so it fails closed rather than open. |
| Code | What it means |
|---|---|
| FORMER_MEMBER | Appears in the member history. It may have been a good exit or a bad one. A person decides, and their name is recorded. |
| EXCLUDED_STATUS | The recorded status is not sendable as it stands. |
| DUPLICATE_CONTACT | Already contacted within this campaign. |
The asymmetry is the design. The machine holds the line on the things that cannot be undone, and it does not get a vote on the things that need judgement. A test asserts that a hard block cannot be approved even when a signature is sitting in the approvals file, because that rule is the one most likely to be quietly weakened to make a demo run more smoothly.
03 · The trace
One record, every stage, in order.
This is what you read out when somebody asks you to trace a record. Every line is a receipt entry, written by the stage that did the work.
TRACE ONE RECORD END TO END source system arrived validate system flagged:EXCLUDED_STATUS,FORMER_MEMBER agent agent:template drafted human_gate REVIEWER (recorded) approved action system held:DAILY_CAP --> stopped at the gate. Nothing was sent on this record.
Read that again. The record was flagged twice, drafted, approved by a person, and then still did not go, because the daily send cap had been reached. Four separate controls acted on one record and the trace shows every one of them. That is the difference between a pipeline and a script.
04 · The receipt
What a receipt holds, and what it deliberately does not.
An audit trail that cannot detect editing is decoration. This one is hash chained, and it holds no content at all, which is a privacy decision rather than an oversight.
{
"ts": "2026-10-07T12:57:41+00:00",
"stage": "source",
"record": "LEAD-001",
"actor": "system",
"model": null,
"tokens": 0,
"outcome": "arrived",
"request_id": "9ddcb8c82e41dcb0",
"prev": "GENESIS",
"hash": "bf1c7725182a8acd95eb646b10e2a956..."
}
What it never records
The content. Not the drafted message, not the customer's data. The log proves the work happened without becoming a second copy of the thing you were trying to protect.
05 · Break it
A pipeline you cannot break on stage is a demo.
So there is a script that breaks it three ways, and each one is a question an interviewer asks. Here is what it prints.
BREAK 1 - put a CURRENT MEMBER into the outreach pool join key 0002563d... (an active, paying member) route NEEDS_HUMAN reason codes ['CURRENT_MEMBER'] hard blocked True Now try to overrule it with a human signature: approved? False (approved by SYSTEM) RESULT: blocked. The reviewer had already marked this record "Can send", and the pipeline still refused. BREAK 2 - edit an entry in the audit log after the fact chain before tampering intact=True entries=3 chain after tampering intact=False entries=1 RESULT: the chain breaks at the edited entry. BREAK 3 - the upstream system stops sending a field the rules need join key (blank) reason codes ['MISSING_JOIN_KEY'] hard blocked True RESULT: hard blocked, loudly, with a reason code. If a missing field were treated as "probably fine", the rule would silently stop protecting anyone and nothing would error.
Break three is the one that matters. Nothing crashes. The pipeline completes. A validation rule that cannot run has quietly stopped protecting anybody, and the only defence is to make it fail closed. That is the kind of defect that never shows up in a happy path demo, and it is the reason I build the failure case first.
06 · On the figures
Why there are no client numbers on this page.
The pipeline runs against real, reviewed campaign data, and the full measured run exists. The figures are not published here, and the reason is worth stating rather than leaving as a gap.
That data belongs to a client, it is anonymised and held under legal hold, and it is their commercial information rather than mine to publish. So the site shows the mechanism, which is my work and is safe to publish, and the measured run is available to a prospective employer or client on request and under a plain agreement. I would rather explain that honestly than pad a page with numbers I should not be quoting.
Want to see the measured run?
Ask, and I will walk you through a single record end to end and show where each control fires. That takes about ten minutes and it is more useful than any page of claims.