The handoff between what runs locally and what runs here

Most descriptions of a split between local and rented compute stop at the split itself: real-time stays here, batch goes there. The interesting part is the seam. A model that the network trains has to end up on a robot. Footage that a robot records has to end up in a network job. Something crosses the line in each direction, and how it crosses matters more than where the line is drawn.

E31 Network is being designed so that the crossing is, in every case, a deliberate move made by the team rather than a live connection between its machines and the pool.

Direction one: data leaves the local side

Everything on the local side produces data. Robots log what they saw and did. Edge devices record what passed in front of them. Operator systems keep records of the shift. That data accumulates on the team's own systems, where it already lives.

When the team decides to run a job, it stages the data the job needs. In the job's terms, that is THE DATA: what the job reads, prepared for the job. The staging is an act the team takes, at a time it chooses, with the subset it chooses. A robot does not stream to the network. A camera does not upload as it records. The team gathers, selects, and stages.

This is the half of the handoff with the most unfinished engineering behind it. Getting large datasets to where the compute is appears on the program's own list of problems not yet solved, and the article on getting large datasets to where the compute is treats it as the open question it is. The design intent is settled even if the mechanics are not: data moves because the team moves it, as the input to a specific job.

Direction two: output returns to the team

The job runs unattended, isolated from other jobs, and finishes. What it produces is THE OUTPUT: a model, a set of results, processed files, a report. The design intent is that the output is returned to the submitter, and then the compute is released and the meter stops.

Returned to the submitter is the important phrase. The output lands in the team's hands. It does not land on the robot. If the output is a retrained perception model, the team takes it from there: tests it against the cases it cares about, decides whether it is better than what is running, schedules a deployment, and pushes it to devices through whatever process the team already trusts for that. None of that is the network's job, and none of it would be visible to the network.

The same holds for less dramatic outputs. Processed footage comes back as files the team can review. Simulation results come back as a set the team can analyze. An evaluation report comes back as a report. In every case, what happens next is local.

Why the seam is kept this explicit

It would be possible to imagine a tighter coupling, where devices feed the network continuously and the network updates devices as soon as a job completes. The network is not being designed that way, for reasons that follow from the real-time rule.

A live connection would make the local side depend on the network. A robot whose next model arrives whenever a remote job finishes is a robot whose behavior changes on someone else's schedule. A camera that uploads as it records is a camera with a dependency on a link. The whole point of keeping real-time work local is that it keeps working without anything else. An explicit handoff preserves that. The team can run jobs or not, and the floor does not notice either way.

An explicit handoff also keeps the accounting clean. A job has a beginning, when compute is held for it, and an end, when the output is returned and the compute is released. What was held is accounted for. A continuous stream has no clean edges to account against.

What the handoff looks like in practice

Consider the retraining case from the examples page. A team has a model on its machines and a fresh batch of new data on its servers. It stages that data, describes the work as a retraining run, states the request as compute tonight until the run is done, and names the output as the retrained model. The job waits in the queue if it must, runs when compute is free, and the model comes back.

The team now has a candidate. It evaluates the candidate locally or, if the evaluation is itself heavy, submits it as another job and gets a report back. When it is satisfied, it deploys through its own process. At no point did a machine on the floor talk to the network, and at no point did the network reach into the floor. That is the handoff as designed: two moves, both made by the team, with the real-time path untouched in between.