The Edge-to-Cloud Continuum

Compute is placed where its time budget demands — FPGAs at the edge for microseconds, on-site servers for the twin, cloud HPC for batch work.

Placement follows latency

The architecture's compute is distributed along a continuum from the edge to the cloud, and placement is decided by time budget, not convenience. The tighter a function's latency requirement, the closer to the machine it runs; the more compute it needs, the farther away it can afford to be.

The continuum

• Edge FPGAs — microsecond determinism at L1, physically at the machine.
• On-site servers — the L3 twin and its 50-100 ms predictive shadow, near the data.
• Site data fabric — L2 archive, feature store, and vector DB.
• Cloud HPC and bare metal — L0 batch training and Monte Carlo, latency-tolerant.

Why the twin runs on-site

The predictive twin sits in the middle of the continuum for a reason: it needs enough compute to run four physics modules but must stay within tens of milliseconds of the plant to be useful for control. Running it on-site keeps the round-trip short while leaving the heaviest work — retraining, neutronics — for the cloud.

The gradient as a design constraint

The continuum is the physical realization of the latency gradient. It also enforces a security property: the deterministic edge is isolated from the cloud by the IT/OT boundary, so cloud compute can scale freely without ever being on the safety path. This is the same separation that lets a long L0 job never contend with L1.

The continuum underlies the real-time versus offline boundary and the latency gradient.