Beyond Data Contracts: Why Your Industrial Knowledge Graph
Needs an Operational Ontology Contract

What a Data Contract Actually Gives You

Data Contracts — popularized by Andreessen Horowitz, Spotify, and the modern data mesh movement — are agreements between data producers and consumers about the shape and quality of data. A typical Data Contract specifies: field names, data types, nullability, cardinality constraints, freshness SLAs, and ownership.

This is genuinely valuable. A well-enforced Data Contract prevents the class of failures where a pipeline breaks because a field changed from string to integer without warning, or where a downstream model receives a NULL in a field it expected to always be populated.

But a Data Contract operates at the syntactic level. It answers: "Is this data structurally valid?" It cannot answer: "Does this data mean what we think it means?", "Is this meaning consistent across the six systems that contribute to this field?", or "Can an AI agent legally infer X from Y given the domain axioms we have declared?"

For a transactional data pipeline, syntactic validity is often sufficient. For an industrial knowledge graph that feeds AI reasoning over physical assets, processes, and decisions, it is not.

The Industrial Knowledge Graph Problem

Consider a manufacturing organization building a knowledge graph over its physical assets — turbines, compressors, heat exchangers, maintenance records, sensor streams. The graph integrates data from a SCADA system, a CMMS, an ERP, and real-time IoT feeds.

Each of these sources uses different terminology for the same concepts:

• The SCADA system calls it inlet_temp_C. The CMMS refers to TempEntréeKelvin. The ERP has T_Input (unit unknown).
• The SCADA interprets "failure" as a sensor alarm threshold crossing. The CMMS defines "failure" as a work order of type CORRECTIVE. The ERP considers "failure" any unplanned downtime event.
• In French maintenance documentation, panne, défaillance, and avarie are used interchangeably, but they carry distinct legal and insurance meanings under Moroccan industrial law.

A Data Contract enforced at the ingestion boundary can guarantee that inlet_temp_C arrives as an xsd:decimal in the range [−40, 800]. It cannot guarantee that the temperature is being measured at the same physical location across all three sources, that the calorific relationship to thermalLimit is encoded in the graph, or that an AI making maintenance recommendations knows that a temperature reading above ThermalThreshold is asymmetrically related to ComponentDegradation (i.e., the relationship is not symmetric — degradation causes temperature rise, but not every temperature rise implies degradation).

This is where the Data Contract ends and the Operational Ontology Contract begins.

The Three Pillars of an OOC

Pillar 1 — Meaning Is Native, Not Translated

In multilingual industrial organizations — common across North Africa, the Gulf, Southeast Asia, and any EU-regulated sector — concept definitions are never safely "translated" from one language. Translation implies a privileged source language. It means that the English definition is the "real" one, and every other language is derived from it.

An OOC stores semantic definitions as native multilingual literals using RDF language tags. Every concept carries its definition directly in Arabic, French, English, and any other required language — not as a translated string, but as a first-class, independently maintained semantic annotation. This is not cosmetic. When a French-speaking maintenance engineer and an Arabic-speaking compliance officer query the graph with different terms, they reach the same formal OWL class through SKOS altLabel alignment — not through a translation function.

Pillar 2 — Logical Rigor Enables AI Inference

OWL 2 property characteristics are not metadata annotations. They are axioms that a reasoner uses to derive new facts. When you declare a property as owl:TransitiveProperty, you are not labeling it — you are telling the reasoner: "if A relates to B and B relates to C, then A relates to C, and you may materialize that triple."

This matters for industrial graphs because physical relationships in the real world have logical structure:

• isPartOf is Transitive — if the impeller is part of the pump, and the pump is part of the compression train, then the impeller is part of the compression train.
• isDirectSupervisorOf is Asymmetric — if A supervises B, B does not supervise A.
• hasPrimarySerialNumber is Functional — an asset has exactly one, not multiple, primary serial numbers.
• isMaintainedBy and maintainsAsset are Inverse — declaring one direction is sufficient; the graph infers the other.

An AI agent that queries a SPARQL endpoint backed by an OWL-aware knowledge graph can ask: "Find all components whose degradation risk exceeds threshold X, where degradation risk is defined by transitivity over the isPartOf chain and inverse propagation through thermalStressAffects." Without these axioms declared in the ontology and compiled into the graph, the agent cannot make this inference. It must guess — or hallucinate.

Pillar 3 — Runtime Enforcement Is Machine-Actionable

SHACL shapes derived from an OOC are not documentation. They are executable constraints. In ArcaQ, the Brain ingestion agent validates every RDF entity against the SHACL shapes compiled from the relevant OOC before the entity is written to the Jena graph.

A SHACL shape in an OOC can declare: "every instance of ooc:TurbineComponent must have exactly one serial_number matching the pattern ^[A-Z]{2}-[0-9]{6}$, and its operationalStatus must be one of {OPERATIONAL, STANDBY, UNDER_MAINTENANCE, DECOMMISSIONED}." If an incoming data record violates this, it is rejected at the boundary with a structured validation report — not silently accepted and later causing silent inference failures.

This transforms the OOC from a governance document into a live enforcement mechanism. The contract is not a PDF in a wiki. It is a compiled artifact that the graph enforces automatically.

What an OOC Looks Like in Practice

ArcaQ's OOC format is a structured YAML file that the platform compiles into OWL TTL + SHACL TTL. Here is an excerpt from an industrial equipment OOC:

metadata:
  id: ooc-equipment-turbine-2026-v1
  title: Industrial Turbine Component Ontology
  domain: industrial-equipment
  version: "1.0.0"
  status: approved
  labels:
    en: Industrial Turbine Component
    fr: Composant Turbine Industrielle
    ar: مكوّن التوربين الصناعي

