Ontology Isn't a One-Time Deliverable: Versioning, Change Management & Feedback Loops

Why Acceptance Doesn't Guarantee Lasting Validity

The previous article discussed ontology acceptance and emphasized that acceptance conclusions are only valid for the bound scope, version, data, and environment. This means a model that has passed acceptance cannot be treated as a static deliverable. Business policies change, source systems are rebuilt, fields and interfaces evolve, object states update continuously, and agents expose new semantic gaps and boundary issues in production. Overwriting the old model makes historical decisions irreproducible; modifying the ontology without updating mappings, rules, object projections, and action contracts leaves production running multiple conflicting versions.

The goal of ontology governance is not to keep the model unchanged, but to ensure every change has a source, boundaries, impact analysis, a migration plan, and continuous correction from runtime feedback.

Why a Model May Still Fail After Acceptance

A single acceptance proves that at a specified time and test scope, a model release unit and its runtime implementation satisfied agreed behaviors. This conclusion does not automatically cover future changes. After deployment, changes typically originate from five directions:

Business changes: object boundaries, state meanings, policy conditions, or action rules are adjusted.

Data changes: source tables, fields, encodings, interfaces, or object identity mappings change.

System changes: rule engines, business services, permission policies, and action interfaces are upgraded.

Runtime changes: data latency, distribution drift, state conflicts, or exception paths appear.

Agent changes: base models, prompts, tool descriptions, orchestration strategies adjust, or runtime results reveal new issues.

Some changes require semantic model modifications; others only need adjustments to data mappings, rules, services, or agent configurations. The real danger is labeling all changes as "ontology upgrades" so that no one can explain what actually changed.

First Distinguish Four Version Axes

Once an ontology enters the runtime system, at least four distinct version types exist. They are interrelated but cannot be compressed into a single "current version".

Model Baseline Version – answers "how are objects, relations, processes, states, rule semantics, and action semantics currently defined?" Typical changes: adding states, adjusting object boundaries, changing relation meanings.

Engineering Release Version – answers "which constraints, mappings, rule references, projection definitions, and service contracts are bound in the current release unit?" Typical changes: fixing mapping configurations, regenerating constraints, upgrading tool descriptions.

Source Data & Interface Version – answers "which source structure, record version, event position, or data snapshot do current facts come from?" Typical changes: field renames, encoding adjustments, interface upgrades, source record updates.

Object Projection Version – answers "which facts, rules, and observation time form the current state of a specific object?" Typical changes: new events arrive, facts are corrected, projections are rebuilt.

The model baseline version answers "what do business concepts mean?"; the release unit version answers "which engineering artifacts are in use?"; the source data version answers "where and when does evidence come from?"; the object projection version answers "what is this object's state based on?".

Strictly speaking, the release unit version and each engineering artifact version are not the same number. A release unit locks a specific set of artifacts and their versions via a manifest. The same model baseline can produce multiple engineering release versions due to mapping fixes, constraint regeneration, or tool description upgrades without changing business semantics.

Rules, policies, action contracts, permission policies, base models, prompts, and agent orchestration also have their own versions. They should be recorded as explicit dependencies of the release unit, not hidden inside a single generic ontology version number.

Source data versions are not necessarily a single enterprise-wide number. They may be expressed through interface schema versions, source record versions, event offsets, data snapshots, and observation times. The key is that runtime results can be traced back to the actual evidence used at that time.

No single "latest version" can simultaneously represent business semantics, engineering implementation, source data, and object state.

Not All Changes Require Modifying the Ontology

Regardless of whether a change originates from business planning, system reconstruction, or runtime feedback, the first step is never to immediately edit the model but to determine which layer the change belongs to.

Source system field renamed but business meaning unchanged → handle in data mapping and interface adaptation; usually no semantic model change.

Credit warning threshold adjusted from 30 days overdue to 20 days → handle in policy or rule version; if rule concept and applicability boundaries unchanged, usually no semantic model change.

New "judicial dispute" status added, changing auto-disposal boundaries → requires changes to model baseline, rules, projections, and action contracts; semantic model change needed.

Action API endpoint or authentication method changed → handle in action service and security config; usually no semantic model change.

Action meaning, preconditions, or failure semantics changed → evaluate model baseline and action contract; usually requires semantic model change.

Prompt or tool description adjusted → handle in agent configuration and tool release version; usually no semantic model change.

Data latency causing wrong judgments → address in data quality and runtime pipeline; should not directly modify the ontology.

"Not modifying the ontology" does not mean skipping version management. Changes to mappings, rules, interfaces, or agent configurations still require new versions, re-binding of the release unit, and regression testing.

If modifications are made to labels, descriptions, or other metadata of an already released model, they still must not be overwritten in place. They should form a new revision version, which can be classified as a compatible correction that does not alter business semantics.

A Change Must First Form a Reviewable Change Set

An already released model baseline should never be edited directly. Any adjustment must start from a traceable change request and produce an independent change set.

A usable change set must at least capture:

