The Shadow Latency Budget
For the predictive shadow to lead the plant, every stage from telemetry to twin update must fit within a strict latency budget.
Budgeting the loop
The shadow only leads reality if the sense-estimate-predict-publish loop completes fast enough that the forecast is still ahead by the time controllers read it. Kronos budgets latency across the whole chain and holds each stage to its share, so the twin step reliably fits inside the cadence that supports a 50-100 ms lookahead.
- L2 ingest: validated features delivered with bounded, known latency
- GNN denoise/impute: a bounded forward pass over the diagnostic graph
- State correction: estimator update against aligned measurements
- Coupled twin step: 1-2 Picard passes over four surrogate modules
- Publish: state + projection + uncertainty to L1/MPC/anomaly consumers
Determinism over average speed
What matters is worst-case, not average, latency: a controller cannot depend on a forecast that is usually on time. Kronos therefore uses bounded-compute components, surrogates with fixed inference cost, real-time-iteration MPC with one step per cycle, capped Picard passes, so the loop's execution time is predictable rather than data-dependent. A step that risks overrun publishes its best available result and flags reduced fidelity rather than blocking.
The latency gradient across L0-L2 matters here: the shadow runs on compute close to the plant (the edge-to-cloud gradient keeps twin inference near the machine), while the expensive offline work, Monte Carlo neutronics, PINN training, surrogate distillation, lives at L0 and never sits in the shadow loop. Only pre-trained, fixed-cost inference runs online.
The shadow's latency budget is deliberately separated from L1's microsecond budget. L3 does not compete for the hard-real-time path; it operates in the slower predictive regime, and the strict sub-10 microsecond command boundary and hardware failsafe are untouched by any L3 latency variation.