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 deterministic simulation of growth pressure and structural stability. Safety is assessed from the system state, not from model confidence or natural-language prediction.

System Components

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

Stage	Component	Role
Translation	Metric adapter	Converts domain metrics into evaluation inputs
Simulation	Engine	Evaluates the current system state
Gating	Policy gate	Evaluates state and proposed action against safety thresholds
Narration	Sentinel	Translates engine telemetry into human-readable assessments
Review	Operator workflow	Routes critical rejections for human review when configured

Each stage has a single responsibility, which keeps integration behavior predictable and auditable without exposing enforcement implementation details.

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, pre-production 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 handles each request independently. There is no carried state or history. Use this for request/response architectures where you need a pass/fail gate on a metric snapshot.

Stateful evaluation maintains state across evaluations and produces live telemetry. Use this for continuous control loops where you need action gating, monitoring, and escalation directives.

The stateful path adds capabilities the stateless path cannot provide: action preview, telemetry, and operator-facing escalation context.