Making a world model useful in a specific enterprise setting tends to require a different substrate than the one document retrieval was built for.
That is a strategic inference, not a universal technical requirement, and I want to say so clearly. Some world-model use cases will run on general pretrained systems and never touch a customer's operational data. Some will need only lightweight domain adaptation. But setting-specific adaptation and evaluation both depend on evidence from the setting: what was observed, which action was taken, and what happened next. Meta's V-JEPA 2 experiments, NVIDIA's vendor-reported Cosmos 3 post-training pattern, and manipulation benchmarks such as RoboWM-Bench point in that direction without establishing one universal architecture.
Getting the difference clear is the whole subject of this essay.
What documents do, and what they leave out
Documents are the residue of human thinking about the business. Policies, procedures, incident write-ups, engineering standards, contracts, meeting notes, emails, decision memos. Together they encode the collective judgment of the organization, and that is genuinely valuable. It is why the document-retrieval stack, however unglamorous, has become the workhorse of enterprise AI.
What documents leave out is a faithful, machine-readable record of what the physical system actually did. They can carry a story about what it did, filtered through what someone thought was worth writing down, days after the fact. That is a different data product, and it is not accidentally different.
Documents optimize for human readability. Operational records optimize for machine learnability and evaluation. The two goals are not opposed, and they do not cover for each other. This is where a lot of "we already have a data lake" arguments run out of substance.
Document retrieval is not becoming irrelevant. It remains the substrate for the language layer, including the language layer sitting above a world-model rehearsal. The claim is only that document retrieval is insufficient for evolving state and dynamics, and that treating the two problems as the same one — which several vendor pitches implicitly do — tends to produce pilots that look convincing and fail to adapt to the customer's specific setting.
What a linked operational record actually contains
Strip away the labels — "digital twin," "physical AI platform," "industrial AI foundation" — and the substrate that keeps appearing in setting-specific adaptation work has four elements. Every one is normal operational data. What is unusual is that they are linked to each other tightly enough to be learnable.
Observations. What did the system see or measure at this moment? Sensor readings, camera frames, position and pose data, event logs, whatever mixture the environment provides. Rich enough to reconstruct the situation, dense enough to sample the transitions, honest enough to reflect the messiness of the actual environment rather than a cleaned-up executive view of it.
Operating conditions. What was the ambient state at that moment? Weather, temperature, load, throughput, shift, product mix, mode of operation, upstream constraint. Downstream behavior often depends on conditions that never appear in a camera frame.
Actions. What did the system do? Not what the operator intended, not what the plan called for. What was actually commanded, at what time, with what parameters. If you have ever tried to reconstruct why a shift went badly from a mixture of human recollection and dashboard screenshots, you have felt the absence of this.
Outcomes. What happened next? The next observations, the next readings, the actual result of the action taken, and — where possible — the human-labeled or system-labeled judgment of whether the result met the goal.
None of the four is exotic. Every one of them exists inside some part of most industrial organizations. The problem is that they are typically produced for different tools, sampled at different rates, keyed differently, and often owned by teams that do not know each other. Linking them into a joined, time-synchronized record is a data-engineering project more than a modeling project, and it is where more of the actual money is likely to have to be spent than the current AI narrative tends to suggest.
World models
The scarce asset is a linked record of reality
Observations become useful training and evaluation material when they remain connected to conditions, actions, and outcomes.
A four-part linked record connects observations, operating conditions, actions, and outcomes. Examples include video and geometry, telemetry and setpoints, commands and interventions, and resulting success or failure.
- 01Observationvideo, image, sound, geometry
- 02Operating conditiontelemetry, load, setpoint, context
- 03Actioncommand, intervention, control input
- 04Outcomesuccess, failure, incident, rework
Rights, provenance, privacy, retention, portability
The engineering side of a linked operational record gets most of the attention. The governance side is where more of the pain shows up in production.
Rights. Who owns the data, and under what terms may it be used to adapt or evaluate a model? Operational data is often produced in partnership — customers, suppliers, integrators, regulators — and the rights to reuse it for AI adaptation are frequently unclear in the contracts under which it was originally collected. Fixing that once, at scale, is cheaper than fixing it per pilot.
Provenance. Where did each observation come from, and can that lineage be traced through the model that used it? Provenance turns a data lake into a source of truth. Without it, "the model was trained on our data" is a claim nobody can audit.
Privacy. Human operators appear in camera feeds. Customers appear in transaction logs. Sensor data can indirectly identify people through routine patterns. Retrofitting document-style privacy controls to this substrate does not work; a well-designed operational record builds privacy engineering into the pipeline, not layered on afterward.
Retention. How long will the record be kept, at what fidelity, under what legal and operational constraints? Rehearsal-quality data has a different retention profile than reporting data; retention decisions taken casually here become expensive later.
Portability. Can the record move — to a different tool, a different vendor, a different jurisdiction, a different tenant — without losing the properties that made it valuable? Portability is the property that keeps a customer's operational record from becoming a lock-in artifact for whichever vendor happens to be adjacent to it this year.
None of the five is a decorative concern. All five are more work than the document-retrieval substrate they will sit alongside, and none of them is unfamiliar to a mature data governance team.
Digital twins and simulators are close, and not the same
The pattern most enterprises already have that comes closest to a linked operational record is a digital twin. Manufacturing has been building these for a decade. Utilities have been building them longer. Real estate operations, port authorities, mines, hospitals, and airports all have some version.
Digital twins are useful. As commonly deployed, they do not fully substitute for what a world model tends to be adapted against, and it is worth being specific about why.
Most operational digital twins are simulation-first. They start from an engineering model of the physical system and use live sensor data to keep the simulation aligned with reality. That produces a synchronized simulator, and it is very good at answering "what does the model say is happening right now."
A learned world model, trained or adapted for a specific setting, is closer to the inverse. It benefits from the raw record of what actually happened, plentifully, whether or not the engineering model explains it, so the learned predictor can discover transitions the engineering model missed. The digital twin is a strong starting point. It is not the same product, and treating the twin alone as the training ground rather than one input alongside the observed record is a common early error.
Current systems illustrate several different data patterns. NVIDIA describes Cosmos 3 using synthetic datasets and post-training on customer data. Wayve describes GAIA-2 as an offboard scenario generator trained on real driving data. Dreamer 4 first learns a Minecraft environment from offline data, then trains an agent through imagined experience inside that learned model. These are not one architecture or one sequence. What they share is dependence on data whose actions, conditions, and outcomes are sufficiently clear for learning or evaluation.
What the CIO might usefully ask
The most common question I hear from IT leaders is whether the RAG platform their organization has spent two years standing up can be extended to physical AI. The honest answer is that it can carry the language layer, and it is insufficient for the world-model layer, because the substrates were designed for different jobs.
The more useful questions are less flattering to any single vendor.
Who owns the linked operational record? Not the digital twin, not the data lake, not the historian — the joined, time-synchronized record with the four elements above. In most organizations no one owns it end-to-end, because it has never been assembled as a single asset. Naming an owner is the first move.
Where does it live, and why? The right architecture depends on the plant, the connectivity, the latency budget, the data rights, and the regulatory frame. Central, regional, and on-premises tiers all have roles, and the split is a design decision, not a slogan. The forecast I would offer is that central and local execution grow together rather than one displacing the other.
What governance covers it? Rights, provenance, privacy, retention, and portability, applied by design. If the substrate is being assembled from scratch, this is much cheaper than adding it later.
Which vendor claims are structural and which are decorative? Vendor world-model platforms are shipping real capability, and they are also, on the same page, shipping bundles that assume the operational record exists on the customer side. Read the fine print. If the substrate is not there, the platform is a rendering engine on top of nothing.
Limitations, and the objection I take seriously
The strongest objection to this essay is one I hold some sympathy for. It goes like this: enterprises will not need to assemble their own operational records, because the foundation-model providers will pretrain world models on public and licensed video, driving footage, spatial captures, and simulation, and customers will specialize with a small amount of proprietary data. Meta's V-JEPA 2 paper is a concrete example of the pattern: pretraining on more than a million hours of video, with the V-JEPA 2-AC variant using less than 62 hours of robot video for zero-shot planning experiments. Success rates varied materially by task and object. This is roughly the pattern that made large language models work for the enterprise, and there is no strong reason to think the same pattern will not repeat for physical AI.
That objection has real weight, and I would not dismiss it. The pretrained-plus-specialized pattern is what several of the current stacks are aimed at, and pretraining is doing meaningful work. The reason I remain cautious is that specialization is where much of the operating value tends to live, and specialization for a specific physical system is exactly where the linked operational record cannot be substituted by public data. A general model of "how objects move under gravity" is broad enough to pretrain. A specific model of "how this class of package behaves on this conveyor system in this building" is not. It is the second one that runs the operation.
So the pretrained base helps, and it does not remove the need for customer-specific adaptation and evaluation data. It shifts where the need sits.
The claim I would push back on hardest is the reverse — that no substrate matters at all, and the next base model will just work on any operation without ever having seen it. That is not what the technical literature supports, and it is not, on my read, what any operator-focused vendor is telling its serious customers to plan for.
Close
Chatbots taught the enterprise how to build a retrieval layer over its documents. World models are likely, in the settings that matter, to require a different layer over their physical operations — a linked operational record of observations, conditions, actions, and outcomes, with rights, provenance, privacy, retention, and portability engineered in.
The final essay will put the layers together. Once an enterprise has both a language layer over documents and a world-model layer over its operations, the interesting design question is not which one wins. It is how they compose, and what governance should look like when decisions are being informed by predictors of both sentences and scenes.
Sources
- Wayve. "GAIA-2." March 2025. Source. Vendor-reported offboard scenario generator.
- NVIDIA. "Develop Physical AI Reasoning, World, and Action Models with NVIDIA Cosmos 3." May 2026. Source. Vendor-reported converged model family.
- Meta AI. "V-JEPA 2: Self-Supervised Video Models Enable Understanding, Prediction and Planning." Paper, June 2025. Source. Cited for the pattern of adapting on limited robot video after large-scale pretraining.
- Danijar Hafner et al. "Dreamer 4." Project and paper, September 2025. Source. Cited for training an agent inside a learned environment using offline data.
- Jiang et al. "RoboWM-Bench." CVPR Workshops 2026. Source. Evaluates manipulation world models across prediction, physical executability, and real-to-sim transfer.