Lifecycle

A knowledge base is not a snapshot. Content changes, and the changes have to propagate through every representation without leaving stale copies retrievable.

Versioning. Every source document has a version chain. A new version is a new canonical document linked to its predecessor, not an overwrite. Every derived representation is keyed to the version that produced it. This is what makes "what did the policy say last March" answerable, and what makes rollbacks possible when a bad version is ingested.

Supersession. When a new version becomes effective, the prior version is marked superseded with an effective-to date, and it drops out of default retrieval. It remains in the store, retrievable on request for historical questions, and the supersession link is visible to consumers. The rule for what supersedes what usually comes from source metadata; where it does not, it is a human decision routed through the owning domain's review workflow.

Propagation. A version change triggers regeneration of chunks, summaries, entities, and embeddings for the new version, and invalidation of the old version's derived representations in every index. This is an event-driven pipeline property, and the retrieval layer's freshness metrics are the check that it worked.

Retirement. Content that is expired, withdrawn, or no longer authoritative is retired according to the domain's retention policy: excluded from active retrieval, retained for audit for as long as policy requires, then deleted with its derived representations. Retirement metadata propagates to every index, and the audit log records that it happened.

Lineage throughout. Every representation records what produced it: the source version, the parser and its version, the chunker and its version, the extractor, the embedding model. This is what makes targeted reprocessing possible when a component is upgraded or found defective, and it is what an audit will ask for.