The Fly-by-Wire System
Fly-by-Wire is a pre-execution evaluation layer in Kairos Substrate, the on-premise KAIROS deployment. The integrating system submits proposed actions and uses the returned verdicts to allow or block execution. The evaluation uses deterministic physics to assess structural stability.
The Aviation Analogy
Section titled “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. In a gating mode, the integrating system blocks actions that receive rejection verdicts before they execute.
Core Properties
Section titled “Core Properties”Three properties define Fly-by-Wire:
Pre-execution. The evaluation happens before the action executes. The integrating system must honor the verdict before allowing execution. The deployment policy controls enforcement and failure behavior.
Deterministic. The same inputs and evaluation context produce the same decision. Reproduction requires the same engine version, calibration artifact, policy, license context, and evaluation time. Stateful evaluation also requires the same session state. The gate uses no model inference in its decision path.
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
Section titled “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 | Returns the state or action verdict supported by the evaluation surface |
| 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
Section titled “Decision Modes”The deployment policy controls which gates are active. Its three mode values are observe, state_gate, and state_plus_action_gate.
Action previews require the stateful surface and a mapped proposed action.
Observe
Section titled “Observe”Observe reports the evaluation without enforcing state or action rejections. Those verdicts become PASS.
REJECT_LICENSE remains a rejection in Observe mode.
The stateful surface adds live telemetry, warning signals, and escalation context.
This mode is for monitoring, data collection, and calibration validation. Operators inspect the reported telemetry without enforcing state or action gates.
State Gate
Section titled “State Gate”The engine evaluates the metric snapshot and checks whether (structural stability) is at or above the configured floor. If it is, the action passes. If has fallen below the floor, the evaluation returns REJECT_STATE. The integrating system blocks the action.
State gating reports whether the system meets the policy’s structural stability floor.
State + Action Gate
Section titled “State + Action Gate”All state gate checks apply. The stateful surface also evaluates a mapped proposed action before execution, without advancing session time.
An action rejection can return REJECT_ACTION, REJECT_BASIN_COLLAPSE, or REJECT_PARADOX.
An unmapped action falls back to the state gate. Selecting this mode on the stateless surface also provides state gating only.
State + action gating reports both current stability and the mapped action’s preview verdict.
Other response decisions are REJECT_STALE_METRICS, REJECT_INVALID_SIGNATURE, REJECT_LICENSE, and ERROR.
The policy’s failure behavior and Observe mode affect which verdict appears. Inspect both decision and reasonCode.
When to Use Each Mode
Section titled “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 | Stateful pre-execution evaluation for mapped actions |
| Live monitoring dashboard | Observe | Real-time telemetry without enforcement |
| Calibration validation | Observe | Verify scaling functions against known-outcome scenarios |
Stateless vs. Stateful Evaluation
Section titled “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 action preview, live telemetry, and operator-facing escalation context. The stateless path returns evaluation details and can include escalation information, but has no live telemetry history.