In a decade, AI has restructured the digital economy. Software is written with models beside the developer. Documents draft themselves. Customer conversations, financial analysis, media, search — anywhere work is made of information on a screen, intelligence has arrived and compounded.

Then there is everything else. The plants, grids, pipelines, fleets, mines, ports and cities where physical value is actually produced — the majority of the world's economic output. Walk onto one of these sites and, with few exceptions, the daily reality of work is untouched by the AI revolution. An inspector still carries a paper checklist or a static form. A technician troubleshooting a machine still calls a colleague who retired last year. A control room still reconciles what the enterprise system says the plant is doing with what the plant is actually doing.

The usual explanation is that industry adopts slowly. That explanation is comfortable, and wrong. Industrial operators have been early and aggressive adopters of technology for decades — instrumentation, control systems, planning systems, historians. The physical economy is not slow. It has been waiting for an architecture that fits it.

Section 01The assumptions that don't survive contact with the field

Enterprise AI — the entire pattern of copilots, chatbots and cloud platforms — is built on a small set of architectural assumptions so universal in the digital world that nobody states them anymore. The application is always connected. The data lives in one place. The user works at a screen, with both hands free. And context is text: whatever the model needs to know can be retrieved from documents.

Physical operations break all four at once. Sites are distributed and connectivity is intermittent, bandwidth-constrained, or deliberately isolated for security. Operational data is scattered across enterprise systems, control systems, historians, and — most importantly — the physical environment itself, where much of the truth is never captured by any system at all. The people doing the work are on their feet, wearing gloves, in noise, at height, in heat. And the context that matters is not a document. It is the identity, condition, configuration and history of a specific physical asset, at a specific moment, in a specific operational state.

Any one of these constraints is an inconvenience for enterprise AI architecture. All seven together are disqualifying. This is why so many industrial AI initiatives follow the same arc: a promising pilot in a connected corner of the operation, then a stall the moment the approach meets a remote site, an offline requirement, a legacy system, or a safety case.

Section 02Why the copilot pattern can't cross the boundary

The instinctive response has been to take the pattern that worked in the digital economy — a model in the cloud, a chat interface in front of it, retrieval over documents behind it — and point it at industry. The result is a copilot that can summarize a maintenance manual but does not know which pump the technician is standing in front of, what state it is in, what was done to it last month, what it is permitted to do next, or what the rest of the system is doing right now.

The deficiency is not intelligence. Today's models are more than capable of the reasoning that field work requires. The deficiency is architectural: the model has no access to a live, trustworthy representation of the physical environment, no way to act on that environment through workflows and systems, and no way to operate when the link to the cloud disappears. Intelligence without state, actuation, and autonomy from the network is commentary.

Section 03What an architecture for the physical world requires

Start from the constraints rather than from the existing pattern, and the shape of the required architecture follows almost mechanically. It has five properties, and each one is a direct answer to a way the enterprise pattern fails.

First, an explicit model of the physical world. The architecture must hold a structured, shared representation of assets — their identity, state, relationships, capabilities and permitted actions — so that every model, application and workflow reasons about the same reality. This is the difference between AI that retrieves documents and AI that understands an operation.

Second, state that stays consistent without the cloud. That representation cannot live only in a data center. It must be distributed across devices, edge infrastructure and sites, stay usable through disconnection, and reconcile cleanly when connectivity returns. In the physical world, synchronization is not a feature. It is the ground the architecture stands on.

Third, execution where the work is. Inference, guidance, verification and decision support must run on the device in the worker's hand and the compute at the site — placed wherever the operation needs them, not wherever the vendor's cloud happens to be.

Fourth, orchestration across humans, AI and machines. Physical work is not a conversation between one person and one model. It is inspectors, technicians, supervisors, vision models, language models, enterprise systems, devices and increasingly robots — acting on the same assets. Something has to coordinate them: route the right intelligence to the right actor, keep humans in the loop for consequential decisions, handle exceptions, and capture evidence.

Fifth, a closed loop. Every inspection, intervention and outcome should flow back into the shared state, so the operation's understanding of itself — and the intelligence that runs on it — improves with every shift worked.

Section 04This is a layer, not an app

Notice what these five properties describe. Not a product for inspections. Not a copilot for maintenance. They describe an infrastructure layer — something that sits between the enterprise systems above and the workers, devices, machines and robots below, and gives everything on both sides a shared intelligence to operate on.

The digital economy went through exactly this transition. Early web applications each carried their own bespoke infrastructure until a set of shared layers — cloud, container orchestration, data platforms — abstracted the common problem and made every subsequent application radically cheaper to build. The physical economy is at the pre-platform stage of that curve: every industrial AI application today rebuilds asset context, edge deployment, offline behavior and systems integration from scratch, which is precisely why pilots don't compound.

There is one more property this layer must have, and it is not technical. Because it runs inside critical operations and holds the operational state of nationally significant infrastructure, it must be deployable under the full control of the operator — on their infrastructure, within their borders, under their governance. An intelligence layer for the physical economy that can only exist in someone else's cloud is a contradiction in terms. Sovereignty is not a compliance checkbox here; it is an architectural requirement of the category.

Section 05The wave is already breaking

Foundation models have made general-purpose reasoning available. Edge compute has made it deployable in the field. Multimodal AI has given machines eyes and ears in industrial environments. Robotics is putting more autonomous actors onto sites every year. And two decades of industrial digitalization have created the connectivity and data foundations for the layer to plug into. None of these alone creates Physical AI. Together, they make it inevitable — and they make the architecture question urgent, because the operators who lay this layer down first will compound on it while everyone else is still running pilots.

