Skip to content
Technology How it works Breeder — Hyperion Burner — Aegis Burner — MetroVolt AI-Native Architecture Magnets Fuel cycle Safety Roadmap
Solutions AI & Data Centers Defense & Government Grid & Baseload Neutron Detection Quantum
Learn Technical Library
Proof Publications Whitepapers Technical Library Open Science & Reproducibility The Honest Gates
Company About / Mission Leadership Environment Health & Safety Investors Careers Press Contact
3D Model
AI Architecture › L3 · Twin Modeling & AI
L3 · Twin Modeling & AI

Terminal Sets and Recursive Feasibility

The theory that lets Kronos trust MPC over a finite horizon to keep the machine safe indefinitely: a terminal safe set and a terminal cost.

THE STACK · click to jumpL7Ecosystem & StrategyL6Experience & VisualizationL5Applications & CopilotsL4OrchestrationL3Twin Modeling & AIL2Data FabricL1Control PlaneL0Foundation▲tlmctl▼L3 · TWIN MODELING & AIThe KRONOS-CTRL digital twin and its predictive shadow.1KRONOS-CTRL Twinlive plant state2GNNscoupled subsystems3PINNsphysics-constrained4Anomaly Ensemblesdrift & fault detection5MPCreceding-horizon control6Predictive Shadowruns seconds aheadMACHINE TIEState estimate descends to L1 control; alerts rise to L4 / L5.KRONOS FUSION ENERGYAI-NATIVE S.M.A.R.T. GENERATORTWIN MODELING & AISHEET 05REV. 2026-08L3 · AI-NATIVE STACK
L3 · Twin Modeling & AI — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

The finite-horizon gap

MPC plans only N steps ahead, yet the machine runs indefinitely. Without care, a plan that looks fine over the horizon could steer the machine into a corner from which no safe continuation exists. The standard remedy, adopted by Kronos, is a terminal constraint: require the horizon to end in a terminal safe set X_terminal from which a known safe policy can keep the machine safe forever.

Why it guarantees safety

If every MPC plan ends inside X_terminal, and inside X_terminal a fallback controller is known to keep the state safe, then the receding-horizon scheme is recursively feasible: a safe plan existing this cycle guarantees a safe plan exists next cycle (shift the plan and append the fallback move). The terminal cost P approximates the cost-to-go of that fallback policy, so optimizing over the finite horizon behaves like optimizing over the infinite one. This is what converts a horizon-limited optimizer into a controller with an indefinite safety guarantee.

python
# terminal ingredients
#   X_terminal : invariant safe set (fallback policy keeps state inside)
#   P          : terminal cost ~ cost-to-go of fallback policy
# recursive feasibility: feasible now => feasible next cycle
#   plan_next = shift(plan_now) + fallback_move   # always feasible

For the breeder, X_terminal corresponds to a stable, well inside the envelope, low-stress equilibrium the machine can be held in; for the burner, a plug-density and potential state with comfortable confinement and mirror-stability margins. The fallback policy is a simple, certified controller, not another learned model, so the safety guarantee does not rest on a neural network behaving well.

This layering, learned surrogates and optimization for performance, a certified fallback and terminal set for the safety floor, is the same philosophy as the L1 hardware failsafe: performance may lean on AI, but the safety guarantee never depends on it alone.

Content reviewed August 2026 · design-and-simulation stage