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 › L7 · Ecosystem & Strategy
L7 · Ecosystem & Strategy

Multi-Unit Coordination and Control

A fleet controller coordinates many units through the same unified API each unit exposes, balancing power obligations, fuel, and maintenance across the population.

THE STACK · click to jumpL7Ecosystem & StrategyL6Experience & VisualizationL5Applications & CopilotsL4OrchestrationL3Twin Modeling & AIL2Data FabricL1Control PlaneL0Foundation▲tlmctl▼L7 · ECOSYSTEM & STRATEGYThe plant in its world — integrated through one unified API.1Unified API Layerone door in/out2Grid Integrationdispatch & firm supply3Supply Chainfuel, parts, isotopes4Maintenanceservice & spares loops5Regulatorycompliance & reporting6Fleet Strategymulti-unit planningMACHINE TIEConnects the machine to grid, suppliers, and regulators — the outermost loop.KRONOS FUSION ENERGYAI-NATIVE S.M.A.R.T. GENERATORECOSYSTEM & STRATEGYSHEET 09REV. 2026-08L7 · AI-NATIVE STACK
L7 · Ecosystem & Strategy — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

Coordinating through the single door

Because every unit exposes the identical unified API, a fleet controller talks to twenty plants exactly as an operator talks to one. Multi-unit coordination is therefore a client of the same read and write planes, one tier up: it reads each unit's state and forecast and writes dispatch and maintenance intents back, while each unit's own L1 through L3 stack keeps final authority over its own safety.

What the coordinator balances

The coordinator solves an allocation across units: meet aggregate firm-power obligations from the burner fleet, meet isotope-production and offtake commitments from the breeder foundry, respect each unit's maintenance windows, and keep helium-3 flowing from foundry to fleet. These are the same constraints the dispatch optimizer and material graph express; the coordinator is where they meet at fleet scale.

python
# fleet coordinator loop (each unit is an API client target)
while True:
    states = {u: read_state(u) for u in fleet}         # unified read plane
    plan   = coordinate(states, obligations, he3_pool,
                        maintenance_windows)            # constrained solve
    for u, intent in plan.items():
        submit_dispatch(u, intent)                      # unified write plane
    # each unit clamps to its own envelope; coordinator never overrides safety

The coordinator cannot override unit safety. Every intent it issues is clamped by the target unit's own envelope, so a fleet-level decision can never push an individual machine outside its certified operating point. This preserves the invariant that safety is local and authoritative even as strategy is global.

Coordination is resilient to unit loss. If a unit trips or enters an unplanned outage, its firm-power contribution drops out of the coordinator's next solve, which re-allocates across the remaining units within their headroom and reserve. The firm-power forecast's conservatism is what makes this re-allocation feasible without breaching obligations.

Multi-unit coordination runs today over a twin-modeled fleet. As real units commission from ~2030, they are enrolled into the same coordinator with no interface change, and coordination scope grows with the validated fleet rather than ahead of it.

Content reviewed August 2026 · design-and-simulation stage