Versioned Knowledge Models: Keeping Changes to Operational Knowledge Traceable

Which Model Version Actually Applied?

For an operational process step, it must be clear which specific model version was used. The most recently saved file does not reliably answer this question.

In Process Intelligence, this reference becomes relevant as soon as earlier processes are analyzed under their conditions at the time. A later rule change must not silently become the original benchmark. Model identity, version identity, and scope of use must therefore be recorded separately.

A New Rule Takes Effect at Different Times at Two Sites

In an illustrative model, M-Trocknung, version 2.2 specifies the temperature conditions that apply to a product variant. Version 2.3 refines a limit and adds a check. It is published on June 1, activated at the North site on July 1, and not activated at the South site until July 15. The dates are part of this example.

A task newly started on July 8 can therefore be assigned to a different version depending on the site. The version number alone is insufficient: the assignment additionally needs the product, site, and reference time defined for the process.

A batch started in North before July 1 and processed further afterward needs its own transition rule. This can retain the previous version or provide for a reviewed transition. During a transition, the original reference, the change, and its effects on steps already completed remain traceable. An activation date alone does not decide this.

In Knowledge Graphs, these versions and assignments can be represented as separate objects and relationships. The domain rules must determine which assignment is permissible.

Stable Identity and a Specific Version Are Two Different Things

A knowledge model needs a stable identity under which it remains recognizable as a coherent model series. Each published version also needs its own version identity. The stable identity answers “Which model is meant?” The version identity answers “Which specific version of this model was used?”

OWL 2 accordingly distinguishes between an ontology IRI and an optional version IRI. The ontology IRI denotes the model series; a separate version IRI identifies a particular version. Earlier versions should remain accessible through their version-specific addresses, while the general address can refer to the current version.^[1]

The same principle can be applied outside an OWL ontology. A model version should have an unambiguous identifier and should not be silently overwritten after approval. At minimum, the identifier must be accompanied by a publication date, status, and predecessor version. A human-readable number such as 2.3 can be helpful but is insufficient on its own if different environments or submodels could use the same number.

A stable identity does not mean that every individual concept must remain unchanged forever. Instead, it ensures that changes can be assigned to a shared line of development. If a substantively entirely different model is created, a new model identity may be more appropriate than continuing an existing version series.

Recording Publication Time and Domain Validity Separately

A new model version can be published on June 1 but apply to a particular site only from July 1. Conversely, a correction can retrospectively clarify the domain frame of reference for an already completed investigation without changing historical records. Versioning therefore needs at least two temporal perspectives:

• System time: When was a version created, reviewed, published, or technically replaced?
• Validity time: For which period, process, site, product type, or use case does the version govern in domain terms?

The context model describes the conditions that give a specific operational situation its domain context. The model version adds a temporally unambiguous reference point. An event should be connected not merely to “the current model” but to the version actually approved for that operation.

When versions are valid in parallel, a linear sequence from version 1 to version 2 is insufficient. Different sites can introduce a new rule in stages, products can be subject to different specifications, and a pilot area can use an extension earlier. The scope of applicability must therefore be treated as an explicit condition. “Current” is not an unambiguous domain statement without specifying the relevant context.

Dependencies Between Models Must Also Be Versioned

An operational knowledge model rarely stands alone. It can adopt concepts from an ontology, use units from a reference model, import test conditions from a set of rules, or contain mappings to external classifications. If such a dependency changes, the meaning of the model itself can change even though its local files remain unchanged.

An approved version should therefore record which specific versions of its dependencies it references. An open reference to “whichever is current” makes reproducibility harder, because the same historical operation could receive a different semantic frame in a later analysis. OWL 2 describes imports as part of an ontology and also considers directly imported ontologies in its structural requirements.^[1]

Dependencies also include mappings between conceptual systems. For example, if an internal material status is mapped to a concept in a partner system, the mapping must have its own version and scope of applicability. A changed mapping must not silently make earlier data appear to have always had the same external meaning.

Not Every Change Has the Same Substantive Impact

A simple spelling correction differs fundamentally from a new mandatory relationship or a changed decision rule. Versioned knowledge models should therefore not only list changes but classify them in domain terms. A practical classification distinguishes at least:

• Editorial changes: Clearer labels, additional explanations, or corrected typos without changing the substantive statement;
• Additive changes: New concepts, relationships, or rules that do not restrict existing permissible statements;
• Refining changes: Narrower definitions, additional conditions, or more precisely defined scopes of applicability;
• Incompatible changes: Removed concepts, changed meanings, or rules that cause previously valid data and inferences to be treated differently;
• Deprecations: Elements marked as obsolete that remain available for historical operations but should no longer be used for new ones.

