How does a system know that knowledge has changed?

Knowledge and systems — 02

A document is updated. The new version is uploaded to the system. The next answer now uses that version.

At first glance, the knowledge appears to have been updated. Yet the old version may continue to live elsewhere: in a cache, a previously generated summary, another record, or the basis of a past decision.

That makes a change in knowledge a broader issue than noticing that a file has changed.

How does a system track what changed and which uses that change affects?

Working on KLM and nage, I encounter this question at two levels: how to record the knowledge trail, and how the system using that knowledge should behave.

What exactly has changed?

Consider a simple, hypothetical example.

Suppose an institution’s guidelines allow ten days for applications. New guidelines reduce that period to seven days, effective from a specified date.

More than the text has changed. The conditions under which a rule is valid have changed too.

The old guidelines may still be needed to explain an action taken while they were in force. A new application, however, should be answered using the new guidelines.

The system therefore needs more than a single “current document” field. It should distinguish which version of which source it holds, when that version is valid, and in which operations it was used.

Nor does every change carry the same weight. A spelling correction, a date change, and a change in a decision condition can have different consequences.

When a file’s content digest—its hash—changes, we can detect that the content differs. Establishing the meaning and impact of that difference requires another assessment.

KLM: making the trail of change readable

KLM is a contract development effort for explicitly recording the relationships among knowledge, claims, and evidence behind an answer.

What matters here is being able to distinguish the specific source version used, beyond retaining a source address.

If a link points to a different document today, that link alone may no longer tell us what a past answer relied on. Recording a source identity, version, or content digest makes this distinction possible.

The KLM specification defines validity start and end, version, and a relationship for superseding a prior knowledge unit. A new record can therefore state which older record it replaces.

These fields do not, by themselves, form a mechanism that detects changes in meaning. The application must separately establish how it detects a change and on what basis it fills those fields.

KLM provides a framework in which we can preserve the trail of a decision about a change.

Does a new version require deleting the old one?

If we remove the old guidelines in the example entirely, explaining a past answer can become difficult. If we use the old and new guidelines together without distinction, the rule governing a new answer becomes unclear.

Preserving history and setting the conditions for current use should be considered together.

A knowledge unit may be active, superseded, expired, or revoked. These are different states.

KLM accommodates these lifecycle distinctions. When a source is said to have been deleted, it also requires the deletion scope to be stated. A record removed from the knowledge store may not have been removed from caches, inference logs, or derived outputs.

The word “deleted” should not imply that the same operation has been completed throughout the system.

nage: carrying a recorded decision into an operating system

On the nage side, the question extends to maintaining these distinctions during operation.

Ingesting new knowledge can involve several operations: creating a source record, processing it, making it searchable, and opening it for use. Each can fail at a different point.

Which version will the system use if the new version has been written to storage but the search index has not been updated? What happens if the old version is archived but remains in a cache? If two updates arrive simultaneously, which is treated as the active version?

In nage’s design, managed knowledge units are considered together with their sources, versions, lifecycles, and available capabilities. A document being present, searchable, and accepted for use are separate states.

Compressing that distinction into a single “ready” flag can make an unfinished operation appear usable.

The operational question here is:

How do we verify the conditions under which the new version can be used?

Product-wide lifecycle acceptance remains an open area of work in nage. This account therefore describes behaviour that needs to be tested; it does not claim that all update and deletion scenarios have been completed.

How far does a source change reach?

Suppose a particular claim in an answer relied on the old guidelines. That answer might later have been summarised, and the summary used in another piece of work.

When the source changes, the impact does not stop at the first answer.

Being able to trace from sources to outputs therefore matters: which claims used this version? Which outputs were derived from those claims?

KLM’s evidence and derivation relationships offer a basis for recording this impact trail. Finding an affected record, however, does not automatically declare it wrong.

An answer produced under a rule valid in the past may remain correct in its historical context. The same answer may be unsuitable for a new action today.

The system needs a policy to distinguish those uses. Some records may be reassessed, some preserved historically, and some closed to new use.

The relationship record makes visible which records that decision needs to cover.

What do we not know about freshness?

A source entering the system today may not establish that its contents are valid today. A recently dated file can also convey an older rule.

The time a source was acquired, changed, and became valid carry different information.

If one is unknown, that absence needs to remain explicit. KLM’s approach of preserving unknown signals together with their reasons matters here too. Assigning a number to unmeasured freshness does not eliminate missing information.

Returning to the opening question, “the system understands” separates into several concrete tasks: detecting the change, linking the new record to the old one, setting conditions of use, and finding affected outputs.

Each task should have its own basis and limits.

When assessing a knowledge update, we also need to ask:

We added the new knowledge; can we see where the old knowledge continues to be used?

---

Source note — 15 October 2026: This article draws on the KLM specification’s knowledge lifecycle and impact lineage sections, and nage’s design and current implementation documents. The guidelines example is hypothetical. No new implementation or acceptance-test result is presented.

KLM project page · nage project page · Why is unknown not zero?