Why Dynamic Ontologies Need Four Separate Governance Paths, Not One Auto-Update Button

The article builds on a previous distinction of four change types often lumped together as "dynamic ontology": terminology mapping, model evolution, runtime state, and agent negotiation. It argues that merely distinguishing the concepts is insufficient; each must enter its own responsibility, verification, release, and failure path.

The key to dynamic capability is not letting the system automatically modify more content, but ensuring each change type reaches the correct owner, validation method, release path, and failure exit.

Four Dynamics Cannot Share One "Auto-Update" Button

If a platform claims "self-evolving ontology," the first question is not which LLM is used, but who changes what. The article presents a routing table for the four change types:

Terminology Mapping

Candidate Generation: Rules, dictionaries, code tables, retrieval, or model suggestions

Verification: Thresholds, source restrictions, real-sample evaluation, human review

On Success: Versioned mapping library

On Failure: Terminology backlog or human arbitration

Model Evolution

Candidate Generation: Business changes, mapping gaps, runtime feedback form change sets

Verification: Capability issues, consistency, real data, impact analysis, business review

On Success: New semantic candidate baseline and release package

On Failure: Model change backlog or redesign

Runtime State

Candidate Generation: Source records, events, rules, and object projections continuously updated

Verification: Source, time, version, completeness, freshness, reconciliation

On Success: Reproducible current object projection

On Failure: Source system fix, replay, rebuild, or human confirmation

Agent Negotiation

Candidate Generation: Intent, capability declarations, current context combined

Verification: Semantic consistency, policy, authorization, safety thresholds, human confirmation

On Success: Time-bound candidate plan or controlled action request

On Failure: Clarification, re-negotiation, deterministic fallback, or human takeover

The table shows "self-evolution" at most means automatic candidate discovery, evidence collection, pre-checks, and governance initiation. Whether a candidate becomes enterprise semantics, execution strategy, or real action still requires explicit owners and acceptance evidence.

From One Fault Signal: How Four Changes Diverge

Scenario: A supplier device reports a new fault code X7-TempDrift while device A's temperature hits 92°C, and a repair agent wants to coordinate scheduling and spare parts within 4 hours. The system faces four parallel governance tasks:

Terminology mapping task. Determine if X7-TempDrift maps to existing "spindle temperature drift." Retain original value, candidate concept, catalog version, match score, confirmation log. Failure only enters terminology backlog — never auto-create a business concept.

Model change task. Only if field evidence proves a new fault type with independent state, rules, or repair process does the business model owner submit a change set, assessing impact on data mappings, rules, queries, and action contracts.

Runtime state task. Device A's 92°C, current work order, recent repair time continue updating via event streams and object projections. They must bind source record, observation time, state version — temperature change does not trigger a new ontology version.

Agent negotiation task. Repair, scheduling, spare-parts, and personnel agents can form candidate plans, but results must pass safety policy, object state, action contracts, and human confirmation before real execution.

These four tasks may reference the same alarm and device object but must not impersonate each other. Terminology mapping success does not prove the fault occurred; runtime anomaly does not auto-approve shutdown; a negotiation proposing a new concept cannot directly modify the enterprise semantic baseline. Change routing preserves this responsibility separation at signal onset, preventing everything from collapsing into "let the LLM decide."

Enterprise Architecture Needs "Stable Core + Controlled Dynamic"

The four dynamics are not isolated systems; they collaborate around a single traceable version chain:

Business Source Model → Published Semantic Baseline → Terminology & Data Mapping → Object Runtime → Agent Context & Ad-hoc Negotiation → Deterministic Decisions & Action Contracts → Source Business Systems → Runtime Feedback

Along this chain:

Business source model is co-confirmed by domain experts and FDEs using understandable symbols, language, and cases.

Ontology, constraints, mappings, service contracts run as published engineering artifacts at baseline versions.

Terminology layer continuously discovers new expressions but only produces candidate mappings or model change proposals.

Object runtime generates reproducible projections from current facts, time, and rules.

