KCAE.CHANGE:4.1 - Detect changes at the relevant dependency boundaries

Maintain a source inventory that can distinguish addition, deletion, content change, relocation, replacement and a change in role or authority. Identify editions and membership from the source system or a captured snapshot. A directory scan of a changing tree is not automatically a snapshot: obtain source locking, immutable revisions, a stable export, or detect concurrent mutation and retry the affected acquisition.

Establish how a change becomes observable: an authorized event feed, revision query, periodic polling, supplied export or explicit owner notification. Record the last successful observation and the coverage or freshness interval it supports. Detect a broken subscription, failed fetch or missed sequence where the source permits it. “No change event received” supports currency only under a functioning channel with the required coverage; after an unexplained gap, recover the current inventory or mark currentness unknown. A periodic full reconciliation can find missed additions and deletions that an event-only path would retain indefinitely.

Track the dependencies actually used to derive a result. A retrieval unit can depend on its bytes, enclosing heading, table structure, contextual prefix, linked definition, extraction version and model configuration. An assessment additionally depends on the case facts, criterion and source-role basis. A recommendation additionally depends on burden and the receiving opportunity. These are different invalidation sets.

For example, moving an unchanged clause from “general availability” to “obsolete compatibility” leaves its block hash unchanged and changes its practical interpretation. Recompute the context-sensitive representation and reopen dependent assessments. An unchanged embedding can sometimes be reused technically while the source address or applicability is updated; do not infer semantic validity from that reuse.