Iron Interlock

The Story

There is a reason large language models are effectively banned from power plants, water treatment facilities, and chemical processing lines, and it is a good reason: nobody has had a way to bound what the model is allowed to do. Every “AI for industry” vendor stops at read-only dashboards, because the moment actuation appears, the only thing standing between the model and a destructive action is prompt quality — which regulators, insurers, and plant operators correctly treat as no barrier at all.

Iron Interlock inverts the problem. Instead of describing the safety envelope to the model and hoping it listens, the envelope is made physically unavailable to violate. Actuation exists only inside @CodeFunction methods whose bodies clamp, rate-limit, interlock, and verify every request before anything touches a controller. “What the AI may do” stops being a policy document and becomes a compile-time, JVM-enforced property.

The model proposes. The interlock disposes.

How It Is Built

The three authority zones map cleanly onto the plant:

• The deterministic zone is the safety envelope itself: pure Java @CodeFunction methods are the only path to actuation.
• The bounded AI zone runs on ModelTier.LOCAL — ONNX inference inside the JVM on the OT gateway. Zero bytes leave the network, which keeps the air gap (and the data-diode topology) intact.
• The elevated AI zone (CLOUD_ADVANCED) never touches live operations. It studies de-identified archives offline and writes playbooks for the local model — crossing the boundary as reviewed artifacts, not API responses.

public class CompressorStationAdvisor {

    @CodeFunction(description = "Clamp a requested setpoint change to "
            + "the certified rate-of-change envelope and the absolute "
            + "min/max for this asset.")
    public SetpointCommand clampSetpoint(String assetId, double requested) { /* … */ }

    @CodeFunction(description = "Verify interlock preconditions for a "
            + "valve transition: upstream pressure, permissive chain, "
            + "lockout/tagout registry.")
    public InterlockVerdict checkInterlocks(String valveId, ValveTarget target) { /* … */ }
}

@PromptOrchestrator(
        prompt = "Assist the control-room operator. Diagnose, propose, "
               + "and execute only through registered functions.",
        model = ModelTier.LOCAL,
        planMode = PlanMode.STATIC,
        planCacheStrategy = PlanCacheStrategy.INTENT,
        allowDynamic = false
)
public OperatorResponse assist(String operatorUtterance) { return null; }

Note allowDynamic = false. In most deployments that flag is an optimisation choice; here it is a governance statement. The tool surface is frozen at deploy time and enumerable in a single code review. PlanCacheStrategy.INTENT collapses an alarm flood into a handful of intent classes, and @SensitiveData keeps plant identifiers out of the audit trail — which, for the record, doubles as the flight recorder a safety case has always wanted.

Why It Is Unprecedented

Safety becomes a property of the architecture, not the prompt. A regulator does not have to evaluate the model's intentions; they evaluate a finite, frozen list of Java methods, each of which enforces its own physics. That is a safety case in a form engineers already know how to audit. Nobody has been able to offer that for an LLM in the loop of physical infrastructure before, because no other framework makes the boundary structural.

The Fine Print

Honesty corner. The local tier bounds linguistic sophistication — the design compensates with pre-digestion and compiled playbooks, not model heroics. This is decision support with governed micro-actuation; it does not replace the safety instrumented system. And the human review gate on playbooks is load-bearing: the architecture makes that gate cheap, not optional. Remove it and a safety case quietly turns back into a hope.