Research on ontology evolution points out that semantic models cannot be treated like ordinary database schemas. Explicit meanings, logical dependencies, and different contexts of use make changes to ontologies a distinct problem area.^[2] Even an apparently small conceptual change can affect queries, rules, mappings, or inferred statements.

Compatibility should therefore not be inferred from a version number alone. Labels such as “backward compatible” are initially documented assertions by those responsible for the model. Whether existing data, queries, and applications actually continue to work must be checked against the affected use scenarios.

A Change Record Explains More Than a Technical Comparison

An automated comparison can show which elements were added, removed, or renamed. This list of differences is insufficient for controlled knowledge maintenance. The domain rationale is also required: Which problem was observed? Which source or experience justifies the change? Which processes and decisions may be affected? Who reviewed and approved it?

W3C PROV-O provides relationships for derivation, revision, and responsibility, among others. A revision can be described as a new entity derived from a previous entity; the activities involved and responsible agents can also be expressed.^[3] For a knowledge model, this can preserve the connection showing that version 2.3 arose from version 2.2, which change activity produced it, and which person or organization was responsible.

The record should be maintained at the level of an approved change package. Individual editing steps during modeling can be numerous and technical. For operational review, what matters is which substantively related changes were assessed together and which expected effects the approval considered.

A Review Report Belongs to a Specific Set of Versions

A report on version 2.3 must show which model, import, shape, and test-data versions were used. Otherwise, it remains unclear whether a later repetition still checks the same subject. SHACL distinguishes a data graph and a shapes graph; both belong to a traceable review context.[4]

If a condition changes, the same data can produce different results under two shape versions. Such a difference must first be explained in terms of the respective requirement. The further question is validation of the knowledge model: which checks support a decision to use it?

Clearly Separating Working Drafts, Candidates, and Approved Versions

Intermediate states arise during model maintenance. If each went directly into operational processes, ongoing operations could be affected by incomplete or unreviewed changes. A controlled lifecycle therefore distinguishes at least a draft, a review candidate, an approved version, and a withdrawn version.

Responsibilities, review scope, and the decision should be documented for approval. Depending on the impact, domain model owners, process owners, quality assurance, and technical operators may be involved. An additional explanation may require less review than a rule that blocks tasks or influences release.

Operational knowledge models connect knowledge to real tasks, states, and decisions. Precisely for this reason, a new version must not take effect merely because it is technically available. Operational activation is a separate controlled action. It defines when and for which scope the approved model version is used.

Withdrawal should also be prepared for. It does not mean deleting the faulty version. Instead, its further use is stopped, another version is activated, and the operations processed with the withdrawn version during the affected period are documented.

Distinguishing Versioning, History, and Provenance

• Version management distinguishes approved versions of a model and their line of development.
• Change history logs which elements were edited and when; it does not automatically contain their domain meaning.
• Provenance describes the origin, derivation, activities involved, and responsibility for a model version.
• Validity management determines the period and context in which a version is to be applied.
• Migration moves data or applications into a new structure; this does not require historical data to retroactively lose their original meaning.
• Ontologies formally define concepts and relationships. Ontologies can be versioned, but less formal knowledge models also need controlled versions.^[5]

These tasks complement one another. A version number without a change record does not explain what changed. A complete history without validity rules does not explain which version was to be applied in a situation. And migration does not replace a lasting reference to the original semantic frame.

Validating Knowledge Models additionally describes how an unambiguously identified version is checked against structural rules, domain test cases, and its intended scope of applicability.

When Several Versions Apply at Once

An unresolved case arises when two active versions claim the same product and site combination. The higher version number is not a selection rule justified in domain terms. Model management must detect such overlaps and provide for a decision or an explicitly defined priority.

Withdrawal also needs a clear continuation: Which version applies to new operations, and which cases already processed need investigation? Reactivating an older version does not undo the intervening use.

An Earlier Operation Needs Its Earlier Reference

Asking for “the current version” is insufficient in the site example. Only the version, scope of applicability, and transition rule explain why a particular task was processed under 2.2 or 2.3.

A useful version record therefore leads from the specific execution to the identified version and its dependencies. Reusing assessed experience adds another reference: process memory preserves earlier process paths together with their substantive assessment.