This is the conviction FormaEdge is built on: that the physical economy deserves an AI architecture of its own — asset-centric, edge-native, orchestrated, and sovereign by design — rather than a hand-me-down from the digital one. The next article in this series looks at the most consequential piece of that architecture: the orchestration layer that industrial AI is missing.

Ask an industrial technology leader what AI they have running and the list is long: a vision model checking product quality on one line, a chatbot over maintenance manuals, an anomaly detector on a compressor fleet, a pilot with smart glasses at one site. Ask what these systems know about each other and the answer is almost always the same: nothing.

Each application arrived with its own definition of the assets it touches, its own integration into the systems of record, its own approach to devices and connectivity, its own silo of results. Each one works. None of them compound. The tenth AI application costs as much to deploy as the first, because nothing the first nine built is reusable. In the digital economy, this pattern has a name — the pre-platform stage — and it always ends the same way: with the emergence of a shared layer that abstracts the common problem.

For industrial AI, the common problem is not intelligence. Models are abundant and improving on their own curve. The common problem is that nothing connects intelligence to the operation — coherently, everywhere, all the time. That connective tissue is the orchestration layer, and it is the most important unbuilt piece of the Physical AI stack.

Section 01The fragmentation is structural, not accidental

An industrial operation is already full of software. Enterprise systems hold the business view of assets and work. Operational technology holds the control view. Historians hold the time-series record. Edge devices and mobile hardware hold the field view. Workers hold — in their heads and their forms — the ground truth. And now AI models arrive holding powerful but disembodied reasoning. Seven constituencies, each with a partial picture, none with the whole.

Point-to-point integration cannot fix this, because the number of connections grows with the square of the systems involved, and every AI application added to the pile makes it worse. The only structure that has ever resolved this kind of fragmentation — in networking, in computing, in data — is a shared layer: one place where the common state lives and through which coordination flows.

Section 02What the layer must actually do

Strip away vendor language and the orchestration layer for the physical world has four functions. They are not features to be mixed and matched; they are a stack, and each one depends on the one before it.

The first function is the one the industry keeps skipping, and it is the foundation. Before intelligence can be orchestrated, the physical world has to be described: what this asset is, what state it is in, what it can do, what it relates to, what may be done to it and by whom. Crucially, this description must be declarative — a formal statement of what the world is and what is permitted, that machines can read, validate and act on — rather than logic buried in the code of individual applications. When the description of the operation lives in the applications, every new application starts from zero. When it lives in a shared declarative layer, every new application inherits it.

Software infrastructure has run this experiment before, at scale. Data centers were once operated imperatively — through scripts and human procedures that described how to change things. The transformation of the last fifteen years came from making infrastructure declarative: operators state the desired configuration of the world, and a control layer continuously reconciles reality against it. Declared state is what made automation composable, auditable and safe enough to trust with production systems. The physical world — where assets, unlike servers, cannot be destroyed and recreated — needs its equivalent even more.

The second function turns the description into something the field can trust. A model of the physical world that only exists in a cloud database is a report, not a foundation. The state must be distributed — present on the inspector's device, the site's edge infrastructure, and the enterprise systems simultaneously — and it must remain locally usable when connectivity drops, then reconcile deterministically when it returns. This is a hard, unglamorous distributed-systems problem, and it is exactly the kind of problem application vendors avoid and platform layers exist to solve once.

The third function is orchestration in the literal sense. Against that shared, synchronized state, work actually happens: procedures execute, exceptions escalate, a vision model's finding routes to a technician's checklist, a technician's observation updates the asset's state, a supervisor approves the consequential step. Humans, AI and machines stop being separate systems and become participants in one coordinated operation — with the human-in-the-loop boundary drawn explicitly, not left to each application's discretion.

The fourth function is where the models finally earn their keep. Grounded in asset state and coordinated through workflows, any model becomes operationally useful — and, just as important, replaceable. When context and orchestration live in the layer rather than the model, the operator can adopt each year's best vision, language or industrial model without rebuilding anything. Model-agnosticism is not a procurement preference; it is a structural consequence of putting the intelligence layer in the right place.

Section 03Why this layer changes the economics of industrial AI

With the orchestration layer in place, the arithmetic of industrial AI inverts. The first application — an inspection workflow, say — is deployed with roughly the effort it would take today, but it leaves behind described assets, synchronized state, an edge runtime and enterprise integration. The second application inherits all of it. So does the tenth. Applications stop being projects and start being configurations of a platform that already understands the operation.

This is also why the layer cannot be bolted on later. Every application deployed without it deepens the fragmentation it would have prevented — one more private asset model, one more integration to unwind. The orchestration layer is the rare piece of infrastructure whose value is highest when adopted earliest, which is precisely how platform positions are built.

Section 04Who should hold it

One question remains, and for operators of critical infrastructure it is decisive: where does this layer live, and who controls it? By construction, the orchestration layer holds the most complete operational picture of the enterprise that has ever existed in one system — every asset, every state, every workflow, every intervention. That picture cannot reasonably reside in an external vendor's cloud, subject to someone else's jurisdiction, roadmap and terms. The layer must deploy on the operator's infrastructure — on premises, at the edge, in private or sovereign cloud — under the operator's governance, with the operator's choice of AI models.

FormaEdge is building the orchestration layer this way, from first principles: a declarative model of the physical world, distributed state that survives the field, execution that coordinates humans, AI and machines, and intelligence grounded in operational reality — deployable wherever the operation requires. The category will be defined by whoever builds this layer credibly. We think it should be built where the physical economy actually lives, and owned by the operators who run it.