Change identifier, proposer, reason, and business evidence.

Stable identifiers of affected model elements.

Semantic differences before and after, not just file diffs.

Applicable scenarios, organizational scope, business effective time, and whether the change is forward-effective or a retrospective correction of historical errors.

Preliminary compatibility judgment and potential risks.

Linked capability questions, rules, data sources, and test cases.

Business, data, system, and risk owners.

It is essential to distinguish business effective time, system record time, and release time. The release unit must also record its release time. Business effective time determines which business time points a policy or semantics applies to; system record time reconstructs what the platform knew at that moment; release time indicates when engineering artifacts become consumable by the runtime system. These three must not be conflated, especially for retrospective corrections.

For model elements already referenced by external systems, deprecation should be preferred over immediate deletion. Deprecated elements retain their stable identifiers and historical meanings and must not be reused for a different concept; new systems stop depending on them, while old systems phase them out during a migration window.

After a change set passes review, if business semantics change, it enters a new candidate model baseline. If only policies, rule parameters, data mappings, rule implementations, interface adaptations, or agent configurations are adjusted, the original model baseline is retained and a new engineering release version is created. This way the team reviews not "how the whole model differs from yesterday" but "which specific semantics and runtime contracts this change alters".

Different change types cannot be approved by a single technical team. Business semantics and policy changes require confirmation by business or institutional owners; data mappings by data and source system owners; action and permission changes by application, security, or risk owners. When a change spans multiple layers, the highest-risk approval and verification requirements apply. Emergency fixes may shorten processing time but must not overwrite released baselines or skip subsequent evidence completion and re-review.

Impact Analysis Is More Than Checking Internal References

A state or relation in the ontology may already be used in data mappings, rules, object projections, semantic services, agent tools, and business actions. Checking only internal model references cannot reveal the true impact.

From an engineering perspective, this step assesses the blast radius: a seemingly local model or engineering adjustment may propagate to data, rules, services, actions, and historical records.

The complete impact chain typically follows:

Change Set → Model Elements → Capability Questions → Data Constraints & Mappings → Rules & Policies → Object Projections → APIs, MCP Tools & Semantic Services → Action Contracts & Permissions → Agent Config → Test Cases → Historical Decisions & Action Records

Impact analysis must answer six categories of questions:

Semantic impact: Have object identity, classification, relations, states, or rule meanings changed? Can old data still be interpreted under the new meaning?

Data impact: Which source tables, fields, documents, interfaces, and quality rules need adjustment? Is remapping or supplemental evidence required?

Behavioral impact: Do rule hits, state calculations, candidate actions, or human confirmation boundaries change?

Interface impact: Are query results, API contracts, MCP tool descriptions, and action parameters still compatible?

Runtime state impact: Can existing object projections continue to be used, or do they need rebuilding, recalculation, or marking for refresh?

Historical impact: Can historical decisions still be explained by the version in effect at that time? Do unfinished tasks need recalculation rather than rewriting occurred facts?

Impact analysis must trace from the model outward to implementations and from affected interfaces, rules, and runtime records backward to confirm sources. Only when bidirectional tracing is established does the team know what to regenerate, retest, and which consumers to notify.

Compatibility Cannot Be Judged by Version Number Alone

Semantic versioning can express compatibility promises, but the version number itself does not replace the team's judgment.

Adding an optional attribute may be fully compatible with existing queries; adding a required attribute may cause many historical objects to violate constraints. Changing a display name usually doesn't affect runtime; splitting a state may simultaneously change data mappings, rule results, object projections, action permissions, and agent prompts.

Therefore, compatibility must be checked separately for:

Can old data be interpreted by the new model?

Can old queries and interfaces continue to run?

Do rule changes affect only the expected scope, and can old version results be replayed under the original rules?

Do old object projections need rebuilding?

Do old action requests still satisfy the new contract?

Can historical decisions be replayed and audited under the original version?

Compatible changes can use rolling upgrades but still require regression testing within the affected scope. Breaking changes require a migration plan covering: target version, affected systems, adapters or dual-version window, data and projection migration, test scope, switch time, failure rollback conditions, and owners.

Forward-looking new policies usually only affect judgments after their effective time. Retrospective corrections for historical modeling or mapping errors may require recalculating affected results, notifying owners, and handling already produced business consequences. Even when retrospective correction is needed, the original version and original decision records must be retained; new results must not overwrite historical evidence.

The runtime system should not simply select the "highest version number" model. Different regions, business lines, or contracts may be bound by different effective times, so old and new versions must coexist for a period, with scenario, organizational scope, and business time jointly determining which version applies.

The model lifecycle after "draft, candidate, released" can be further divided:

Effective: allows new tasks in specified scope to use it.

Deprecated: no longer accepts new dependencies; existing consumers enter a migration window.

Retired: no longer used for new runtime tasks, but retained for historical explanation, audit, and replay.

Technical version rollback only changes which release unit subsequent requests use; it cannot undo completed payments, limit adjustments, or customer notifications. Business side effects already produced must be resolved through reversals, compensations, or manual handling in the business system, not by reverting the ontology version.

