The Through-Line: Ontology as Operational Substrate

Thesis

An ontology is not a documentation artifact - it is an operational substrate that lets AI agents represent world state, predict transitions, and execute actions under constraints. This single idea connects AssetOpsBench’s industrial agents, Palantir’s enterprise ontology, and the possibility of decentralized organizational control.

The control loop, animated

Everything in this series is one loop running over and over: observe the world as a graph, predict where it is going, propose an action, validate that action against constraints, execute it, and feed the result back into observation.

Observe Predict Propose Validate Act Update

The control loop never stops. Each step hands off to the next.

The loop is the unit. Change the domain (a data center, a finance org, a software team) and you change the ontology inside it, not the loop. The rest of this post is about what lives at each step.

Why this matters

Most people encounter ontologies as data models - formal taxonomies that structure information. They are filed under “knowledge management” and used by data teams to make enterprise search work better. This is the wrong framing entirely.

An ontology can be the runtime substrate for an AI control system. It can hold the current state of the world as a typed graph, support prediction of what happens next, validate proposed actions before they execute, and update itself based on the results. The coding harness architecture - four slots (model, system_prompt, tools, memory) configured into five roles - is built on exactly this premise. Every harness instance reads from and writes to an ontology store, producing ontology-native artifacts that are validated by a cascade before acceptance.

The implication is profound: once you have an ontology that describes a domain, you can build an AI control loop on top of it without writing domain-specific application code. The ontology is the application logic. Agents are the cognitive layer. The harness is the execution engine.

State as a typed graph

Every entity in a domain - a chiller in a data center, a budget line in a department, a team in an organization - is a typed node in an RDF graph. Every relationship - “chiller-9 belongs-to main-campus,” “engineering-team reports-to CTO” - is a typed edge. Every observation - a sensor reading, a KPI data point, a ticket count - is a property value on a node.

This is not metaphor. It is how the ontology store physically works. Oxigraph holds the triples. SPARQL queries them. LLMs are instruments that read subgraphs and produce ontology-native output. The provenance log tracks where every triple came from.

The benefit of this structure: you can ask any question about the domain without knowing the application code. “What assets at the main campus have had compressor-related work orders in the last 90 days?” is a SPARQL query, not a SQL join across five tables:

PREFIX org: <https://omoios.dev/org#>
SELECT ?asset ?site ?status ?wo WHERE {
  ?asset a org:Chiller ;
         org:belongs-to ?site ;
         org:status ?status .
  ?wo a org:WorkOrder ;
      org:related-to ?asset ;
      org:priority 1 .
  FILTER(CONTAINS(LCASE(STR(?wo)), "compressor"))
}

The ontology captures relationships that relational schemas struggle with (inheritance, temporal evolution, many-to-many with properties).

graph LR
    subgraph "RDF Graph - AssetOps Domain"
        C9["chiller-9<br/>rdf:type: Chiller<br/>rdf:type: Equipment<br/>belongs-to: main-campus<br/>status: degraded<br/>COP: 3.8"]:::asset
        MC["main-campus<br/>rdf:type: Site<br/>location: Building A"]:::site
        WO["WO-0427<br/>rdf:type: WorkOrder<br/>priority: 1<br/>status: open<br/>related-to: chiller-9"]:::workorder
    end
    C9 --- MC
    WO --- C9

Transitions are first-class

State changes are not events to log and forget. They are observable, classifiable, and predictable transitions between state clusters. A chiller doesn’t just have “a temperature reading” - it transitions between state clusters: normal to warning to degraded to failed. An engineering team doesn’t just have “a velocity number” - it transitions between healthy to stressed to burning-out.

The observation layer captures this by taking periodic snapshots of entity state, computing diffs between snapshots, clustering entities based on their feature vectors, and tracking movement between clusters over time. This is not batch analytics run overnight - it is a continuous process feeding into the control loop.

Trajectory prediction uses these observed transitions to forecast next states. Given that chiller-9 is in the “degraded” state cluster and has historically transitioned from degraded to failed within 72 hours 73% of the time, the predictor can flag risk. The prediction is bounded by the ontology - it can only name destination states that exist in the graph - which makes it auditable in a way that unconstrained LLM prediction is not.

Actions are functions on the graph

Every action an agent can take - schedule maintenance, approve a budget transfer, reassign a team member, escalate an incident - is a function whose signature is defined by the ontology. The function’s inputs come from the graph (the current state of the entities it affects). Its outputs are new triples written to the graph (the updated state after the action). Its constraints are enforced by SHACL shapes (the action’s preconditions and postconditions).

A typed action looks like this:

interface ActionProposal {
  type: "approve_budget";
  preconditions: { budgetStatus: "draft"; fundsAvailable: number };
  postconditions: { budgetStatus: "approved" };
  affects: { budgetLine: string }; // the graph node being changed
}

And the constraint that gates it is a SHACL shape:

org:BudgetLineShape a sh:NodeShape ;
  sh:targetClass org:BudgetLine ;
  sh:property [
    sh:path org:status ;
    sh:in ( "draft" "approved" "rejected" ) ;
    sh:minCount 1 ; sh:maxCount 1 ;
  ] .

This is the critical insight that separates an ontology-as-documentation from an ontology-as-control-surface. A read-only ontology is a dashboard. An ontology with action types is a control system. You don’t just query it - you operate on it, and the ontology validates the operation before committing the result.

