Risk invariants and execution safety in live 0DTE systems

Safety outranks correctness, which outranks profit. The live 0DTE systems encode that as hard invariants — single position, long-only, daily hard stops, forced EOD flatten — enforced by state machines and schema-level tests rather than comments, with production incidents converted into permanent regression tests.

The invariants, as written

The live systems share a priority order — safety > correctness > profit — and encode it as configuration-level invariants, verbatim from the configs:

Enforcement is structural, not documentary: a four-state execution state machine whose can_enter() is only true from FLAT; a risk kernel that returns allowed + reason so a refused entry carries its own audit trail; and schema-level data tests (SPX bars must not have a volume column — which catches wrong-instrument joins at load time) inside a 300+ test suite.

Three production bugs, three permanent tests

All three were found in live or paper sessions, none by the original unit tests — and each now exists as a named regression test that will fail loudly if the behavior regresses.

The lesson

An invariant that lives in a comment is a wish. The ones that hold in production are the ones a state machine, a type, or a test can refuse — and the cheapest time to add the next one is the same afternoon an incident shows you where it was missing.