The Fly-by-Wire System

Fly-by-Wire is a pre-execution safety layer. Every action an autonomous agent proposes passes through Fly-by-Wire before it reaches the outside world. The system evaluates whether that action is safe, using deterministic physics — and blocks it if the answer is no.

The Aviation Analogy

In aviation, fly-by-wire replaces the mechanical linkage between a pilot’s control stick and the aircraft’s control surfaces with a computer. The pilot still commands intent, but the computer enforces the flight envelope. Pull back too hard and the computer limits the pitch to prevent a stall. Bank too steeply and the computer reduces the roll angle. The pilot flies; the computer keeps the aircraft inside the physics of safe flight.

KAIROS Fly-by-Wire does the same thing for autonomous agents. The agent proposes actions; the system evaluates them against a physics simulation that models structural stability. Actions that would push the system toward collapse are intercepted before they execute.

Core Properties

Three properties define Fly-by-Wire and distinguish it from probabilistic safety approaches:

Pre-execution. The evaluation happens before the action executes. There is no rollback, no post-hoc audit, no “we’ll catch it next time.” The gate is closed until the physics say it is safe to open.

Deterministic. The same inputs always produce the same decision. There is no sampling, no stochastic threshold, no model inference in the critical path. Given identical metrics and policy, every evaluation is reproducible.

Physics-based. The evaluation runs on a simulation engine grounded in the Stability Equation — a mathematical relationship between growth pressure ($\Lambda$) and structural stability ($\Gamma$). Safety is a property of the system’s physics, not a prediction about its behavior.

System Components

A Fly-by-Wire evaluation moves through five stages:

Stage	Component	Role
Translation	Rosetta	Converts domain metrics into simulation parameters ($\Lambda$, $\Gamma$)
Simulation	Engine	Advances the physics simulation one tick with the translated parameters
Gating	Gate Chain	Evaluates the simulation state and proposed action against safety thresholds
Narration	Sentinel	Translates engine telemetry into human-readable assessments
Override	Human-in-the-Loop	Allows credentialed operators to authorize specific rejected actions

Each stage has a single responsibility. Rosetta knows nothing about gating. The gate chain knows nothing about narration. Sentinel knows nothing about overrides. This separation means each component can be tested, audited, and reasoned about independently.

Decision Modes

The deployment policy controls which gates are active. Three modes are available, each adding a layer of enforcement:

Observe

The engine evaluates every metric snapshot and produces the full telemetry output — stability values, warning signals, escalation directives — but never rejects. Every decision is PASS. This mode is for monitoring, data collection, and calibration validation. Operators see everything the engine sees, without affecting agent behavior.

State Gate

The engine evaluates the metric snapshot and checks whether $\Gamma$ (structural stability) is above the configured floor. If it is, the action passes. If $\Gamma$ has fallen below the floor, the evaluation returns REJECT_STATE and the action is blocked.

State gating answers a single question: is the system structurally stable right now?

State + Action Gate

All state gate checks apply. Additionally, the engine previews the proposed action by simulating its effect on the physics — without advancing real time. If the preview shows the action would push the system toward instability, the evaluation returns REJECT_ACTION.

State + action gating answers two questions: is the system stable, and would this specific action keep it stable?

When to Use Each Mode

Scenario	Mode	Why
Initial deployment, data collection	Observe	Build confidence in calibration without blocking agents
Production API gateway, CI/CD policy check	State Gate	Enforce stability floor with minimal overhead
Autonomous agent control loop	State + Action Gate	Full pre-execution safety with action-level granularity
Live monitoring dashboard	Observe	Real-time telemetry without enforcement
Calibration validation	Observe	Verify scaling functions against known-outcome scenarios

Stateless vs. Stateful Evaluation

Fly-by-Wire provides two evaluation surfaces:

Stateless evaluation (SubstrateRuntime) handles each request independently. There is no engine state, no tick counter, no history. Each call maps metrics, checks the gamma floor, and returns a decision. Use this for request/response architectures where you need a pass/fail gate on a metric snapshot.

Stateful evaluation (SubstrateSession) wraps a live simulation engine. The engine maintains state across evaluations — it ticks forward, accumulates history, and produces telemetry including warning signals, reachability analysis, and projection previews. Use this for continuous control loops where you need action gating, hazard detection, and escalation directives.

The session path adds three capabilities the stateless path cannot provide: action preview gating, hazard detection (basin collapse and paradox), and adaptive tracking for retry management.