Skip to content

TECHNICAL PREVIEW · IN ACTIVE DEVELOPMENT

ALL NOTES

DEPLOYMENTS

Linear infrastructure and the thin uplink

Inspection fleets for energy and utilities break the assumption that a facility is the unit of deployment. When the asset is a corridor of small unstaffed sites rather than a building, where the compute lives becomes a genuinely open question.

· 8 min read

Most robotics environments are rooms. A plant, a warehouse, a terminal — each has a perimeter, a power feed, an operations building, and a boundary that everyone involved can point at. Energy and utility work is not shaped like that. The asset is a network: generation sites and large substations at the nodes, and between them transmission corridors, distribution feeders, and pipelines running for as far as the system reaches.

Inspection and maintenance fleets follow that geometry. They work at a few substantial sites and at a great many small ones — switching stations, valve sites, pumping and compressor stations, riser and metering points — most of which are unstaffed, remote, and visited on a schedule rather than occupied. And a meaningful share of the work happens at no site at all, along the span between them.

The argument that a facility is the natural unit of compute, coordination, and learning is made elsewhere and holds wherever there is a facility. Here it does not cleanly apply, and it is more useful to say so than to stretch the framing. This archetype pushes harder on the architecture than any of the others, and the question it pushes on is simple to state: when the asset is a line, what is the unit of deployment?

The asset is a line

Start with what the geometry actually changes. In a building, every machine that matters is inside one boundary, sharing one network, one power system, and one owner's control. Along a corridor, the fleet is spread across a distance that no local network spans, and the sites it works at differ from each other by more than any single design point can absorb. A generating station has conditioned space, staff, and real power. A pole-top or valve site has a cabinet, a modest supply, and a gate.

The work is also episodic. A corridor is not inspected continuously; it is inspected in passes. A crawler, a ground vehicle, or an aerial platform covers a segment, and then the segment is quiet for a long time. Compute bolted to a site sits idle between passes, while compute that travels is busy exactly when the work is.

Meanwhile coordination — the thing that justifies a facility plane in a warehouse — barely applies. Two inspection machines on the same corridor rarely contend for space. What they share is not a floor but a model: the same detectors, the same criteria, the same accumulated understanding of what a degrading component looks like on this operator's equipment. The shared resource here is learned capability, not real-time state, and learned capability has a completely different latency requirement than deconfliction does.

Three shapes for the compute

There are three plausible answers, and each is right about something.

  • Compute that travels with the machine. The unit becomes the inspection platform itself. Coverage matches the asset exactly, nothing has to be installed or secured at a thin site, and the machine keeps full capability in places with no infrastructure at all. What it gives up is scale: the platform's power, weight, and thermal envelope cap what can run, and a vehicle cannot hold the corpus or do the adaptation that makes next season's detectors better.
  • A plane at each substantial site. Where a real facility exists, the ordinary model works, with power and space and a boundary that can be defended. It covers the nodes well and the spans between them not at all, and it multiplies the number of boundaries an operator has to maintain and attest, for assets that may see a machine only rarely.
  • A regional plane serving many thin sites. One plane per operating region, with thin sites and travelling machines attaching to it. The economics are far better, and adaptation across many similar assets is where the learning actually improves. The cost is that it puts a link between a machine and its plane, and that link is the thin backhaul that created the problem in the first place.

The likely answer is not to choose but to partition by deadline: perception and autonomy on the machine unconditionally, since the corridor may have no coverage; site-scoped work at sites that can host it; and cross-asset adaptation and analysis at a regional plane, which tolerates a slow link because nothing about it is in a control loop. Stated that way it sounds settled. It is not — the hard part is what a thin site should hold, and how a machine that has been out of contact for a long pass rejoins and reconciles.

Bandwidth first, policy immediately after

Every archetype has a reason the data cannot leave. Here the reason is arithmetic before it is anything else. Remote backhaul is thin, sometimes metered, and sometimes satellite, and a single camera stream at working resolution outruns what a small site's link can carry. Multiply by the sensors an inspection pass actually uses — visible, thermal, sometimes acoustic or ranging — and the mismatch stops being a matter of compression. Nothing is going to stream. The only question is what gets summarized and where the summarizing happens.

Policy arrives immediately behind. Grid and pipeline operations data is treated as a national-security concern, not merely as commercial information, because it describes the condition and topology of infrastructure whose failure is a public event. Critical-infrastructure regimes dictate how that information is handled, who may hold it, and where it may reside, and vendor access to operational data is a question that gets asked early and answered narrowly.

The two constraints reinforce rather than substitute. If the links were generous, the regime would still confine the data. If the regime relaxed, the links would still not carry it. An architecture that solves only one of them has solved neither, which is why the useful design target is a system that never needed to move the data for its own functioning.

A large input and a small output

Inspection has an unusually favorable shape for local processing. The input is enormous: hours of imagery over a span, most of it showing equipment behaving exactly as it should. The output is small — a corroded fitting, a cracked insulator, a joint running warmer than its neighbors, vegetation encroaching on a conductor. The valuable product of an inspection pass is a short list of findings and their locations. That is the ideal case for processing where the data is made and shipping only the judgment.

Two things complicate the funnel, and both push in the same direction. The first is that a finding has to be defensible. In a regulated environment, a judgment that triggers a maintenance action, an outage, or a filing will be examined later, and the examination asks for the evidence behind it. So the system must retain enough of the input to justify each output, which means full-fidelity retention somewhere — and the somewhere cannot be up a link that could not carry the data in the first place.

The second is that the uninteresting imagery is the training set. What teaches a detector to distinguish a real defect from a shadow, a bird, or a paint blemish is the vast quantity of material that showed nothing wrong. That corpus is the least shippable and the most valuable, and it is generated continuously by the fleet on the operator's own equipment. Adaptation has to happen where the corpus lives, or it does not happen on this operator's data at all.

No locked room

Unstaffed sites remove the assumption that most computer security quietly rests on. A cabinet at a remote switching station is behind a fence and a padlock, unobserved for long stretches, reachable by anyone willing to be somewhere unremarkable for an afternoon. A machine that works a corridor is transported, parked, and recovered by whoever is nearest. Neither has the physical first wall that a datacenter's threat model assumes, and the point that attestation matters more when the computer is handled is argued in detail elsewhere.

What matters for this archetype is the consequence. Integrity has to be demonstrated rather than assumed on every rejoin, because between visits the honest posture is that a node may have been alone with someone. A unit that cannot prove which hardware, firmware, image, and model it is running gets no work and no keys, automatically.

Conveniently, the regulatory environment already expects this kind of artifact. Operators in this sector produce evidence for auditors as routine business, and attestation records, signed-bundle provenance, and inspection findings with retained justification are all the same species of thing: statements about what happened that were designed to be checked by someone who was not there.

What is still open

The design intent for this archetype is clear at the ends and unfinished in the middle. At the machine, autonomy has to be unconditional, because the corridor cannot be assumed to have coverage. At the top, governance has to work over links too thin to carry operations data: authority down as signed bundles, evidence up as attestation and audit records, and the imagery and findings staying inside the operator's boundary.

The middle — how a plane serves many thin, unstaffed, intermittently visited sites, and what belongs at each of them — is design work we have not finished. It is the part of E31 Network that a corridor operator would be right to press on, and the part where the facility framing that carries every other environment has to be replaced with something that fits a line.

DESIGN PARTNER PROGRAM

Build this with us.

We are working with a small number of teams operating real fleets in constrained environments. If the cloud is not an option where your machines work, we want to talk.