Why industrial robotics needs a different data layer, and what the moat looks like.

The state of public robotics data, May 2026

Trekion is the industrial data and simulation and evaluation infrastructure layer for physical AI. We sit between foundation robotics labs and the plants where their models will eventually deploy. From that seat, the public data landscape looks like this.

Open X-Embodiment (Google DeepMind, 2023, expanded through 2025) is the canonical robotics demonstration corpus. Over one million trajectories across 22 robot platforms, pooled from 60 underlying datasets at 21 institutions, with 527 distinct manipulation skills. Excellent for embodiment generalization research. Heavily weighted toward lab manipulation tasks: blocks, cups, kitchen surfaces, generic objects on flat tables. Almost zero industrial process workflows.

Egocentric-1M (Build AI, April 2026) is the largest first-person robotics-relevant dataset to date. Roughly one million hours of head-mounted camera footage from over fourteen thousand factory workers across Southeast Asia, captured on Build AI's custom glasses inside real production environments: assembly lines, sorting, packaging, machining. Released Apache 2.0. Important step, and it does cover factory work. What it does not capture is what the plant's own systems saw at the same moment. There is no synced MES tag, no historian timestamp, no SCADA reading, no DCS state attached to the frames. The video knows what the operator did; it does not know what the plant did.

AGIBOT World 2026 is an open dataset from AgiBot. Broad scenarios, good benchmark for generalist policies.

NVIDIA Cosmos is a synthetic world model for physical AI. It generates training and evaluation data from world simulations. Complementary, not competitive. Most labs running serious industrial training pipelines should use Cosmos for volume and synthetic perturbation, and pair it with real ground-truth capture for fidelity.

Add it all up. The total quantity of high-quality real physical-interaction data globally, as of mid-2026, sits under 500,000 hours by most industry estimates. Generalist embodied policies need tens of millions of hours of relevant interaction to reach the breadth of behavior foundation lab teams are targeting. Roughly speaking, the world has about one twentieth of the data the labs need.

That is the data desert. Now the question that matters more: of the data that does exist, what fraction transfers to industrial deployment? Almost none. Here is why.

Why household tasks do not transfer to industrial

A foundation policy trained on household egocentric video learns three things well. It learns spatial reasoning over flat surfaces and clutter. It learns dexterous manipulation primitives for everyday objects. It learns natural language grounding for common verbs (pick up, place, open, close). All useful. None sufficient for industrial deployment.

What industrial deployment also requires:

Process state. The robot is not just moving a valve. It is opening a valve from 0 bar to 4.2 bar, in a system where the next downstream tag is a flow meter reading and a gas concentration alarm. The action only makes sense in the context of the plant state. Without that context in the training signal, the policy cannot learn the correct action conditioning.

Safety sequencing. Industrial SOPs are deeply ordered. A correct gas detection round in a refinery involves a fixed sequence of substeps in a fixed order, with a known set of permitted deviations. A household kitchen task has none of this structure baked in. A policy trained only on household data has no prior over operator-grade sequencing.

Tools and surfaces. A pipe rack is not a corridor. A control room is not a kitchen. A 30-year-old refinery floor has corrosion, fluid spills, vibration, varying lighting, and process noise that no kitchen captures. Sim-to-real transfer that works for tabletop block manipulation does not solve transfer to plant floors.

Operator conventions. Plant operators do tasks one way for hard reasons: lockout-tagout, two-person rules, vendor-specific procedure. Policies that have never seen these conventions cannot reliably propose actions a plant safety officer will approve.

This is why an Open X-Embodiment foundation plus an Egocentric-1M fine-tune is not enough to deploy a robot into a chemical plant. The transfer gap is structural.

What industrial reality actually looks like

Three concrete examples make this concrete.

