Data gravity is not a bandwidth problem

A robot fleet's sensor data does not leave the site. Ask why and the first answer is about the pipe — the uplink is too small, the egress bill too large, the compression not good enough yet. That answer is not wrong. It is the shallow half of the problem, and it is the half that invites the wrong fix, because every fix it invites is a way of making the data smaller.

The deeper half is what the data is. Continuous sensor output from machines working inside a building is not a large object; it is a description. It records what the building does, how, at what rate, and with whom. Moving it is not a logistics question with an engineering answer. It is a policy question, and policy questions do not yield to better codecs.

Both halves point the same direction, which is the useful thing about them. Either alone might be negotiable. Together they make the sensor stream a fixed feature of the terrain.

The shape of the volume problem

Take the easy half first, because its shape is instructive. A working machine is not one camera. It is several — a wrist view, a gripper view, a chassis view, whatever the task needs to see — plus depth, plus lidar on anything mobile, plus force and torque at the contacts, plus joint telemetry at control rates. Each is unremarkable alone. Together they are a stream, and multiplying by the machines on a floor makes that stream the facility's second output, produced continuously alongside the product.

Continuity matters more than size. A fleet does not produce a file to upload after the shift; it produces through every minute of every shift and again tomorrow, so the backlog never clears and the link never goes quiet.

Meanwhile the site's uplink was provisioned for something else entirely — enterprise applications, mail, a video call, an occasional transfer to a supplier. Nobody sized it for a continuous multi-camera record of the production process, because until recently nothing on the floor produced one. A single camera stream at working resolution can consume what a plant's connection has to spare, and a fleet's worth is not a harder version of that problem but a different category of demand.

The arithmetic runs the wrong way

The comfortable assumption is that this is transitional: links improve, so wait. The trend lines do not cooperate. Fleets grow toward denser deployment — more machines per floor, more floors per operator — and sensors improve at the same time, every improvement an increase in emission. Higher resolution because the task needs finer discrimination. Higher frame rate because the motion is faster. Additional modalities because the policy performs better with them.

The reason to add a sensor is almost always that a learned system gets better with what it produces, which means volume grows for precisely the reason the data becomes valuable. A fleet that gets better gets louder.

Uplinks do improve, at the rate of regional infrastructure and capital planning, for a whole site at once, on a cycle measured in years. Fleet output improves at the rate of the robotics roadmap. Planning an architecture on the assumption that the first curve overtakes the second is a bet against the direction of your own product plan.

What the stream actually is

Now the harder half. Set the transfer cost aside and ask what would be moving. Video of a working facility is a record of the process: the sequence of operations, the fixtures and tooling, the routing of material, the layout of the floor, the places where the line hesitates. Anyone who has tried to write down how a plant actually works knows the recording is the better description, because it includes everything the author thought too obvious to mention. Telemetry is the same record in another form — cycle times, force profiles, retry rates, the yield curve, the specific method this site uses.

The stream also contains people: their positions, their pace, their faces, their badges, their habits. In a hospital corridor nearly everything a camera sees is protected by statute. On a factory floor, worker imagery carries obligations that attach whether or not anyone intended to record a person, and a camera on a moving machine has no field of view that respects the distinction.

So the export question is not whether some sensor data may be moved. It is whether a continuous, high-fidelity recording of the operation, its methods, and its people may be placed on infrastructure the operator does not own, under terms the operator did not write, in a jurisdiction the operator may not have chosen. The answer in serious environments is no, and it arrives from three directions at once.

Three forces, one direction

They are worth separating, because they behave differently and cannot be traded against one another.

Cost is the force everyone models and the weakest of the three. It recurs, and it scales with utilization: the better the fleet works, the more it costs to keep watching it. But it is negotiable in principle — a bigger link, a different tier, a better encoder, a decision to keep less. Cost problems have engineering answers, which is why they attract the most attention and deserve the least weight.

Law is not negotiable and does not care about efficiency. Personal-data regimes attach to imagery of people wherever it is processed. Health-privacy rules reach every sensor in a clinical space. Critical-infrastructure regulation constrains where operational data may be handled. Classification and export control confine bytes regardless of what any engineer would prefer, and in the environments where autonomous machines are most needed those regimes are the normal condition. A compliance function does not ask whether a transfer is cheap. It asks whether it is permitted.

Competitive exposure is the quietest and often the most decisive. For a plant whose process is its advantage, process video is that advantage in recorded form and telemetry is the annotation. Customer contracts routinely forbid disclosing anything about how their parts are made. An operator can absorb a cost and work through a regulation, but placing a complete description of the method onto someone else's infrastructure is a decision with no reverse gear, because copies do not come home.

Any one of these would keep the stream inside the fence. Having all three means there is no clever arrangement in which the data leaves under some conditions and not others. The conditions do not overlap.

The asymmetry that defeats sampling

The instinct here is to send less. Downsample. Send keyframes. Summarize on the machine and ship the summary. Send embeddings instead of pixels. Forward only the interesting events. It is the right instinct, and it does not survive contact with what the data is for.

The parts you would discard to fit the pipe are the parts with training value. Footage of a task going normally is the most compressible material the fleet produces and the least informative; a policy that already handles the routine case learns almost nothing from another day of it. What carries signal is the opposite — the odd frame, the light through the door at the wrong hour, the object presented at an angle nobody anticipated, the near-miss, the grasp that slipped for a reason no one has characterized. These are rare, irregular, poorly compressible, and not reliably identifiable at ingest. A filter that could recognize the valuable episode in advance would need roughly the understanding you were collecting the data to build.

That is the asymmetry. Value density is concentrated in precisely the fraction a bandwidth-driven filter throws away. Sampling preserves a faithful record of everything going as expected and drops the long tail, which is the only reason to retain sensor data at all.

There is a version of this that does work, and it deserves naming plainly. Extract the signal where the data is made, and move the result. That is not a compression strategy dressed differently. It is a statement about where the compute lives.

Where this leaves the compute

Data gravity is a useful phrase because it names a force rather than a bill. Mass attracts, and the heaviest object in a system determines what orbits what. In a facility running machines, the heaviest object is the sensor record — too voluminous to move and too consequential to release. Neither weight is going to decrease.

Take that as given and the architecture stops being a matter of preference. If the data cannot move, the compute must. Perception runs where the cameras are. Heavy inference runs where the streams terminate. Training signal is extracted on the same side of the fence as the machines that generated it, and what crosses afterward is a model, a policy, or an evaluation result — small enough to review, few enough that a person can approve each one.

The boundary is not arbitrary either. It is drawn by the same obligations, contracts, and ownership that make the data immovable, which places it at the facility's fence.

E31 Network is being designed for that placement rather than around it. The facility plane is intended as the point where the fleet's data terminates and its compute begins — not because onsite infrastructure is a preference, but because the alternative requires a permission that the industries with the most to gain from working machines are never going to grant.