Skip to content

The Sentinel

Engine telemetry is precise but opaque. A gamma headroom of 0.05, a criticality of 0.75, and a steps-to-breach of 3.0 are exact — but they do not tell an operator what is happening, how fast it is happening, or what to do about it.

Sentinel translates these numbers into narratives.

When the evaluation pipeline produces an escalation, Sentinel receives the engine telemetry — a structured feed of recent tick data, warning signals, and escalation context — and produces three things:

A narrative. A plain-language summary of the system’s state and trajectory. At the CRITICAL risk level, this reads like: “System stability is deteriorating rapidly. Gamma has dropped to 0.250 against a floor of 0.200, leaving only 5.0% headroom. Warning criticality has escalated from 0.0 to 0.75 over the last 3 ticks, with impact projected in 3.0 steps. Immediate operator review recommended.”

Highlighted metrics. The two or three most important numbers, extracted from the telemetry and annotated with severity. An operator sees “Gamma state: 0.250 (floor: 0.200)” tagged as CRITICAL, “Steps to breach: 2.5” tagged as CRITICAL, and “Warning trend: 0.00 to 0.75 over 3 ticks” tagged as ELEVATED.

A risk level. A single classification — NOMINAL, ELEVATED, or CRITICAL — that summarizes the overall urgency.

LevelMeaningTypical conditions
NOMINALEscalation may be precautionaryComfortable headroom, no warning trend, stable trajectory
ELEVATEDTrajectory shows a concerning trendActive warning, moderate headroom pressure, increasing criticality
CRITICALImmediate human attention requiredNear or below floor, rapid escalation, projected breach within a few steps

Risk classification combines multiple signals: gamma headroom, warning trend direction, steps to breach, and whether a loss event appears in the recent telemetry window. A CRITICAL signal from any single indicator elevates the overall assessment to at least ELEVATED.

Each highlighted metric carries its own severity classification:

SeverityMeaning
INFOInformational context — no action needed
ELEVATEDWorth monitoring — the trend may worsen
CRITICALRequires immediate attention

Sentinel supports two backends for generating summaries. Both receive the same telemetry input and produce the same output structure. The choice is a deployment decision.

The template backend uses deterministic rules and pre-defined sentence templates. It analyzes the telemetry through a structured pipeline — gamma analysis, warning trend analysis, steps-to-impact assessment, risk classification, narrative assembly — and generates a summary from parameterized templates.

The template backend is fully deterministic: the same telemetry input always produces the same narrative. Latency is sub-millisecond. There are no external dependencies.

Use the template backend when you need reproducible assessments for audit trails, sub-millisecond latency, or zero-dependency deployment.

The SLM backend uses a locally-running small language model (SmolLM2-1.7B-Instruct) to generate richer, more contextual narratives. The model runs entirely on-device using the candle inference framework — no network calls, no data leaves the machine.

The SLM backend requires the slm feature flag at build time and a downloaded model bundle (~1 GB on disk). Latency is approximately 100ms per summary. The output is non-deterministic due to sampling.

Use the SLM backend when narrative quality matters more than determinism, 100ms latency is acceptable, and you can manage the model bundle.

AspectTemplateSLM
Latency< 1ms~100ms
Narrative qualityStructured, formulaicContextual, natural
DeterminismFully deterministicNon-deterministic
Disk footprintNone~1 GB model bundle
Feature flagAlways availableslm

Sentinel is used in two places:

The TUI dashboard. When kairos observe is launched with --sentinel, the dashboard includes a Sentinel assessment panel. Operators see the narrative, highlighted metrics, and risk level alongside the live engine telemetry.

The HITL coordinator. When an override request is submitted, the Sentinel telemetry feed and summary can be included with the request. Operators reviewing override requests in the TUI see the Sentinel assessment alongside the raw evaluation data, giving them both quantitative and narrative context for their decision.

Sentinel receives only trusted, session-emitted data. The telemetry feed contains no agent-generated strings or payloads. When a proposed action triggers an escalation, Sentinel receives a cryptographic hash of the action (actionHash) — not the action itself. Sentinel can reference this hash in the narrative (e.g., “Action #a7f8b9”) but cannot recover or display the original action payload. This is a deliberate boundary: the narration layer has no path to inject or surface untrusted content.

For the full telemetry feed schema, backend implementation details, and configuration, see the Sentinel Internals technical reference.