Skip to content

Concepts

The Substrate stack provides two distinct evaluation surfaces. Choosing the right one depends on whether you need stateful engine telemetry or stateless policy checks.

SubstrateRuntime performs stateless policy evaluation. Each call to evaluate() is independent — there is no engine state, no tick counter, no history.

Use SubstrateRuntime when you:

  • Need a simple pass/fail gate on a metric snapshot
  • Don’t need engine telemetry (warning signals, projections, reachability)
  • Want minimal overhead per evaluation
  • Are running in a request/response service architecture

The runtime handles:

  • Metric scaling (domain values → λ\lambda, γ\gamma)
  • Policy resolution (base + operator overrides)
  • State gating (γ\gamma vs. floor threshold)
  • HITL override verification for REJECT_STATE decisions

SubstrateSession wraps a SubstrateRuntime with a live simulation engine. It maintains state across evaluations — the engine ticks forward, accumulates history, and produces telemetry.

Use SubstrateSession when you:

  • Need real-time telemetry (warning signals, severity, imminence, criticality)
  • Want action preview gating (preview proposed actions without advancing time)
  • Need hazard detection (basin collapse, paradox)
  • Are running a continuous control loop or monitoring dashboard
  • Need escalation directives (reformulate vs. human escalation)

The session adds:

  • Engine tick management and actor stepping
  • Warning signal computation (severity, imminence, risk, criticality)
  • Reachability analysis and projection previews
  • Escalation directive generation based on gamma headroom
  • Action gating via registered ActionPhysicsMapper implementations
  • Hazard gating (basin collapse and paradox detection)
  • In-session HITL replay detection
  • Multi-actor support with per-actor evaluation and stepping

The deployment policy’s mode field (or operator override) determines which gates are active:

The engine evaluates but never rejects. All decisions are PASS, but the response still contains the full evaluation detail — gamma, lambda, stability, warning signals, and escalation directives. This mode is for monitoring and data collection.

The engine evaluates the metric snapshot and rejects if γ\gamma falls below the configured floor. The action field on the request, if present, is ignored.

ConditionDecisionReason Code
γ\gamma \geq floorPASSNONE
γ<\gamma < floorREJECT_STATEGAMMA_BELOW_FLOOR

All state_gate checks apply, plus the engine previews the proposed action (if present) using a registered ActionPhysicsMapper. The action preview simulates the effect of the proposed action without advancing engine time.

ConditionDecisionReason Code
γ\gamma \geq floor, action safePASSNONE
γ<\gamma < floorREJECT_STATEGAMMA_BELOW_FLOOR
γ\gamma \geq floor, action unsafeREJECT_ACTIONACTION_PREVIEW_UNSAFE

Action gating is session-only. The runtime ignores the action field even in state_plus_action_gate mode — it only performs state evaluation.

Observe-Mode Semantics in Session Hazard Gates

Section titled “Observe-Mode Semantics in Session Hazard Gates”

The session path can detect two hazards that the stateless runtime never produces:

  • Basin collapse (REJECT_BASIN_COLLAPSE) — the engine preview predicts a loss event
  • Paradox (REJECT_PARADOX) — the engine preview detects a multi-agent collision

In observe mode, these hazards are still detected and reported in the response’s evaluation.hazardGate detail block, but the decision remains PASS. This lets you monitor for hazards without blocking actions.

Both hazard decisions are non-overrideable by HITL tokens. They represent structural failures that cannot be safely bypassed by operator authorization.

ScenarioSurfaceMode
Pre-deployment testingSubstrateRuntimestate_gate
Production API gatewaySubstrateRuntimestate_gate
Live monitoring dashboardSubstrateSessionobserve
Autonomous agent control loopSubstrateSessionstate_plus_action_gate
Data collection / calibrationSubstrateSessionobserve
CI/CD policy validationSubstrateRuntimestate_gate