Ontology as the Semantic Control Plane for Agent Fact Systems

Ontology as Semantic Control Plane

In knowledge engineering, an ontology is a precise description of objects, relationships, constraints, and inferable boundaries of a domain. Placed between the fact layer and the action layer, the ontology (or semantic control plane) constrains how different agents and systems interpret the same fact.

One Edge Is Not Enough

RDF expresses a statement as a subject‑predicate‑object triple, e.g.: Brand A --has_payee--> Company B In real business a single edge hides at least five questions:

Are the two ends the same stable object or just similarly named?

What is the business meaning of the predicate, and can it be swapped with another relation?

When does the relationship become effective and when does it expire?

Which document provided the relationship, and has it been verified?

Which queries and actions are authorized to consume it?

W3C’s RDF 1.2 draft notes that the abstract data model is timeless; time, version, and source must be modeled explicitly.

A concrete claim record might look like:

{
  "claim_id": "claim-20260808-001",
  "subject_id": "brand:brand-a",
  "predicate": "has_payee",
  "object_id": "entity:company-b",
  "valid_from": "2026-05-18",
  "valid_to": null,
  "source_ref": "document:vendor-onboarding-2026-05-18#page=4",
  "status": "candidate",
  "schema_version": "[email protected]"
}

The status field drives the lifecycle: candidate means the model suggested the claim; after entity disambiguation, relationship validation, and optional human review the status becomes published. If the source is later found erroneous the status changes to retracted, preventing silent overwrites.

Four‑Layer Architecture

To keep responsibilities separate the system can be organized into four layers:

Evidence Layer : store original text and context (contracts, onboarding forms, attachments, approval records).

Fact Layer : store candidate and published claims (payee entity, validity period, source reference).

Semantic Control Plane : define types, relations, constraints, and inference boundaries (e.g., has_payee – subject type, required evidence, multi‑value rules).

Action Layer : handle permissions, policies, approvals, and side‑effects (whether payment is allowed, audit trails, retraction handling).

RAG primarily serves the evidence layer, knowledge graphs or relational tables serve the fact layer, and the ontology lives in the semantic control plane.

Reasoning vs Validation

OWL 2 uses an open‑world assumption: the absence of a fact only means “unknown”, not false. OWL can infer new triples but cannot enforce that a required field exists. Business processes often need a stricter check: if no valid has_payee is found the system should pause and request evidence rather than assume “no payee”.

Three complementary components solve this:

OWL answers “what can be inferred from existing facts and axioms”.

SHACL (or a domain validator) answers “does this batch of data satisfy publishing conditions”.

Policy/permission systems answer “who may execute which action after conditions are met”.

Where Large Models Fit

Large models generate candidate entities, relationships, and claims from contracts, tickets, and meeting minutes. Projects such as Microsoft GraphRAG and OntoGPT (using the SPIRES method) demonstrate that models excel at candidate generation, but downstream validation, publishing, and action gating remain local responsibilities.

The model can:

Identify candidate entities and relations from raw documents.

Normalize abbreviations, legacy names, and internal jargon.

Emit structured claims according to a given schema.

Highlight source discrepancies for human review.

Derive new validation examples from expert edits.

However, a correct JSON output does not guarantee the claim is true, nor does a professional‑sounding predicate guarantee business acceptance.

Practical Starting Point

Entity List

Identify 5‑10 core types, assign stable IDs, and record aliases, sources, matching methods, and manual merge logs, e.g.:

brand:brand-a    a Brand
entity:company-b a LegalEntity
account:account-c a BankAccount

Relation Dictionary

Define high‑frequency predicates (10‑30) with domain, range, meaning, inverse, cardinality, temporality, and evidence requirements. Example entry:

predicate: has_payee
 domain: Brand
 range: LegalEntity
 inverse: payee_of
 cardinality: 0..n
 temporal: true
 evidence_required: true

Claim Ledger

Separate candidate, published, and retracted claims. Minimum fields:

subject_id, predicate, object_id,
source_ref, observed_at, valid_from, valid_to,
status, schema_version, changed_by

Query APIs should support an as_of parameter to answer “who was the valid payee on June 1”.

Publish Tests

Validate that:

Identical names are not merged without evidence.

Incorrect endpoint direction (e.g., BankAccount → has_payee → Brand) is blocked.

Time‑based queries return different results when old and new entities coexist.

Every published fact can be traced back to its original source.

Retracted sources no longer appear in current results.

Missing evidence or insufficient permissions yields a “needs review” response.

Duplicate submissions do not cause duplicate side effects.

When to Adopt a Graph Database

Early systems can start with a relational table:

fact(
  subject_id,
  predicate,
  object_id,
  valid_from,
  valid_to,
  source_ref,
  status,
  schema_version
)

A graph database becomes attractive when:

Entities are scattered across many sources and need continuous alignment.

Business queries often span more than two hops.

Relationships accumulate over time and require provenance, versioning, and temporal tracking.

Multiple agents or systems concurrently read and write the same fact set.

If the workload is still limited to document paragraph retrieval, RAG may be simpler; if most queries are one‑hop and the schema is stable, a relational store suffices.

Conclusion

A reliable system must expose not only the predicate ( has_payee) but also the source document, current status (candidate or published), validity period, conflict information, and whether the fact can be consumed by the payment process.

Before scaling, answer six basic questions: Do objects have stable IDs? Are relations precisely defined? When is a fact valid? Where is the evidence? Who can publish or retract? Which actions may consume the fact? If these cannot be answered, postpone technology choices such as RDF, OWL, or Neo4j and first get a single fact chain working.

References

W3C: RDF 1.2 Concepts and Abstract Data Model

W3C: OWL 2 Web Ontology Language Primer

W3C: Shapes Constraint Language (SHACL)

Microsoft GraphRAG: Indexing Methods

OntoGPT: Introduction and Methods

SPIRES: Structured Prompt Interrogation and Recursive Extraction of Semantics