The guardrail enters the dynamics

Feedback begins when a system measures the consequence of its own action and changes the next action accordingly. That sounds obvious. Many AI guardrails do something weaker.

A content rule may reject a prompt. A permission check may deny a tool call. A schema validator may reject malformed output. These are useful mechanisms. They become feedback control only when their result is connected to a measured system state that matters over time. The distinction is causal, not terminological.

Suppose a guardrail checks every proposed refund against a per-transaction limit. It can prevent a £20,000 refund if the limit is £5,000. It does not, by itself, control unresolved daily exposure, customer retry pressure or the queue of partially executed refunds. Those variables evolve through the joint behaviour of model proposals, policy, tool latency, humans, external systems and previous guardrail interventions. A local check can be correct while the larger trajectory becomes worse.

The smallest useful control model

Control theory starts by declaring what changes. Let x_t be the system state at step t. In a refund workflow, it might include unresolved exposure, age of the oldest unverified effect, queue pressure and remaining authority. Let p_t be the model proposal, u_t the guardrail intervention, and w_t disturbances such as retries, tool failures or external demand. The state evolves through a plant, which is simply the part of the world whose behaviour matters:

y is the measured output, v measurement noise, τ total observation delay, r the intended operating reference and π_g the guardrail policy. The equation is useful only after each variable is tied to a real operational quantity.

A guardrail is open loop with respect to a variable when it acts without measuring how that variable changed. It may still use feedback about something else. A prompt classifier, for example, uses input evidence but usually does not observe whether denied users rephrase, route around the system or increase queue pressure. Control quality depends on the variable actually closed around, not on the existence of any feedback whatsoever.

Feedback is powerful because it can correct model error and disturbance. It is dangerous because the correction itself enters the plant. Åström and Murray’s treatment of feedback emphasises this duality: feedback can reduce sensitivity to uncertainty, but it also creates closed-loop dynamics that must be analysed for stability and robustness.[1] The practical translation is exact enough to be useful: every consequential guardrail needs an explicit state, measurement path, intervention path and timing model. Without them, there is nothing to stabilise in an engineering sense.

