The Iron Lung#

The ledger records. The memory witnesses preserve. The hardware-fault response thread halts. A fourth mechanism is what holds the whole system to a predictable cadence so that those commitments are observable in practice rather than only in theory.

What it does#

ANNIE’s control path — the loop that ingests intents, evaluates them against the safety logic, anchors decisions in the ledger, and dispatches approved actions — runs on a strict deterministic budget. Each iteration completes within a bounded interval. Iterations do not stretch under contention, do not pause for garbage collection, do not stall on memory allocation, and do not yield to lower-priority work on the host.

This discipline is not a single component — it is a property of the whole control path: every line of code on that path is required to allocate no heap memory, take no unbounded locks, perform no blocking I/O, and complete in a time provably below the budget.

The result is a control loop that completes each iteration at a bounded rate on supported platforms. For inputs within the documented operating envelope, the same input produces the same output in the same time. The discipline turns latency from a probability distribution into an engineering budget that can be checked at deployment time.

Why it matters#

Probabilistic latency is incompatible with bounded safety claims. A safety check that usually completes in five milliseconds but occasionally takes fifty is not a safety check — it is a race condition. Under adversarial load, an attacker can find inputs that push the safety check past its budget and create the window they need.

The bounded-latency discipline removes that variance. By engineering the entire control path to be allocation-free, lock-bounded, and scheduled above OS contention, the 99.99th percentile of decision latency converges toward the median on supported platforms.

This also lets us make bounded claims to customers. We do not say “ANNIE is fast.” We say “ANNIE’s control loop is measured against a documented budget, and deployments outside the required operating envelope should refuse to start.”

How you observe it#

Every release ships with a published budget for the control loop and the measured worst-case latency from the release’s benchmark run. These numbers are auditable — they appear in the release notes, and the test methodology is described.

At runtime, ANNIE exports control-loop timing as a Prometheus metric. Operators can graph the distribution and alert on excursions. An excursion that exceeds the published budget is itself logged to the ledger as a soft fault, with the responsible iteration identified.

Release notes and deployment monitoring expose the current budget and recent timing measurements.

What it costs#

Determinism has a price. The bounded-latency control loop is the reason ANNIE deployments require:

Specific kernel scheduling configuration on the host.
CPU isolation for the control-loop core.
A platform that supports memory locking.
Acceptance that the control path will not interleave gracefully with general-purpose workloads on the same machine.

These are documented in the install guide. They are not optional; deployments without them will not pass the self-check at startup.

What it does not do#

The bounded-latency control loop bounds the control path. It does not bound the underlying model’s inference time, which is a function of the model and the hardware, not of ANNIE. A slow model is still a slow model. ANNIE’s job is to ensure the safety decision about that model’s output happens on a predictable schedule, not to accelerate the model itself.

The Guillotine — the hardware-fault response that lives inside the Iron Lung’s budget.