The operational ontology.

Why operations needs a shared ontology, not another integration.

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 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. The choice of eighteen is not arbitrary: each type appeared in five or more deployments, each type has at least two cross-system relationships, and each type can be populated from a CSV in under thirty seconds.

The six-domain split matters because it 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.

We define seven extensions, each of which adds two to four object types and binds them to the core through declared relationships. The extensions are not vertical products. They are schema modules.

1. 01
   Healthcare

   Adds Patient Encounter, Clinical Order, Care Pathway, and Adverse Event. Binds to Person (clinician) through Certification (license, credential), to Work Order through Order Type, and to Document through HIPAA-bound chart references.
2. 02
   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.
3. 03
   Manufacturing

   Adds Bill of Materials, Tooling, OEE Window, and Yield Bin. Binds to Batch Run through BOM and to Quality Check through Yield Bin. The extension carries the ontology MAIA already runs in production for plant operators.
4. 04
   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.
5. 05
   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.
6. 06
   Hospitality

   Adds Reservation, Room Status, Service Recovery, and Compliance Lapse. Binds to Shift through Service Recovery and to Document through Compliance Lapse. Runs the same fatigue-and-fairness loop healthcare uses, with different verbs.
7. 07
   Defence

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

The grammar across the seven is identical. Each extension declares its types, declares its bindings to the core, and declares which governance lenses apply. Onboarding asks one question, what do you operate, and selects the matching extension. The platform never ships an empty schema; it ships a populated one, with the operator’s first CSV seeding the rest of the org around it.

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 (Deep Learning for Health Decision Systems, Cognitive Computing), 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 + 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.

We currently bind seven framework lenses by default and exposed three more as opt-in. We expect this list to grow with each industry deployment, and we explicitly designed the lens binding to be additive: a lens cannot relax an existing safeguard, only add new ones. The ontology accumulates governance the way it accumulates entities.

Counterfactual outcome attribution makes the ontology auditable.

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 counterfactual is one of three kinds. A threshold-bypass counterfactual answers what would have happened if the fatigue threshold had not been raised. A predictive counterfactual answers what the model expected without the intervention. An optimisation counterfactual answers what the previous policy would have routed.

The structure has two consequences. First, it forces the platform to be honest: a recommendation that cannot articulate its counterfactual is not allowed to ship. Second, it gives the operator a coherent story to tell their auditor, their regulator, and their CFO. Every quarter we close, we can attribute the dollar swing to a specific model, a specific rule, and a specific class of counterfactual. The ledger replaces the slide.