A founder reflection on manufacturing ontology, operational control, and why enterprises should be careful not to surrender their own reality to the AI market.
A few years ago, while I was still at Apple, I spent a lot of time thinking about manufacturing digital transformation. This was before the market became obsessed with foundation models, agentic workflows, token pricing, and AI copilots. The language then was different. People talked about smart factories, digital twins, industrial IoT, predictive maintenance, scheduling, quality control, energy optimization, and carbon management.
After looking at enough industrial systems, I kept coming back to one uncomfortable conclusion: factories did not really lack data. They lacked a shared language for describing how the business actually worked.
A production line has machines, stations, operators, work orders, materials, batches, process steps, exceptions, maintenance records, quality events, supplier delays, energy usage, and approval decisions. All of those things exist in the real world, and all of them usually exist somewhere in software. The problem is that they rarely exist as one coherent model. ERP has one version of reality. MES has another. SCADA has another. Spreadsheets fill the gaps. Operators carry the missing context in their heads. By the time a company tries to transform the operation, it is often trying to automate across a fragmented map of its own business.
That was what pushed me toward manufacturing ontology.
I did not think of ontology as an academic exercise. I thought of it as a practical operating language for traditional industries. If a factory can describe its assets, lines, processes, constraints, events, and actions in a consistent way, then software can stop treating the company as disconnected tables and start treating it as an operating system. Scheduling, quality, carbon tracking, maintenance, energy optimization, and supply chain visibility become easier to connect because they are no longer separate data projects. They become different views of the same business reality.
At the time, this was not a fashionable thing to say. The market rewarded dashboards, SaaS wrappers, and transformation slides that made operations look cleaner than they were. Real industrial digital transformation was much messier. You had to understand where OT and IT systems disagreed, why one plant could not reuse another plant's solution, why site-level workarounds mattered, why data lineage broke, and why the people closest to the process often trusted their own notebooks more than the corporate system of record.
There was also a human side to it. Large organizations do not fail to transform only because the technology is hard. They also fail because ownership is unclear, incentives are misaligned, and people protect their small territories. A good idea can die quietly if it threatens the wrong workflow, exposes the wrong dependency, or requires too many teams to admit that the current process is held together by custom scripts and personal memory. I learned that lesson early.
When Alex Karp recently pushed ontology back into the enterprise AI conversation, I paid attention. Whatever someone thinks about Palantir, the underlying argument is important. Enterprise AI cannot be built only around access to stronger models. A model can reason, summarize, generate, classify, and assist. But it does not automatically understand the operating structure of a company. It does not know which object is business-critical, which action is reversible, which permission is missing, which approval path matters, or which evidence a customer, auditor, or regulator will ask for later.
Ontology becomes more than a data model at that point. It becomes the boundary between generic intelligence and operational intelligence.
A company that owns its ontology owns more than its data. It owns the language through which AI understands the business. It owns the nouns and verbs of its own operation. It can define what a customer means, what a machine means, what a shipment means, what a maintenance event means, what a production exception means, and what kind of action is allowed against each of those objects.
Without that layer, AI becomes a very expensive guessing machine attached to fragmented systems.
I think this is one of the reasons the current AI market feels so strange. On one side, the technology is genuinely impressive. On the other side, the commercial narrative is often ahead of the operational reality. Every product is agentic. Every workflow is autonomous. Every company claims to be AI-native. But enterprise buyers do not live inside demo videos. They live inside procurement reviews, security exceptions, legal constraints, system permissions, production incidents, messy integrations, and business processes where the cost of a wrong action is not theoretical.
A chatbot can be wrong and embarrassing. An agent can be wrong and expensive.
Manufacturing makes this obvious. A production line does not care about a benchmark. A supplier delay does not care about a keynote. A quality incident does not care how impressive the model looked in a product launch. The physical world only cares whether the system understands enough of the operation to support the right action, block the wrong action, and leave behind enough evidence for the organization to know what happened.
That lesson stayed with me.
It also shaped how I think about OSuite now. My early work around manufacturing ontology was about giving software a better representation of the business. OSuite is about the next layer: once AI agents can understand more of the business, how do we govern what they are allowed to do?
These two problems are connected. Ontology gives AI the business structure. Governance gives AI the permission structure. Runtime control gives AI the action structure. Evidence gives AI the accountability structure. If one of those layers is missing, the enterprise is not really deploying controlled AI. It is connecting a powerful system to operational surfaces and hoping the surrounding organization absorbs the risk.
A serious agent system should not only answer questions. It should understand the business object it is touching, the consequence of the action it proposes, the policy boundary around that action, the person or system with authority, and the evidence required after execution. Otherwise, human oversight becomes a phrase in a policy document rather than a control that actually exists at runtime.
This is also why I am cautious about the idea that the future of enterprise AI belongs entirely to frontier model providers. Models matter, and they will keep getting better. But enterprises should be careful about confusing model access with operational control. The model can be rented. The infrastructure can be bought. The cloud can be chosen. But the operating language of the business should not be casually surrendered.
If a vendor owns the abstraction through which your business is understood, the vendor owns more than a software layer. It owns part of your decision structure.
Some companies will be comfortable with that. Many should not be.
For low-risk productivity work, the tradeoff may be acceptable. For finance, manufacturing, healthcare, logistics, compliance, public sector, and critical operations, the question becomes much more serious.
These questions sound less exciting than model benchmarks, but they are the questions that determine whether AI becomes enterprise infrastructure or another expensive wave of software disappointment.
Looking back, I do not see my manufacturing ontology work as a separate chapter from what I am building now. I see it as the beginning of the same thesis. Traditional industries do not need more hype. They need systems that understand their reality, respect their authority structure, and make action accountable.
That was true before the current AI boom. It is more true now.
The next phase of AI will not be won by companies that merely consume intelligence. It will be won by companies that can describe their own reality clearly enough for intelligence to act inside it without taking control away from the people responsible for the outcome.
Request enterprise access and send your first governed decision today.
