The Twin State Vector and Interfaces
What KRONOS-CTRL actually holds and publishes: a defined state vector with lineage that L1, MPC, and the anomaly ensemble consume.
A defined state, not a black box
KRONOS-CTRL maintains an explicit, versioned state vector rather than an opaque model. It comprises the plasma equilibrium and stability margins, the neutron flux and breeding balance, the thermal and strain fields, and the electrical/DEC and grid-sync state, plus per-quantity uncertainty and a lineage tag pointing back to the L2 features and model versions that produced it.
- Plasma: psi map, q-profile, shape, delta, X-point, stability margins
- Neutronics: flux/spectrum, TBR, residual D-D, fluence
- Thermomechanics: temperature and strain fields, thermal margins, health indices
- Power: DEC potentials, efficiency, delivered power, grid-sync status
- Meta: per-quantity uncertainty, model versions, L2 feature lineage, timestamp
Interfaces
The state vector is the contract between L3 and its consumers. L1 receives actuation intents and envelope constraints derived from it; MPC reads the current state and its forward projection as f_twin; the anomaly ensemble reads it to compute forecast residuals; operators read a curated view. Because it carries lineage, any decision can be traced to the features and model versions behind it, which is required for validation and post-event analysis.
The state is published on a fixed cadence with both a now estimate and the shadow projection, so consumers always know current state and near-future state together. Uncertainty travels with every quantity, so a downstream controller can see not just the value but how much to trust it and tighten its margins when trust is low.
Strict metadata governance from L2 carries through here: the twin state inherits the same lineage discipline, so the whole chain from analog port to control decision is auditable. This is what lets Kronos treat the twin as evidence, not just as an aid.