Latency Budget per Interface

Each physical interface carries an end-to-end latency budget from sensor edge to actuator gate, and the budget decides where its loop can close.

Latency is a specification, not an outcome

For every interface Kronos writes a latency budget before hardware exists: the time from a physical change, through sensing, transport, decision, and actuation, back to the physical world. The budget determines which layer can own the loop and whether the twin can sit in the path at all.

The budget terms

# end-to-end latency budget (per interface)
T_total = T_sense + T_afe + T_transport \
        + T_decision + T_command + T_actuate
# owner assignment rule
owner = 'L1' if T_total_required < ms_threshold else 'L3+'
assert T_total_worstcase <= T_total_required   # WCET, not average

The budget is stated as a worst case, not an average, because a protection loop that meets its deadline 99% of the time is not a protection loop. The twin's predictive shadow runs at 50–100 ms, which is why anything faster must close in L1 without the learning layer in the loop.

Representative budgets

The pattern is consistent across both machines: protection and inner loops in microseconds to milliseconds at L1; supervisory and campaign loops in seconds and up at L3/L4; accountancy in hours at L7. The clock distribution is what makes these budgets measurable, and the ownership rule follows directly from them.

Design-and-simulation specification; budgets are validated against the twin and, later, hardware-in-the-loop commissioning after Q2 2027 construction start.