A gas detection round on an oil refinery. An operator walks a fixed route. At each station, the operator turns a sample valve, takes a reading on a portable gas detector, logs the reading, and rotates the valve closed. The valve actions are simple. The state that makes them meaningful is not in the camera. It lives in the plant historian (the pressure reading before and after each valve action, the gas concentration recorded by the portable detector, the previous round's value for delta tracking) and in the DCS (the supervisory state of the upstream process unit). A useful training signal pairs the operator's action with these synchronized process readings. The video alone is just video.

A line changeover on an automotive assembly line. Parts swap, fixtures index, a quality gate runs. The operator's action sequence is dictated by the MES production order (which model, which trim, which fixture preset, which torque value). The same physical gesture means different things on different changeovers. Strip the MES context and the dataset has lost the information that made the action correct.

A structural inspection on a construction site. An inspector walks a route, captures defects against a checklist, syncs the checklist to ERP. The action is "look here, judge X." The training signal that makes it useful is the linkage to the ERP record (which structural element, which spec, which prior inspection round). Without that, the data is generic walking-with-camera content.

All three workflows have a common shape. Human action plus camera plus synced plant or facility system state equals a useful training episode. Human action plus camera, with no synced state, equals weakly labeled video that may help a model generalize but will not get it past a deployment evaluation.

The access problem

Even labs that recognize the gap and want to solve it run into the access problem. Industrial environments are gated. Plant security clearances are not casual. Hazard protocols vary by site and vendor. Insurance, IP, and safety officer sign-off are required before any data can leave the floor. Procurement cycles in oil and gas, pharma, and discrete manufacturing run six to twelve months on routine contracts.

A foundation lab that decides today to capture data in three chemical plants will, in the best case, see its first useful episode delivered nine months from now. The slow path is not the capture itself. It is the year of relationship work, certification, NDA, and on-site operator training that has to happen before the first camera is even mounted.

This is the asymmetry. The labs that need the data the most cannot economically build the access pipeline. The companies that have the access do not have the data infrastructure or the training-format expertise. The gap between them is the wedge Trekion was founded to close.

What this means for foundation labs

Three concrete implications.

First, household egocentric does not get a model to industrial deployment. Egocentric-1M is a useful upstream signal. It is not a substitute for industrial capture with synced process context. A policy that has trained only on household and lab demonstrations will not pass a plant safety officer's evaluation.

Second, scale of data matters less than fidelity of context. Ten thousand hours of process-contextualized capture from a refinery is more useful for training a refinery deployment policy than a million hours of generic egocentric. The data desert is a fidelity problem, not just a volume problem.

Third, owning the access pipeline is the moat at the data layer. Capturing industrial workflows with process context, at scale, is hard not because the cameras are special. It is hard because the access takes a year. Once a partner builds that access, they hold a structural advantage.

What Trekion delivers

Multimodal capture inside real plants. Every episode synced with MES, historian, SCADA, ERP, and DCS. Delivered as state-action pairs, trajectories, scene and task descriptions in the formats foundation labs train on. The schema and a sample episode are available on request.

We deliver this for one vertical at a time, with depth. The simulation and evaluation stack on top of the data layer turns one vertical's data flywheel into the deployment partner relationship for that vertical. That is the wedge.

If you are training a vision-language-action model for industrial deployment, talk to us before you commit a year of capture from your own side.

What process context actually is

Trekion is the industrial data and simulation and evaluation infrastructure layer for physical AI. Inside that mandate, the single most important technical commitment is this one: every episode we deliver carries the synchronized state of the plant's own systems, frame by frame.

Process context is a precise thing. It is not "metadata." It is not "labels." It is the readings of the plant's own software systems at the moment the operator performed the action the camera recorded. Those systems are:

MES (Manufacturing Execution System). Tracks production orders, work-in-progress, fixture indexing, recipe versions, and changeover state. A model that does not know what the MES knew at action time does not know which product the operator was assembling, which line was running which mix, or which step in a sequence the action belonged to.

Historian. Time-series record of every plant signal: pressures, flows, temperatures, levels, alarm states, vibration spectra. Common vendors include OSIsoft Pi (now AVEVA), Aspen IP.21, Honeywell PHD, Yokogawa Exaquantum, GE Proficy. The historian tells the model what physical state the plant was in when the operator acted. Without it, the action is unmoored from physical consequence.

SCADA. Supervisory control of distributed assets: pipelines, substations, water networks, remote pads. SCADA tells the model what the dispatchers were watching. It contextualizes wide-area actions a local camera cannot resolve.

ERP (Enterprise Resource Planning). The business-level state of the workflow: which work order, which batch, which customer, which compliance scope. Common vendors include SAP S/4HANA, Oracle Fusion, Microsoft Dynamics. ERP gives the model the "why" behind a workflow appearing on a given day in a given facility.

DCS (Distributed Control System). The supervisory layer for continuous processes in chemicals, oil and gas, pharma. Honeywell Experion, Emerson DeltaV, Yokogawa Centum, ABB Ability System 800xA. DCS tells the model the active control state of every loop: setpoint, output, mode, alarm.

PLC (Programmable Logic Controller). The closest layer to the physical plant. Discrete logic states, interlocks, safety circuits. Rockwell ControlLogix, Siemens S7. PLC data tells the model whether the equipment was in a permit-to-operate state when the action happened.

Process context is the union of these. It is not an enrichment. It is the part of the training signal that turns video into a state-action pair that survives plant-floor deployment.

One episode, twice

Take a single 30-second clip of an operator performing a routine on a refinery. The operator walks to a sample point, turns a sample valve to closed, takes a portable gas detector reading, logs the reading, opens the valve back to its prior position.

Label this clip two ways.

The second labeling makes every layer of the model's loss function meaningful. It tells a policy not just what action to take, but what state to expect, what compliance to maintain, what readings to capture, and what to do if the readings deviate. It transforms a kinematic demonstration into a deployable policy precursor. The first labeling does not.

This is what we mean by "process context is the missing label." The signal that determines whether the model can be trusted on a plant floor is the signal that lives in the plant's own systems. Capture without it is incomplete capture.

Why nobody has shipped this at scale

The reasons are mostly not technical. They are organizational.

The systems do not talk to each other. A modern refinery may run Honeywell Experion for the DCS, OSIsoft Pi for the historian, SAP for the ERP, and a custom MES on top of all of it. Inside the plant, those systems are integrated for operations. Outside the plant, exporting a synchronized cross-system trace per frame requires a one-off integration per facility. Most data collection pipelines do not even try.

The networks are isolated by design. Plant control networks are firewalled from corporate networks. Corporate networks are firewalled from public internet. Pulling a synchronized historian trace out of an active refinery network requires safety officer approval, IT change control, and often vendor engineering hours. None of that happens in a weekend.

The schemas vary by vendor and by site. Two refineries running Honeywell DCS still have different tag taxonomies, different historian tag naming, different MES customizations. Building a stable cross-site schema requires field engineering work that most labeling vendors are not staffed to do.

The expertise is split. People who know foundation model training rarely know historian tag schemas. People who know historian tag schemas rarely know what a state-action pair format looks like for VLA training. The Venn diagram is thin.

The result is predictable. Egocentric datasets ship with rich human-action labels and no plant-system labels. Industrial datasets ship with plant-system telemetry and no synchronized first-person video. The two are not joined, at scale, anywhere we have seen.

Closing that join is the data layer Trekion is shipping.

The Trekion schema for one episode

We publish the canonical schema preview on the homepage. The shape of one episode looks like this. Three artifacts, one episode ID.

episode.json describes the episode at the meta level. Facility type, vertical, workflow, SOP ID, operator count, duration, modalities captured (RGB left, RGB right, depth, audio, sometimes thermal or LiDAR), and a process_context object that indicates which plant systems were synced and how many tags. Plus annotation availability: count of state-action pairs, verification status of dense action labels, pose modality (hand and body, hand only, etc.), object tracking depth.

frames.parquet is the per-frame backbone. One row per frame at capture rate. Per row: frame ID, timestamp, image URIs, depth URI, operator ID, action label, atomic-action breakdown, hand and body 3D pose, object tracks, SOP step ID, and the matching MES tag and historian tag IDs at that frame.

telemetry.csv is the time series of every plant-system signal we synced for the episode, joined on timestamp. Tag ID, value, unit, SOP step the value belongs to.

The three artifacts are deliverable on their own. Together, they are the joined version of the episode that no generic dataset ships.

A sample episode is available on request.

Why this is the moat at the data layer

Anyone with cameras can capture industrial video. The thing that is hard to replicate is not the camera rig. It is the per-facility integration that pulls the historian, MES, SCADA, ERP, and DCS state into the same timeline as the video, in a format a foundation model can train on.

Replicating that requires three things in series. Industrial relationships strong enough that a safety officer signs an integration request. Field engineering deep enough to navigate vendor-specific schemas (OSIsoft Pi vs. AVEVA, Honeywell PHD vs. Yokogawa Exaquantum, SAP vs. Oracle ERP) without a vendor coming on site each week. Training-format expertise sharp enough to turn the joined trace into state-action pairs that drop into a VLA training pipeline.

Each layer is a year of work. Stacked, they are the data layer's moat. Once Trekion's pipeline is set up in a vertical, every subsequent episode pulls those three layers behind it without extra cost.

Foundation labs that try to build this themselves arrive at the same arithmetic. Nine to twelve months of relationship building per facility, plus per-vendor integration engineering, plus annotation expertise. The math does not work for any one lab to insource. It works for an infrastructure layer that amortizes the work across labs and across episodes. That is the seat Trekion holds.

What this means for foundation labs

Two practical implications.

First, if your VLA model is training on egocentric data without synced plant-system state, you are training on the wrong distribution for industrial deployment. Process context is not a nice-to-have label. It is the part of the signal that determines whether the policy can be trusted on a plant floor. Get it in your training set early.

Second, ask for a sample episode before you commit to any data vendor. The schema is the tell. If the vendor cannot show you a frames.parquet row with both mes_tag_id and historian_tag_id populated, time-synced to the frame, they are not shipping process context. They are shipping video.

If you want to see what a real process-contextualized episode looks like, we will share a public-safe sample under NDA within 24 hours.

Why data alone stops being a moat

Trekion is the industrial data and simulation and evaluation infrastructure layer for physical AI. The data layer is the entry point. It is not the moat.

The data layer is replicable in principle. It is hard, it takes a year per facility, and it requires a stack of capabilities that very few teams hold together. But it is not structurally defensible. A well-funded competitor can run the same playbook three years later and get to similar scale. The first-mover advantage decays as more labs realize industrial data is the gap. By 2028, the data layer will have multiple credible providers.

That is not where moats live in physical AI. The structural moat is one layer up. It is in the simulator that knows a vertical's physics intimately, paired with the evaluation harness that knows what good policy performance looks like in that vertical, measured against real operator benchmarks from the same plants. Once those two are in place and feed each other, they compound. Every captured episode tightens the simulator's calibration. Every simulated rollout exposes a gap that turns into the next capture. Every evaluation report against a new policy candidate sharpens the harness. The system gets better at evaluating policies faster than any new entrant can catch up.

This is the moat physical AI is going to settle around. Per vertical. Not generally.

Why generic simulators underdeliver in industrial verticals

The robotics community has excellent general-purpose simulators. NVIDIA Isaac Sim, MuJoCo, Drake, Gazebo. The newer Genesis World 1.0 (Genesis AI) is in active development as an open foundation for physical AI simulation. These are all serious platforms. None of them, by design, ship the things a deployable industrial policy needs to be evaluated against.

Plant fluid dynamics. A refinery has process fluids that vibrate piping, fog camera lenses, leak heat, change viscosity, and behave nothing like the dry kinematics most sim engines optimize for. A construction site has dust loading that defeats depth sensors. A pharma cleanroom has air-handling regimes that affect every wipe pattern. Generic sim engines have rigid-body and contact models. They do not have refinery-floor fluid behavior or cleanroom airflow models out of the box.

Real plant layouts. A pipe rack is not a corridor. A control room is not a kitchen. A switchgear yard is not a warehouse. Scene geometry that matches a real plant requires real capture. The geometry has to come from the same multimodal capture rigs that fed the data layer: depth maps, point clouds, calibrated cameras. Synthetic scenes built from CAD do not generalize to the wear, corrosion, and lighting irregularities of operational plants.

Real SOP sequencing. Industrial workflows are SOPs. API RP 578. OSHA 1910.119 inspection routines. ASME B31.3 piping procedures. FDA cleanroom protocols. The policy is not "do the task." It is "do the task under this SOP, in this order, with these compliance gates, on this asset class." None of that is encoded in a general-purpose simulator. It has to be authored as a task specification by people who know both the SOP corpus and the simulation engine. That is a vertical-specific layer of work.

Operator benchmarks. Even the best simulator only has value if you can score against something real. Operator benchmarks (the real human trajectory and outcome distribution for the same task on the same plant) are the ground truth. Generic simulators do not come with them. They cannot. Operator benchmarks are per-vertical and per-plant. They have to be captured. That is where the data layer's investment becomes the simulator's calibration substrate.

Genesis AI's own writing on Genesis World 1.0 makes a similar argument from the engine side: trustworthy simulation requires every layer to match reality, from hardware system identification to control timing to rendering precision. We agree. Our point is one level up: even a perfectly faithful general-purpose engine still needs a vertical-specific layer of physics, geometry, SOP encoding, and operator benchmarks to be useful for evaluating industrial policies. That vertical-specific layer is what we are building.

What the evaluation harness actually does

The simulator is the substrate. The harness is the engineering surface.

The harness is the closed-loop scoring system that takes a candidate VLA policy, runs it across a representative distribution of vertical-specific scenarios in the simulator, and produces a scored report. Same task, same plant geometry, same SOP gates, run N times for the policy and run N times by real operators captured from the same plant.

The metrics that matter are not "did the robot move." They are:

• Task completion rate. Did the policy reach the SOP's defined end state.
• SOP compliance rate. Did the policy hit every required substep in order, with the correct gating, within the permitted thresholds.
• Time vs. operator baseline. How does the policy's wall-clock compare to the human operator's.
• Intervention rate. How often during simulated rollouts does the policy require a hypothetical human intervention or a safety guardrail trip.
• Safety event count. How many simulated runs hit a hazard that an operator would have avoided.

Each of these is scored against the human distribution from the same plant. A policy that completes the task 92 percent of the time but compliance-passes only 71 percent is not yet deployable. The harness surfaces that gap explicitly. The lab uses it to iterate.

The harness's most important property is throughput. Real-world evaluation in industrial robotics is brutally slow: hundreds of operator hours, single robot stations, plant access windows that are weeks apart. With a working sim-and-eval harness, a lab can run thousands of evaluation rollouts overnight on compute. Iteration cycles drop from weeks to hours. That throughput unlock is what changes development economics.

Why the combination compounds

A simulator without a harness is a sandbox. A harness without a simulator is a static benchmark. The pair, joined, creates a flywheel.

Walk through it slowly.

1. Phase 1: capture seeds the simulator. Trekion's data layer produces episodes with synced process context. Those episodes feed the simulator's plant geometry, calibrate its physics, populate its SOP graphs, and provide the operator benchmark distribution.
2. Phase 2: the harness scores policies against the operator distribution. A foundation lab brings their candidate VLA policy. The harness runs it. Reports the per-substep score gap.
3. Phase 3: gaps drive the next round of capture. The harness exposes the specific tasks, SOP steps, and plant states where policies are weakest. The next round of capture targets exactly those gaps, in those workflows, on those plants. The captured episodes feed back into the simulator and the operator benchmark.
4. Phase 4: the simulator gets sharper, the harness gets stricter. Each iteration tightens calibration, expands scenario coverage, and improves the realism of the score. New entrants trying to replicate would need to rebuild every layer from scratch, in parallel.
5. Phase 5: the verticalized flywheel attracts deployment. Once a lab's policy clears the harness for a vertical, the operator side has a defensible signal that the policy is plant-floor ready. Deployment partnerships flow from that signal. Trekion sits at the center of the flow.

The defensibility comes from the joining, not the parts. Anyone can build a simulator. Anyone can write evaluation metrics. The thing that takes years to replicate is the joined version where the simulator's calibration is fed by real captured episodes from a specific vertical, and the harness's ground truth is operator distributions from the same plants the policies will deploy in.

Why one vertical first

The flywheel is per vertical. The physics that matters in a refinery is not the physics that matters on a construction site. The SOPs are different. The operator benchmarks are not transferable.

We are evaluating three verticals with design partners: discrete manufacturing, construction and inspection, and oil and gas. The vertical that pulls hardest gets the simulator and the harness first. Then it gets the deployment partner relationship.

This is the wedge logic. Generalist physical AI is a horizon. The economics of getting there run through verticals first, depth before breadth. The labs that ship industrial policies fastest will be the ones whose policies clear an evaluation harness somebody else built. The labs that wait for a perfect generalist simulator will be late.

What this means for foundation labs

Three implications, in order of impact.

Data sourcing is not enough. Pick a sim-and-eval partner per vertical. If you are training a VLA for refineries, the model is only as good as the simulator and harness it gets evaluated against. Choose now.

Evaluation throughput is the binding constraint, not training compute. Most VLA programs hit the wall on evaluation, not on training. A working sim-and-eval pipeline lifts that wall. Account for it in your roadmap.

The vertical-specific flywheel is where deployment partnerships are won. When the harness for a vertical exists, the lab that clears it first holds the deployment seat. The race is for the first cleared policy in a vertical, not for general capability.

If you are building a VLA for industrial deployment, talk to us about which vertical we are committing to and what the harness will look like.