Deployment Overview

Fly-by-Wire is deployed through the kairos CLI, configured through JSON policy files, and controlled through compile-time feature flags. This page covers the operational surface — what you configure, what you run, and what you enable.

CLI at a Glance

The kairos CLI is the primary interface to the Substrate stack. Five commands are directly relevant to Fly-by-Wire operation:

Command	Purpose
kairos evaluate	Run a single evaluation against a calibration artifact and deployment policy
kairos observe	Launch the live TUI dashboard with real-time telemetry, Sentinel, and HITL
kairos trace	Replay and inspect historical evaluation traces
kairos policy	Validate and inspect deployment policies
kairos hitl	Manage HITL override requests (serve, list, approve, deny)

evaluate is the core command for integration: it takes a calibration artifact, a deployment policy, a license key, and an evaluation request, and returns a decision. All other commands support operational workflows around that core.

For the full CLI reference, see the CLI Reference section.

The Deployment Policy

The deployment policy is the central configuration file for Fly-by-Wire enforcement. It defines what the system enforces, how strictly it enforces it, and who can override rejections.

A deployment policy specifies:

• Gamma floor — the minimum $\Gamma$ threshold. Evaluations where $\Gamma$ drops below this floor produce REJECT_STATE.
• Enforcement mode — observe, state_gate, or state_plus_action_gate. This controls which gates are active.
• Metric staleness window — the maximum age of a metric snapshot before it is rejected as stale.
• Fail behavior — fail_closed (reject on errors) or fail_open (allow on errors, when the base policy permits).
• HITL authorities — the operator identities and public keys authorized to sign override tokens, and the maximum token TTL.
• Adaptive escalation — retry budgets, novelty scoring, stall detection, and operator load protection settings.

For the full schema, see the Deployment Policy reference.

Operator Overrides

The policy uses a two-layer design. Ananke signs the base policy, which sets minimum safety bounds. Operators can tighten those bounds without Ananke’s involvement.

Operators can:

Override	Constraint
Raise the gamma floor	Must be at or above the base policy’s gammaFloorMin
Restrict the enforcement mode	Must be one of the base policy’s permittedModes
Reduce the staleness window	Must be at or below the base policy’s metricStalenessMaxMs
Tighten fail behavior	Can change fail_open to fail_closed, but not the reverse

Operators cannot lower the gamma floor below the base minimum, enable modes the base does not permit, or loosen staleness or fail behavior. The policy resolution happens once at load time. Use kairos policy validate to check a policy file and kairos policy inspect to see the resolved effective configuration.

Feature Flags

Fly-by-Wire capabilities are controlled by Cargo feature flags at compile time. You enable exactly what you need:

Feature	What it enables
fly-by-wire	Stateful sessions, action gating, hazard gating, session-side HITL with replay guard
tui	The kairos observe dashboard with live telemetry, projections, and HITL operator mode
slm	Sentinel SLM backend (SmolLM2-1.7B local inference)
dynamic-config	Runtime artifact loading from filesystem (for rapid iteration)
static-config	Compile-time artifact embedding

The minimal deployment (stateless evaluation, state gating only) requires no feature flags beyond the defaults. Adding fly-by-wire enables sessions. Adding tui enables the observe dashboard. Adding slm enables richer Sentinel narratives. Each flag adds capabilities and dependencies.

For the full feature matrix and build configurations, see the Feature Flags reference.

Integration Patterns

Three integration surfaces are available:

CLI — run kairos evaluate from any language that can invoke a subprocess. The request is a JSON file, the response is JSON on stdout. This is the simplest integration path.

Native library (C FFI) — link libkairos directly into your application. The FFI exposes evaluation functions callable from C, C++, Python (via ctypes), and any language with C FFI support. This eliminates subprocess overhead and enables in-process evaluation.

WebAssembly — build the kairos-wasm crate for browser or Node.js environments. The WASM module provides advisory evaluation without license enforcement.

For integration details, see the Integration section.

Deployment Checklist

A production Fly-by-Wire deployment requires:

1. Calibration artifact — a validated JSON file mapping your domain metrics to $\Lambda$ and $\Gamma$
2. Deployment policy — a signed base policy with operator overrides, HITL authorities (if overrides are needed), and optional adaptive escalation configuration
3. License key — a valid license for the target machine and domain
4. Built binary — compiled with the appropriate feature flags for your deployment surface
5. Coordinator (if HITL is enabled) — the kairos hitl serve process running with its TOML configuration and operator private keys

For build instructions and testbed setup, see the Deployment section.