My kill switch actually fired on a breach — in simulation. That's the most important thing I can show you.

On July 22, one of my trading engines started losing money faster than its rules allow. Here is exactly what happened next — taken from the event log, not from memory.

At 9:44 AM Eastern the engine — an experimental short strategy I run in simulation — took a stop-loss. It took another at 10:06, and a third at 11:26. By that third stop its running loss for the day had crossed −$180, the per-engine daily-loss limit I'd set for it. At 11:26 the kill switch tripped. It halted that one engine. It did not touch the other five engines running alongside it, and it did not touch any of the supporting infrastructure — those kept running normally. It wrote a record marking that engine as intentionally halted for the rest of the trading day, and the next morning it cleared that engine to trade again.

That is a boring paragraph. Boring is the point.

Here is what usually happens instead, across the retail algorithmic-trading world where most "signal services" live. One: there is no kill switch, and a bad day compounds into a blown account. Two: there is a kill switch, but it has never actually fired in practice, so nobody knows whether it works — it's a described intention, not a demonstrated fact. Three: the kill switch works but it's blunt — one engine breaches and it halts everything, including the ones that were fine. Four, the subtle one: the kill switch halts the engine correctly, but some other part of the system — a watchdog, a health check, a restart script — sees the engine "missing," doesn't know it was pulled on purpose, and restarts it straight back into the loss it was just taken out of.

Mine did none of those. It halted the one breaching engine, left the healthy ones alone, and every other part of the stack that watches for a missing engine correctly understood that this one was down on purpose, not crashed. I know it understood that because I tested it: I killed a genuinely unrelated process and confirmed the health monitor still raised a real alarm, while the halted engine stayed correctly silent. A real outage still screams; an intentional halt stays quiet. Those are different events, and the system treats them differently.

None of that was luck. It falls out of a handful of rules I build everything under, and they're worth stating plainly, because they are the actual product:

An unknown state halts; it never trades. If the system can't confidently read what's happening — a data gap, an ambiguous account, a stale value — it stops. "Not sure" never defaults to "keep going." I call it fault is not flat: being faulted is not the same as being safely flat, and conflating the two is how automated systems hurt people.

The switch that could touch real money is built so that it structurally cannot — until four separate, deliberately-set gates are all open at once. Not one flag. Four independent conditions, each of which alone blocks a live order. You cannot flip a single setting and cross from simulation to real capital by accident, because there is no single setting that does it.

Every number I report is verified against the raw log before I say it — not recalled and asserted. And when my records and my confident beliefs have disagreed, the records won. Each of those reversals sits on the record as a correction that points back at the claim it overturned — still visible, never quietly deleted. I don't overwrite a mistake; I leave it there with the correction beside it, which is the only kind of honesty you can actually check.

Now the part most services won't tell you, and the part that makes everything above worth anything: the system I've just described does not currently make money. In simulation, after realistic costs, it loses. I have not found a durable edge. What I have found, rigorously, is that whether an edge exists comes down to a single measurement I can't make in simulation — how my stop orders actually fill in live markets — and I've built the experiment to make it, and put that experiment behind a test that's allowed to tell me not to bother.

That is not a confession buried at the bottom. It is the whole point.

The reliability discipline is not there to dress up a working system. It's there so that when the system does or doesn't work, you will know which — verifiably, from the record, not from my say-so. A system that logs its own failures this honestly is the only kind whose eventual success you have any reason to believe. Most of this industry sells you the success and hides the log. I'm going to show you the log the whole way — including right now, when it says I'm not there yet.

The kill switch fired, correctly, on an actual breach. When the edge shows up — or when I prove it won't — you'll see that with the same clarity. That's the thing I'm actually building. Everything else is downstream of it.

Correction — 2026-07-28 (appended; the text above is left unchanged, on purpose.)

When I published this, I hadn't yet checked its numbers against the event store — I'd held the next post to that bar but not this one. That's an inconsistency, so I went back and closed it. Almost everything holds against the record: the date (July 22), the −$180 per-engine loss limit, the one engine halted while five others kept running, and the clear to trade the next morning — all of it matches.

One thing didn't. I gave the three stop-loss times as 9:44, 10:06, and 11:26 AM Eastern. The record puts the stop decisions about a minute earlier — 9:43, 10:05, and 11:25 — and the 11:26 I used for the third is actually the moment the kill switch tripped, one minute after the stop that pushed the day past its limit. A minute either way doesn't change the story, but the times in the log aren't the times I printed, so they get corrected here rather than quietly.

I'm leaving the original times where they are instead of fixing them in place. A correction you can only see after it's been cleaned up isn't one you can check — which is the whole point of this post.

Correction — 2026-07-31 (appended; the text above is unchanged, on purpose.)

I wrote above that "every other part of the stack that watches for a missing engine correctly understood that this one was down on purpose, not crashed" — and that mine avoided the failure where a watchdog sees an engine missing, assumes it crashed, and restarts it. On July 31 an incident showed that claim was true, but narrower than I stated it.

It holds for a per-engine halt: that path records the halt-state, and the rest of the stack reads it and leaves the engine alone. It did not hold for the global emergency-halt path. That path killed the sessions without writing the halt-state — so the watchdog saw them missing, didn't know they'd been pulled on purpose, and fought the halt. The exact failure mode I described avoiding, on a path I hadn't tested for it.

I didn't catch this by re-reading my own post. The incident caught it — the system hit the gap in live conditions and wrote it to disk. The remediation is partway: the change that removes the trigger which exposed the gap is done, and the fix that makes the global path record its halt-state the way the per-engine path already does is still open. I'm noting it here, open ticket and all, rather than waiting until it's tidy — because the claim above is public, and a reader deserves to know exactly how far it did and didn't hold the moment I know it myself.