Agents dynamically assemble context and negotiate candidate plans but cannot bypass policies and action contracts.

Source business systems still persist facts and bear transaction responsibility.

Runtime errors and business corrections first enter attribution, then decide whether to modify mapping, model, rules, data, or agent config.

What stays stable is not an "immutable ontology" but an identifiable, verifiable, rollback-capable published baseline at every point in time.

Some Things Must Be Harder Than "Dynamic"

In enterprise systems, the following cannot be loosened just because agents are smarter or ontologies more dynamic:

Business responsibility boundaries. Who defines concepts, confirms rules, approves actions — not replaced by model confidence scores.

Published baselines. Historical judgments must trace back to the exact semantics, mappings, rules, and data versions of that time.

Action contracts. Which object, what action, required preconditions, possible side effects — must be explicit.

Authorization and security floor. Dynamic negotiation may request temporary authorization scope but cannot self-authorize.

Transaction and failure semantics. Idempotency, concurrency, timeout, partial failure, reversal, compensation — not defined ad-hoc via natural language negotiation.

Audit evidence. Temporary context may expire, but intent, candidate proposals, authorization decisions, execution receipts, and contemporaneous versions must be retained.

Only with these stable boundaries can the system earn the right to add dynamic matching, dynamic state, and dynamic negotiation on top.

Not Every Scenario Needs "Dynamic Ontology"

If business terminology is stable, objects come from one system, rules are enumerable, downstream consumers are few, a fixed schema, API, rule code, and release process may suffice. Similarly, if an agent only calls a few known internal tools with stable contracts and clear parameters, MCP or plain function calls work reliably — no need for runtime semantic negotiation just to be "more agentic."

Real signals warranting dynamic mechanisms include:

Terminology, abbreviations, industry standards change continuously; fixed vocabulary maintenance becomes a bottleneck.

Ontology is reused across multiple systems and agents; changes require unified impact analysis and migration.

Object instance state spans multiple source systems; on-demand query no longer meets latency, consistency, traceability needs.

Multi-agent ecosystem participants and capabilities cannot be exhausted at design time, and ad-hoc combination has genuine value.

Evaluation, permission, approval, fallback, and audit boundaries can already be established for these dynamic results.

The criterion is not "can we do it" but whether the adaptability gained covers the uncertainty, latency, compute, review, and governance costs introduced.

If You Want to Land It, Build "Change Routing" First

Enterprises don't need a massive "dynamic ontology platform" upfront. A pragmatic first step: establish change routing in a well-bounded scenario.

Freeze the current semantic baseline. Explicitly define current objects, relations, states, action semantics; tag version, owner, effective scope.

Build terminology and data mapping records. Retain original value, standard value, source, score, method, status, human confirmation.

Separate model change from runtime state. Former enters change set, impact analysis, release process; latter enters events, projections, rebuild, reconciliation.

Bound agent negotiation. Clarify which capabilities can be dynamically discovered and composed, which actions require fixed contracts and human confirmation.

Create independent acceptance for the four change types. Don't substitute ontology consistency reasoning for mapping accuracy, object freshness, negotiation plan validity, and action safety tests.

Route runtime feedback to attribution first. Only when evidence shows business concepts or relations no longer hold should ontology model change be triggered.

Once these six steps run, an enterprise can claim an operable dynamic semantic mechanism — not just an LLM performing more automated operations on a graph database.

Summary

"Dynamic ontology" is a misleading label.

Terminology mapping dynamics absorb new expressions; model evolution dynamics let business semantics follow reality; runtime state dynamics give agents traceable current facts; agent negotiation dynamics enable temporary capability composition in open environments.

They can supply each other with evidence and context but cannot directly substitute for one another.

Enterprises need not a "living ontology" that changes everything on its own, but a semantic runtime system that recognizes changes, routes them to the right objects, and continuously evolves on stable contracts.

Next article will discuss why standard ontologies should not directly become application schemas, and how stable business models connect to continuously changing external terminologies.

Standard ontologies should not become business schemas: how stable business models connect to changing terminologies.