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 › L4 · Orchestration
L4 · Orchestration

Long-Running Procedure Checkpointing

Procedures that run for minutes to hours checkpoint their state so a restart resumes exactly, without re-energizing from scratch.

THE STACK · click to jumpL7Ecosystem & StrategyL6Experience & VisualizationL5Applications & CopilotsL4OrchestrationL3Twin Modeling & AIL2Data FabricL1Control PlaneL0Foundation▲tlmctl▼L4 · ORCHESTRATIONEvents, workflows, rules, and human routing.1Event Streamingthe backbone2Workflow Enginecampaign procedures3Rules & Safety Boundshard limits4Human-in-the-Loopapproval routing5Schedulerexperiment campaigns6Audit Busfull decision lineageMACHINE TIECoordinates L3 outputs with L5 copilots and human operators.KRONOS FUSION ENERGYAI-NATIVE S.M.A.R.T. GENERATORORCHESTRATIONSHEET 06REV. 2026-08L4 · AI-NATIVE STACK
L4 · Orchestration — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

Restarts must not restart the machine

A breeder shot lasts seconds, but a full campaign or a burner steady-state run lasts far longer, and the orchestrator process can restart mid-procedure. Checkpointing persists procedure state frequently so a restart resumes at the exact step rather than re-running an energizing sequence from the beginning, which could be unsafe on a partially-energized machine.

Checkpoint contents

json
{
  "procedure": "burner_steady_state",
  "version": "1.8.0",
  "current_step": "STEADY_STATE",
  "committed_steps": ["throat_field","plug_field","fuelling","ignition_approach"],
  "held_tokens": ["burner.plug.field","burner.throat.field"],
  "saga_compensations_pending": ["safe_bleed"],
  "last_event_offset": 918273
}

Checkpoint = last committed event

Because the procedure is a deterministic function of the event log, a checkpoint is effectively a durable offset plus derived state. On restart, orchestration reloads the checkpoint and, if needed, replays events after the checkpoint offset to reach the precise current state, reusing the replay machinery. Idempotent handlers mean any re-applied events after the checkpoint are harmless.

Token and saga continuity

Frequency vs cost

Checkpoint cadence is tuned so the maximum re-play distance after a restart stays small, which matters most for the burner's plug supervision where the machine must not lose the plug during an orchestrator restart. All of this is validated in simulation ahead of FOAK, with fault injection that kills the orchestrator mid-procedure.

Content reviewed August 2026 · design-and-simulation stage