Executive summary

Our 2026 field study found that the average multi-site operator takes 71 days to convert a meaningful signal into an executive-level action. The bottleneck is not the data and not the systems, but the absence of a layer above the systems that can reason across them. This paper describes that layer's spine — the ontology.

The thesis is simple. Every operational decision worth automating touches between three and nine entities: a person, a shift, a work order, a machine, a batch, a supplier, an incident, a document. Those entities live in different systems, with different IDs and different schemas, and the work of fusing them is currently done by an expensive human sitting in front of three browser tabs. Until that work is done in software, the decision layer cannot exist.

We propose a concrete starting schema: eighteen core object types across six domains, with explicit relationship cardinalities and a well-defined extension grammar for industry-specific entities.

Why operations needs a shared ontology

The dominant pattern in operational software for the last two decades has been point-to-point integration. The PMS talks to the FSM. The HRIS talks to payroll. The EHR talks to the lab system. Each integration is bespoke, brittle, and shaped by the schemas of its endpoints, not by the questions the operator wants to answer.

The result is a graph of pipes that resists the only thing operations ever asks of it: cross-system reasoning. When an operator wants to know whether a flagged shift overlaps a credentialed-but-fatigued worker on a regulated line running a high-risk batch, the answer requires four systems and a human. The systems are not at fault. The integration pattern is.

An ontology inverts the pattern. Instead of pipes between schemas, the operator owns one schema, and every system contributes to it through ingest. The decision layer reads against the ontology, not against the source systems. Every cross-system question becomes a traversal in a single graph. The 71-day latency in our field study collapses, in our deployments, to minutes.

The eighteen-type core, six domains, one schema

Across forty-three operator interviews and six pilot deployments, we converged on a core ontology of eighteen object types, organized into six domains. Each type appeared in five or more deployments, each has at least two cross-system relationships, and each can be populated from a CSV in under thirty seconds.

  • Workforce: Person, Shift, Department, Certification, Fatigue Score
  • Operations: Line, Machine, Work Order, Batch Run, Downtime, Maintenance Task
  • Supply: Material Batch, Supplier
  • Quality: Quality Check
  • Safety: Safety Incident
  • Audit: Decision, Anomaly, Document

The six-domain split tracks the actual organizational seams in operating companies. Workforce is owned by HR and operations together. Operations is owned by the line. Supply is owned by procurement. Quality and Safety are owned by the regulator-facing functions. Audit is owned by leadership and, when it goes badly, by counsel. The ontology should respect those seams, not flatten them.

Every relationship in the core has an explicit cardinality, a verb, and a direction. A Person holds a Certification (1:N). A Shift covers a Line (N:1). A Work Order blocks a Batch Run (N:1). A Decision cites a Document (N:N). The verbs are not decoration; they are how the decision layer constructs the explanation it owes the operator on every recommendation. An ontology without verbs is a star schema, not a substrate.

Seven industry extensions, one extension grammar

Eighteen types covers the operating spine. It does not cover the objects that distinguish a hospital from an airline from a fulfilment centre. Those live in industry extensions, and the extensions are where the platform either earns its keep or fails the operator.

Healthcare

Adds Patient Encounter, Clinical Order, Care Pathway, and Adverse Event. Binds to Person (clinician) through Certification, to Work Order through Order Type, and to Document through HIPAA-bound chart references.

Aviation

Adds Flight, Aircraft, Crew Pairing, and MEL Item. Binds to Shift through Crew Pairing, to Maintenance Task through Aircraft, and to Safety Incident through MEL Item. Carries dispatch-reliability as a runtime constraint.

Manufacturing

Adds Bill of Materials, Tooling, OEE Window, and Yield Bin. Binds to Batch Run through BOM and to Quality Check through Yield Bin.

Logistics

Adds Shipment, Route, Vehicle, and Dock Event. Binds to Work Order through Shipment, to Person (driver) through Certification, and to Anomaly through Dock Event for cross-modal disruption tracking.

Retail

Adds Stock-Keeping Unit, Store Visit, Promotion, and Shrink Event. Binds to Material Batch through SKU lineage and to Anomaly through Shrink Event. Drives staffing-to-traffic and loss-prevention loops.

Hospitality

Adds Reservation, Room Status, Service Recovery, and Compliance Lapse. Binds to Shift through Service Recovery and to Document through Compliance Lapse.

Defence

Adds Mission, Asset, Sustainment Order, and Authorization. Binds to Document through Authorization and to Person through Certification (clearance, training currency). Designed to be the spine of a Government-of-Canada-grade decision system.

Governance is a lens, not a feature

Every operator we interviewed had a regulator. None of them treated compliance as a separate system. They treated it as a property the operating system was supposed to have, and were frustrated that it never did.

The ontology makes governance addressable in a way an integration stack cannot. A framework lens — HIPAA, ISO 42001, NERC CIP, OSFI E-23, SR 11-7, the Government of Canada research-security trend cards — is a binding from one or more object types to a set of concerns and safeguards. The lens is not a checklist. It is a runtime constraint.

When a healthcare operator runs a recommendation that touches Patient Encounter and Document, the platform resolves HIPAA and HTI-1 and refuses to surface the recommendation without the consent chain attached. When a defence operator runs a recommendation that cites a model trained on dual-use data, the platform resolves the relevant research-security trend cards and surfaces the authorization required. The lens is the same code path the platform uses for any other constraint; the only difference is who wrote it.

Counterfactual outcome attribution

An ontology that records what happened is structured. An ontology that records what would have happened without the platform is auditable. The difference is the dollar swing the operator can credit, or blame, on the decision layer.

Every executed action in our runtime records four things: the entities it touched, the rule that proposed it, the baseline counterfactual against which its impact is measured, and the reversibility window during which the operator can undo the outcome. The structure forces the platform to be honest — a recommendation that cannot articulate its counterfactual is not allowed to ship. And it gives the operator a coherent story to tell their auditor, their regulator, and their CFO. Every quarter we close, the dollar swing attributes to a specific model, a specific rule, and a specific class of counterfactual. The ledger replaces the slide.

Companion papers

This is the methodology spine of MAIA's 2026 research series. The framing comes from The State of Operational Decision-Making. The defence extension is specified in Multi-Domain Fusion at Sovereign Scale. The reproducible measurement is the Decision Latency Benchmark.