semantics:
  namespace: https://arcaq.com/ontology/industrial/turbine#
  classes:
    - id: TurbineComponent
      labels:
        en: Turbine Component
        fr: Composant de Turbine
        ar: مكوّن التوربين
  object_properties:
    - id: isPartOf
      domain: TurbineComponent
      range: TurbineComponent
      characteristics: [Transitive, Asymmetric]
    - id: isMaintainedBy
      domain: TurbineComponent
      range: MaintenanceTeam
      characteristics: [InverseOf: maintainsAsset]
  datatype_properties:
    - id: operationalStatus
      range: xsd:string
      allowedValues: [OPERATIONAL, STANDBY, UNDER_MAINTENANCE, DECOMMISSIONED]

data_integrity:
  shapes:
    - target: TurbineComponent
      constraints:
        - property: serial_number
          minCount: 1
          maxCount: 1
          pattern: "^[A-Z]{2}-[0-9]{6}$"
          severity: Violation
          message:
            en: Serial number must match format XX-NNNNNN
            fr: Le numéro de série doit correspondre au format XX-NNNNNN

versioning_control:
  policy: STRICT
  breaking_change_requires:
    - four_eyes_approval
    - graph_migration_plan

interoperability:
  standard_alignments:
    - standard: ISO-10303-239
      mapped_class: TurbineComponent
      relationship: skos:exactMatch

When ArcaQ compiles this OOC, it generates:

• An OWL Turtle file — declaring owl:TransitiveProperty and owl:AsymmetricProperty axioms for isPartOf, an owl:oneOf enumeration for operationalStatus, and owl:inverseOf linking isMaintainedBy ↔ maintainsAsset. Each class and property carries rdfs:label annotations in all three languages.
• A SHACL Turtle file — declaring a sh:NodeShape for TurbineComponent with a sh:PropertyShape enforcing the serial number pattern, with multilingual sh:message literals.

Both artifacts are loaded into Apache Jena. From that point, every entity ingested through the Brain agent is validated against the SHACL shapes, and every SPARQL query over the graph benefits from the materialized OWL inferences.

OOC and OLM: The Enforcement Arm of Ontology Governance

An OOC does not exist in isolation. It is a governed artifact within ArcaQ's Ontology Lifecycle Management (OLM) system. Just as a software library has a version, a changelog, and a deprecation policy, an OOC has a state machine:

Only OOCs in APPROVED state are compiled and enforced in the production graph. An AI agent querying ArcaQ's SPARQL endpoint is automatically scoped to approved graphs — it cannot accidentally reason over a draft ontology that has not been validated.

Breaking changes — altering a property's domain, range, or characteristics — require four-eyes approval and a graph migration plan before they can transition to APPROVED. This prevents the scenario, common in uncontrolled ontology environments, where a silent class rename breaks hundreds of downstream SPARQL queries and invalidates months of accumulated AI reasoning.

When to Use a Data Contract. When to Use an OOC. When to Use Both.

Use a Data Contract when:

• Your pipeline concern is structural: types, nullability, freshness.
• Your consumers are SQL-based systems or ML pipelines that treat data as tabular.
• Your governance boundary is at the table or column level, not the concept level.

Use an OOC when:

• Your data feeds a knowledge graph consulted by AI agents for reasoning.
• Your domain involves multilingual terminology where translation is legally or operationally insufficient.
• Your AI needs to make inferences that depend on logical property characteristics (transitivity, asymmetry, functional constraints).
• You need runtime enforcement at the RDF level, not just at ingestion schema validation.
• You operate in a regulated sector (energy, defense, healthcare, finance) where ontology changes require auditability and four-eyes approval.

Use both when:

• Your raw data arrives from operational systems (SCADA, CMMS, ERP) through a Data Contract—enforced ingestion pipeline.
• That data is then transformed into RDF and loaded into a knowledge graph governed by OOCs.
• This is the ArcaQ architecture: Data Contracts at the source boundary, OOCs at the semantic layer.

A Data Contract ensures your turbine sensor readings arrive in the right format. An OOC ensures the knowledge graph knows what those readings mean, how they relate to thermal degradation models, and how an AI may legally infer maintenance urgency from them — in French, Arabic, and English simultaneously.

Implementing OOCs in ArcaQ

ArcaQ ships with an OOC Registry — a governed catalog of all Operational Ontology Contracts active in the platform. For each domain (industrial equipment, financial instruments, organizational hierarchy, process engineering), a team of ontology engineers maintains the canonical OOC.

The implementation workflow is:

1. Author — Write the OOC YAML in the platform's editor or upload an existing YAML. The registry validates structure on upload.
2. Compile — The POST /api/v1/ooc/contracts/{id}/compile endpoint generates OWL TTL (T-Box) and SHACL TTL (A-Box shapes) from the YAML. No external tooling required.
3. Validate — The POST /api/v1/ooc/contracts/{id}/validate endpoint runs the compiled SHACL shapes against the current graph population and returns a structured violation report.
4. Submit for review — The OOC transitions to IN_REVIEW. Designated validators receive a notification. Four-eyes approval is required for breaking changes.
5. Approve — The compiled OWL and SHACL artifacts are loaded into the Jena graph. Enforcement begins immediately for all subsequent ingestion.
6. Export — The OOC can be exported as YAML (human-readable), Turtle (machine-processable), or JSON-LD (API-consumable) at any time.

The entire OOC lifecycle is accessible through ArcaQ's dashboard — no CLI, no external ontology editor, no manual TTL authoring required. The YAML is the source of truth. The OWL and SHACL are derived artifacts.