Ontology Engineering — the correctness axis
"Prompt engineering is ontology engineering."
The AIDLC methodology frames reliability as a dual-axis: Ontology Engineering guarantees the correctness of what agents produce (the WHAT and WHEN), and Harness Engineering enforces the safety of how they execute (the HOW). This page covers the first axis and how OMA implements it.
The companion page Ontology is the schema reference — the literal entities and fields. This page is the why: how those schemas realize the methodology's correctness guarantees.
The failures ontology prevents
Agentic systems fail on correctness in three recurring ways — none about model quality:
| Failure | Without ontology | With ontology |
|---|---|---|
| Hallucination | The agent invents plausible-but-wrong domain reasoning. | Every domain concept is explicitly defined; invariants are encoded and violations are caught mechanically. |
| Context loss | Definitions scattered across prompts; the agent loses the thread mid-session. | One typed world model is the single referent across prompts, sessions, and tools. |
| Inconsistency / drift | A term means different things in different skills, so handoffs need a human to re-interpret. | A handoff is a validated document, not prose. |
OMA's concrete origin story: autopilot-deploy and construction-loop both said
"deployment target" — one meant an EKS cluster name, the other meant the enum
eks | ec2 | lambda. The handoff only worked because a human re-read it. The
Deployment entity closes that gap.
The typed world model
The methodology elevates DDD's Ubiquitous Language from informal natural-language consensus into a formal, machine-readable schema — a "typed world model" scoped to AI agents + team + code, validated automatically rather than by manual review. Its four characteristics: formality, type safety, verifiability, evolvability.
OMA realizes this as 8 JSON-Schema entities (Draft 2020-12) in
schemas/ontology/:
| Entity | Role in the correctness chain |
|---|---|
Spec, ADR | Inception intent and decisions — the source of WHAT/WHEN |
Agent, Skill | The actors and their declared produce/consume contracts |
Deployment | The validated Construction→Operations handoff document |
Incident, Budget, Risk | Operations-side facts that feed the Outer Loop |
oma validate <entity.yaml> enforces schema + OPA policy on all 8 — the mechanical
"violation detection" the methodology calls for. See Ontology for
field-level detail.
The triple feedback loop — a living ontology
The methodology's key insight is that an ontology is not written once; it is alive, refined by three nested loops at different cadences:
| Loop | Cycle | Trigger | Ontology change | OMA surface |
|---|---|---|---|---|
| Inner | minutes | test failure, harness violation | add/modify a constraint | quality-gates, schema-evolution rule 1 (add fields first) |
| Middle | days | repeated PR-review patterns | update entity/relationship schema | DSL version: bump on breaking changes |
| Outer | weeks | operational incidents, SLO violations | redesign domain model structure | agenticops → self-improving-loop |
The methodology's worked example: rising P99 latency drives a redesign of an
overgrown Payment aggregate (which carried full customer history) into a
CustomerReference plus a separate CustomerProfile aggregate — reportedly
cutting P99 by 42%. The redesign is an ontology change, triggered by operations.
AgenticOps as the Outer Loop
This is where OMA's operations story re-enters as a methodology citizen rather than a standalone feature. AgenticOps is the Outer Loop made autonomous — it feeds observability data (Langfuse traces, Prometheus metrics, incident postmortems) back into the ontology, which the methodology summarizes as "AIOps → AIDLC."
In OMA, self-improving-loop analyzes trace patterns and proposes concrete
skill/prompt PRs (non-destructive, regression tests required before the PR opens),
so the Operations→Construction arrow — historically dependent on human issue triage
— is automated. The reported methodology gains from closing this loop: accuracy
+31%, false positives −67%, error rate 8.3% → 1.2% over 31 days, versus negligible
improvement (8.3% → 7.9%) without the loop.
Where the harness plugs in
Ontology owns WHAT + WHEN — it defines the constraints. It does not enforce them at execution time. That is the harness's job (the HOW axis): the harness verifies the constraints the ontology declares and feeds verification results back into ontology evolution. Continue to Harness Engineering.
References
- engineering-playbook — Ontology Engineering — conceptual source (REFERENCES)
- Ontology — OMA's 8-entity schema reference
schemas/ontology/— the JSON Schemasplugins/agenticops/skills/self-improving-loop/SKILL.md— Outer Loop implementation