In the AssetOpsBench context, the WO Agent generates work orders - but those work orders go into a CouchDB document store, not back into an RDF graph. The agents read state but don’t write it back in the same format. Closing this loop - observe to predict to act to update to observe - is the architectural gap this series addresses.

LLMs orchestrate; logic governs

The LLM-as-ontology-instrument pattern is the key to making this work safely. The LLM is fluent - it can understand a novel situation (a chiller with an unusual combination of sensor readings, a team with conflicting KPI signals) and propose a sensible action. But it is not authoritative - it cannot decide what the ontology’s types are, or whether a constraint should be relaxed.

The division of labor is:

Layer	Component	Role	Reliability
Propose	LLM (frontier model)	Generate novel actions for novel situations	~65% completion
Validate	Cascade	Filter bad proposals before they reach the graph	Near-perfect on structural validity
Govern	SHACL + OWL reasoner	Enforce type system and consistency	Deterministic
Execute	Ontology store	Write validated triples	ACID
Observe	Observation layer	Detect state changes, update predictions	Statistical

The cascade arranges these so the cheapest checks run first:

graph LR
    G[Generator Agent] -->|proposal| T1
    T1["T1: SHACL<br/>$0 / ~0ms"] -->|structurally valid| T2
    T2["T2: Embedding<br/>~$0.0001"] -->|novel| T3
    T3["T3: Haiku<br/>~$0.001"] -->|plausible| T4
    T4["T4: Opus<br/>~$0.05"] -->|accept| W[("Ontology Store")]
    T1 -.->|reject| R1[cost: $0]
    T3 -.->|reject| R3[cost: $0.001]
    T4 -.->|reject| R4[cost: $0.05]

T1 (SHACL) rejects structurally invalid proposals at zero cost. T2 (embedding similarity) filters duplicates. T3 (Haiku-class model) does a quick semantic plausibility check. T4 (Opus-class model) does deep validation with full context. Only proposals surviving all four tiers are written to the graph.

This is not a limitation on LLM capability - it is the correct architectural response to LLM fallibility. You don’t trust a calculator to define what numbers are valid. You don’t trust an LLM to define what the ontology’s constraints are. The LLM proposes; the logic disposes.

From AssetOpsBench to OrgOps

The central extrapolation of this series is that this pattern generalizes unchanged from physical assets to organizational operations. AssetOpsBench is the proof it works on assets.

AssetOpsBench (IBM Research, KDD 2026) is a benchmark for industrial AI agents: four domain agents operating across 141 scenarios on a CouchDB-backed sandbox of roughly 2.3 million sensor points, 53 FMEA failure records, and 4,200 work orders. Its agents cover the loop:

IoT Agent - ingests and reasons over time-series sensor telemetry (the observe step).
FMSR Agent - runs failure-mode-and-severity reasoning against the FMEA library (predict).
TSFM Agent - foundation-model forecasting of asset trajectories (predict).
WO Agent - generates and tracks work orders that act on the asset (act).

Its most important result is not a benchmark score. It is the ~70% completion wall: no agent architecture breaks about 70% on sustained, multi-step industrial tasks. GPT-4.1 peaks near 65% under Agent-As-Tool and 38% under Plan-Execute, against an 85% deployment threshold. Single-agent accuracy (68%) actually beats multi-agent (47%). The wall is structural, and it is exactly what the cascade + ontology-validated execution is designed to push through.

The AssetOps loop maps isomorphically onto organizational operations:

AssetOpsBench	OrgOps
Chiller (typed object)	Engineering team (typed object)
Sensor telemetry: 58C	Org telemetry: velocity -15%
FMEA record: compressor overheating	Policy: sprint velocity threshold
Work order: schedule inspection	Decision: escalate to VP
TrajFM failure analysis	Decision failure analysis

graph LR
    subgraph AssetOps[AssetOpsBench]
        A[Chiller] --> S[Sensor: 58C]
        S --> F[FMEA: overheating]
        F --> WO[Work Order: inspect]
    end
    subgraph OrgOps[OrgOps]
        D[Engineering Team] --> K[KPI: velocity -15%]
        K --> P[Policy: sprint threshold]
        P --> DEC[Decision: escalate to VP]
    end
    A -.->|maps to| D
    S -.->|maps to| K
    F -.->|maps to| P
    WO -.->|maps to| DEC

The mapping is not metaphor - it is structural. The centralized-to-decentralized path principle applies: build the centralized OrgOps system first, prove it works, then explore decentralized alternatives using Bittensor-style incentives, zkML verification, and stake-slash enforcement.

Open questions

What is the minimum viable ontology for organizational operations? (How many object types, link types, and action types before the system becomes useful?)
Can the cascade push past the 70% completion wall that AssetOpsBench exposes, or is that wall a fundamental property of current LLMs?
How does trajectory prediction stay accurate when the ontology itself is evolving?

Citations

harnesses all the way down - the coding harness architecture, cascade tier system, and ontology store (the source work for this series)
AssetOpsBench - the industrial asset control loop that proves the pattern (and exposes the ~70% wall)
Bittensor - decentralized coordination layer (the long-horizon target)
decentralized AI landscape, mid-2026 - the broader landscape of decentralized AI systems