Runtime Feedback Cannot Be Directly Written Back to the Ontology

Once the ontology enters the runtime system, model issues arise not only from review meetings but also from query failures, data quality alerts, rule misjudgments, human corrections, action failures, and agent usage records.

However, a single erroneous output does not prove the ontology definition is wrong. The problem may originate from:

Errors in business concept, relation, or state definitions.

Missing data mappings, incorrect identity associations, or expired evidence.

Policy rule implementation errors or incorrect effective version selection.

Object projection latency, conflicts, or rebuild failures.

Action interface, permission, or transaction processing failures.

Degradation in base models, prompts, tool descriptions, or agent orchestration.

User input exceeding current scenario boundaries, or disputed human corrections.

Therefore, every valid feedback should bind the business object, occurrence time, release unit, model baseline, data and projection versions, rule and action versions, agent configuration, expected result, actual result, and evidence. Feedback lacking this context — "the system answered wrong" — is difficult to feed into a reliable governance process.

A more robust feedback loop is:

Runtime signals → evidence collection → problem classification → owner confirmation → candidate change → impact analysis → regression & acceptance → release observation

Large language models can help cluster issues, discover candidate concepts, and generate change suggestions, but they must not automatically rewrite a released ontology based on a single conversation or user feedback. How business reality is defined still requires confirmation by the responsible owner.

Object runtimes can provide signals such as data expiration, state conflicts, and projection failures; this article focuses on how these signals enter change governance, not on re-discussing projection freshness, rebuild, and reconciliation mechanisms.

Case Study: A Complete Change in Credit Warning

Continuing the "identify overdue risk and form credit disposal suggestion" scenario. Assume a new policy: if a receivable has entered judicial dispute, the system must not automatically generate a credit limit reduction suggestion but must escalate to human review.

This is not a simple prompt tweak but a cross-layer change:

Business owner proposes the change and confirms the meaning of "judicial dispute", applicable receivables, start/end events, business effective time, and human disposal boundaries.

Model adds or adjusts the dispute status and its relations with receivables and customers, forming a new candidate baseline.

Data team confirms the authoritative source in the judicial system, object identity, and interface version, adding semantic mappings and quality constraints.

Rule team adjusts warning and disposal rules; object projection adds the new status; action contract adds human confirmation preconditions.

Impact analysis identifies capability questions CQ-02, CQ-03, CQ-04, related semantic services, MCP tools, agent configurations, and exception test cases.

Old and new versions run in parallel within a controlled scope; affected object projections are rebuilt per the migration plan; switch occurs at the policy effective time.

Historical decisions continue to reference the old release unit and are not silently rewritten by the new policy; unfinished tasks follow migration rules to continue, re-decide, or transfer to human review.

After launch, if the system still misjudges, root cause analysis continues. Suppose the issue is judicial system data latency; the governance action should fix the interface, freshness rules, or fallback strategy — not modify the "judicial dispute" business definition again.

This case illustrates that model evolution is not "changing a diagram" but a bounded collaborative change across semantics, data, rules, state, interfaces, actions, agent, and tests.

What a Model Evolution Must Leave Behind

After a change completes, the artifacts should not be just new model files. Complete governance output includes at least:

Non-overwritable model baseline history.

Change sets with reasons, evidence, and stable identifiers.

Compatibility conclusions and cross-layer impact analysis reports.

Engineering artifacts, external dependencies, and their version manifests.

Data, projection, interface, and consumer migration plans.

Regression tests, layered acceptance, and release observation evidence.

Effective, deprecated, retired, and necessary rollback records.

Runtime feedback, problem classification, owners, and closure results.

These artifacts collectively answer four questions: why change, what changed, who was impacted, and how to prove the change was correctly handled.

Borrowing concepts from current engineering systems: DevOps connects software development, delivery, and operations; DataOps focuses on data flow, quality, and continuous supply. The versioning, change, impact analysis, and feedback loop described here can be viewed as a KnowledgeOps (knowledge operations) practice: bringing enterprise knowledge definitions and their engineering artifacts into a versionable, testable, releasable, and operable system.

KnowledgeOps does not necessarily mean building a separate platform, nor does it replace DevOps and DataOps. It emphasizes that business knowledge cannot remain in static documents long-term but must enter a continuous governance process like code and data.

Summary

An ontology is not a one-time deliverable, nor a configuration file that can be overwritten at any time. It is a versioned baseline of business semantics that enters the runtime system via release units together with data mappings, rules, object projections, action contracts, and agent capabilities.

The key to continuous governance is not stuffing all changes into the ontology, but separating the model baseline, engineering artifacts, source data, and object projections into distinct version axes; letting each change first form a change set, then complete impact analysis, compatibility judgment, migration release, and runtime feedback closure.

A truly operable ontology not only explains how business is currently defined, but also explains why it changed, which systems were impacted, and which version should be used for history and for the future.