Copilot Latency and the Offline Boundary

Copilots live in the seconds-and-slower advisory regime, cleanly separated from the microsecond control path they never touch.

The right layer at the right timescale

Kronos separates timescales strictly. Microsecond actuation and fast protection live in L1 on FPGAs and deterministic hardware. Millisecond model-based control lives in L3 MPC. The L5 copilots live above all of that, in the seconds-to-minutes advisory regime for interactive requests and the offline regime for deep analysis. A copilot never sits in a hard-real-time loop, so its latency variability can never threaten the machine.

Latency Tiers

This separation is why a copilot can afford large context, multi-step planning, and retrieval — none of it is on a control deadline. It is also why a copilot's stale-state refusal matters: because the copilot is not in the loop, it must actively confirm its twin-state snapshot is fresh enough for the question, rather than assuming loop timing guarantees freshness.

Interactive versus offline

• Interactive: bounded context and step budget for seconds-scale response to an operator
• Offline: larger budgets, Bayesian optimization, batch scenario studies on L0 compute
• Both produce proposals; neither executes on the plant
• Offline results are cached and retrievable so interactive requests can cite them

Heavy work — scenario optimization, large maintenance studies — runs offline on L0 compute and lands its results in L2 for later, fast retrieval. An interactive request then cites a completed offline study rather than recomputing it, keeping the interactive path responsive.

The offline boundary also protects determinism: interactive copilot responses draw on frozen, versioned artifacts (prompt, index, twin snapshot), while retraining and re-embedding happen offline on a tracked schedule. This mirrors the platform-wide real-time versus offline separation and keeps the copilots' behavior reproducible for audit.