flowchart TD
  A["The guardrail that created a pulse"] --> B["The guardrail enters the dynamics"]
  B --> C["Two promises, return and never<br/>cross"]
  C --> D["Latency spends the safety margin"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#B96D00,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Two promises: return and never cross

A system can return to normal after wandering through an unacceptable state. Another can remain inside the boundary while never returning to useful operation. Stability and safety answer different questions.

Stability concerns how deviations evolve. Near an operating point, do errors shrink, remain bounded or grow? Safety concerns set membership. Does the trajectory remain within an admissible set? Control Lyapunov functions and control barrier functions formalise versions of these two promises for structured dynamical systems. Ames and colleagues showed how a real-time quadratic programme can combine a performance objective with inequalities that preserve a safe set.[2]

The distinction matters immediately for AI systems. A rate limiter may keep calls below an infrastructure limit while leaving a mission permanently stalled. A retry controller may restore throughput but briefly duplicate an irreversible action. A human escalation rule may prevent automated release but let the queue grow until reviewers rubber-stamp requests. A useful guardrail must name both the boundary it will not cross and the operating region it should recover towards.

From blockers to safety filters

Runtime enforcement research already distinguishes monitors by what they can do. A monitor may halt, suppress or insert actions, and those powers determine which policies it can enforce.[3] Safe reinforcement learning work makes a related distinction through shields that either constrain the action choices offered to a learner or correct an unsafe choice before execution.[4] Predictive safety filters go further by using current state, a model and uncertainty estimates to decide whether a proposed control input can be applied or must be modified.[5]

These results do not automatically make an enterprise agent safe. Their guarantees depend on explicit system models, state observability, constraint definitions and disturbance assumptions. The transfer is methodological: place an untrusted or performance-seeking proposal behind a smaller mechanism that has direct authority over the action and can reason about the next reachable states.

The control-eligible guardrail test

A runtime mechanism is control-eligible for a stated risk only when five conditions hold. It measures a variable causally related to that risk. It can change the future evolution of the variable. The change is verified through readback. The total loop delay is shorter than the available intervention horizon. A fallback can still recover when the preferred action becomes infeasible. Failing any condition does not make the mechanism useless. It changes the permissible claim.

Latency spends the safety margin

Delay, noise and drift look like separate operational problems. From the controller’s point of view, all three enlarge the gap between the estimated state and the state that will exist when correction takes effect.

Delay is more than model response time

The relevant delay begins when the evidence describing the world becomes true and ends when the corrective effect is independently observable. It includes event ingestion, retrieval, reasoning, policy evaluation, human review, tool queuing, external execution and readback. A fast model inside a slow workflow is a slow controller.

Delay matters because the plant continues to move. Recent control research on sampled-data and time-delay systems extends barrier-function methods precisely because a controller that is safe under immediate actuation can become unsafe when measurements or inputs arrive late.[8] Work on control barrier functionals represents delayed state histories rather than pretending the current sample is enough.[9] A 2026 input-delay formulation explicitly combines prediction, feasibility and robustness because delayed correction can arrive too late and demand an infeasible actuator response.[10]

Noise changes the safe buffer

Measurement noise includes more than random sensor error. A risk score can be noisy because two systems disagree about status, because a classifier’s confidence is poorly calibrated, because an effect receipt is eventually consistent or because a human label is ambiguous. If the controller treats the estimate as exact, it can chatter around a threshold. Hysteresis, filtering and state estimation can reduce switching, but each adds delay. The design problem is therefore not “remove noise” but choose how uncertainty changes the admissible set.

Input-to-state safety offers one useful pattern. Rather than claim the nominal safe set remains invariant under disturbance, the method relates disturbance magnitude to a larger bounded set around it.[11] For agentic systems, the direct theorem does not transfer. The design insight does: uncertainty should visibly tighten authority or enlarge the assumed risk tube. A stale readback should not leave the action limit unchanged.

Drift moves the plant while the controller stays tuned

Drift can enter through proposal distributions, customer behaviour, policy, tool semantics, external APIs, data pipelines or organisational workarounds. A guardrail trained on one distribution may still classify individual actions correctly while the sequence-level dynamics change. Drift detectors such as ADWIN adapt their evidence window when stream statistics change and can bound false detections under their assumptions.[12] Yet a drift detector is a sensor. It does not decide which authority to remove, which set to tighten or which fallback to enter.

This is where many monitoring programmes stop too early. They create a dashboard with alerts but no defined actuator. An alert that arrives during a high-load incident may merely add work to the same humans whose queue is causing the delay. Monitoring closes no risk loop until a defined response has enough authority and time to change the trajectory.

stateDiagram-v2
  [*] --> Claim
  state "Replace the model and keep the<br/>pulse" as Claim
  state "The smallest useful control model" as Test
  state "When more correction becomes<br/>less stable" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

From rule lists to control contracts

A guardrail inventory answers what rules exist. A control contract answers what they control, under which assumptions, how late they may act and what happens when those assumptions fail.

The proposed contribution is a guardrail control contract. It is not a universal safety proof. It is the smallest artefact that makes a runtime-control claim testable. Each contract binds one controlled risk to a state definition, estimator, safe set, intervention authority, delay budget, disturbance envelope, readback and fallback. Different risks require different contracts because the same action may be safe for privacy, unsafe for money movement and irrelevant to service continuity.

The contract also prevents three common substitutions. A model confidence score is not a state estimate unless calibrated against the controlled property. A tool acknowledgement is not an effect receipt. A human approval step is not a fallback controller unless the reviewer has sufficient time, information and authority to recover the trajectory.

type DurationMs = number;
type EvidenceRef = string;

type GuardrailControlContract = {
  controlledRisk: string;
  state: {
    variables: Array<{
      name: string;
      unit: string;
      authoritativeSource: EvidenceRef;
      maxAgeMs: DurationMs;
      uncertaintyBound: number;
    }>;
    safeSet: string;
    recoveryReference: string;
  };
  loop: {
    samplingPeriodMs: DurationMs;
    worstCaseDelayMs: DurationMs;
    interventionHorizonMs: DurationMs;
    estimator: string;
    independentReadback: EvidenceRef;
  };
  authority: {
    allowedInterventions: string[];
    maximumVerifiedCorrectionPerStep: number;
    saturationResponse: "reduce-authority" | "safe-mode" | "halt";
  };
  uncertainty: {
    credibleDisturbances: string[];
    driftSignals: string[];
    constraintTighteningRule: string;
  };
  fallback: {
    entryCondition: string;
    verifiedRecoveryAction: string;
    exitEvidence: EvidenceRef[];
  };
  releaseTests: string[];
  prohibitedClaims: string[];
};

The schema exposes assumptions that prose often hides. A field left blank is not a documentation defect. It is a limit on the authority the system may receive.

The stability envelope

The contract should be accompanied by a tested envelope over gain, delay, uncertainty, drift and actuator authority. Inside the envelope, the configured system remains within declared bounds under the specified disturbances. Outside it, the system must reduce authority or enter fallback. This is analogous to an operating envelope in control engineering, but the variables may be business and information states rather than physical position and velocity.

A useful test programme changes one causal property at a time. Apply a step increase in hazardous proposal rate. Sweep end-to-end delay. Add measurement noise and stale evidence. Ramp drift after the controller settles. Saturate the actuator. Corrupt one readback path. Remove the safe fallback. Record maximum boundary excursion, settling time, intervention rate, time in fallback and any unknown outcomes. Failure injection is not a late resilience exercise here. It is how the envelope is discovered.

An executable control bench

The laboratory below simulates a synthetic risk state. An agent proposal stream adds risk. A threshold blocker applies a fixed correction after a delayed measurement crosses a threshold. A feedback governor applies proportional and integral correction, then invokes a simple one-step safety intervention and safe mode when the predicted state approaches the boundary. Both controllers see the same disturbance.

The model is deliberately small enough to inspect. It encodes inertia, delayed noisy observation, drift and actuator saturation. It does not encode language, policy semantics, strategic users or real monetary effects. A positive result permits only this claim: the selected configuration remained bounded in this synthetic disturbance family. A negative result is more informative. It shows that even the simplified dynamics defeat the proposed timing, gain or authority.

How to apply the bench to a real system

Start with a configured operational twin, not the live system. Replace the synthetic state with typed variables derived from authoritative sources. Replace the proposal stream with recorded or generated actions that cover normal, edge and adversarial demand. Implement the actual policy engine, tool latency distribution, retry semantics, state estimator and readback. Use synthetic customer data unless real data is authorised.

Run the same scenario across parameter sweeps and random seeds. A positive result should produce a bounded region, not a single successful trace. A negative result should identify the failure mode: late detection, gain-induced oscillation, estimator bias, actuator saturation, safe-mode failure or a broken measurement bridge. Then change the architecture, rather than only the prompt.

The strongest alternative explanation is that many agent workflows are not well represented by low-dimensional smooth dynamics. They contain discrete permissions, strategic actors, semantic shifts and one-off irreversible actions. That objection is correct. The control contract should not force a false differential equation onto them. It should still demand the same causal facts: what state changes, how it is observed, what intervention can change it, how long that takes and where recovery becomes impossible.