The edit that did not travel

At 09:12, a policy owner corrects a customer-support procedure. One threshold in the approved page changes from £750 to £500. The authoring system shows the new value, its version history records the editor, and a colleague refreshing the page sees the correction. At 14:40, an internal assistant still tells a caseworker that the threshold is £750.

The assistant has not invented the figure. Its vector index contains yesterday’s chunk. The keyword index has refreshed, but the answer cache has not. A PDF exported that morning remains in a team folder. The catalogue points to the corrected page but carries no version identifier, so a reviewer cannot tell which bytes supported the answer. From the author’s perspective the content is fixed. From the institution’s perspective, two incompatible versions are simultaneously usable.

This failure is often described as stale retrieval. That description is accurate but too late in the causal chain. The deeper mistake occurred when a source edit was treated as publication. The source repository performed its job: it stored a new version. Nobody defined which downstream surfaces had to change, how they would acknowledge the exact version, when the new version became eligible, or how the old version would be made ineligible.

A document becomes governed knowledge only when a release transaction establishes identity, authority, scope, discoverability and reversal. “Transaction” here does not promise one global database commit across every platform. It means a controlled state transition with explicit preconditions, typed events, observable acknowledgements and a reconciliation path. The release may be asynchronous, but its incompleteness must not be invisible.

The argument is narrower than general knowledge architecture. The adjacent article on knowledge architecture explains ontology, chunking, metadata and stewardship. The article on freshness and supersession explains temporal fitness at decision time. This paper asks the intervening operational question: what must happen between an approved source and every place from which that source can influence a decision?

Part I: Publication is a state change

An upload answers a storage question: did these bytes reach a repository? Publication answers an institutional question: may this identified version support a defined class of decisions, for a defined audience, during a defined interval? Those questions can have different answers. A draft can be stored but not publishable. An approved procedure can be staged in every index yet remain future-effective. A withdrawn object can remain preserved for audit while being excluded from current answers.

Thought experiment: identical paragraphs, unequal authority

Place the same paragraph in two files. The text, formatting and cryptographic hash are identical. File A is a working note saved by an analyst. File B is a procedure approved by the accountable policy owner, scoped to one jurisdiction and effective from Monday. A semantic model cannot distinguish them from content because there is no textual difference to detect. Only the institutional state around the bytes changes.

Now vary one feature. Remove the approval record from File B while leaving every word intact. Its information content has not changed, but its authority has. Next, restore approval and change only the effective date. Its authority remains, but its current eligibility changes. Finally, keep both and withdraw the procedure after an incident. Historical relevance remains while prospective use ends. Authority, applicability and lifecycle are relations, not stylistic properties hidden inside prose.

The W3C PROV-O recommendation offers a useful minimal grammar: entities are produced or transformed by activities associated with agents. It can express who created or approved an artefact and which source it derived from. It does not decide who is authorised to approve a retail-credit procedure or whether that procedure is currently effective. Standards can carry institutional decisions; they cannot substitute for them.

Four properties of published knowledge

For this paper, a governed knowledge object is an operational artefact eligible to support specified decisions. The term does not claim that the organisation, a person or a machine thereby possesses knowledge in a philosophical sense. The operational object needs four linked properties.

The FAIR Guiding Principles supply part of this foundation: persistent identifiers, rich metadata, searchable registration and metadata that remain accessible even when the data are unavailable. DCAT 3 adds catalogue and version relationships. These are valuable patterns, but enterprise publication adds authority, entitlement, effective time and consequence-specific withdrawal.

One object, several fallible projections

A policy page, a search result, a graph node and an embedding vector are not four independent truths. They are four projections of one governed object. Each projection optimises a different operation and can lag, truncate or misrepresent the object differently. The catalogue may carry authority metadata but no full text. The vector index may carry text but drop version relationships. The cache may carry a fluent answer whose cited object has since been suspended.

The design therefore separates a control plane, which decides identity and eligibility, from data-plane projections, which make eligible objects usable. A projection may contain staged content before activation. It must not decide by itself which version governs. Similarity ranking chooses among objects already admitted by authority, scope, time and entitlement.

flowchart TD
  A["The edit that did not travel"] --> B["On this page"]
  B --> C["Part I, Publication is a state<br/>change"]
  C --> D["Part II, The release contract"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#B96D00,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Part II: The release contract

The publication pipeline begins with a contract for the knowledge object, not with a connector. A practical contract distinguishes the stable conceptual object from each immutable material version. The stable identifier answers “which governed thing is this?” The version identifier answers “which exact representation was used?” A mutable URL alone usually answers neither reliably.

Identity before indexing

For major changes, DataCite’s versioning guidance links versions with explicit predecessor and successor relations. DCAT 3 likewise supports version chains and series. An enterprise need not issue public DOIs, but the identity pattern transfers: one stable object ID, immutable version IDs, typed relations such as supersedes, corrects and withdraws, plus a resolver that returns the current eligible version for an authorised request.

A minimum publication manifest normally carries:

• stable object and immutable version identifiers;
• content hash and source location;
• owner, author, approver and publication activity;
• authority class, scope, audience and entitlement policy;
• approval, publication, effective, review and expiry times;
• predecessor, successor and dependency relationships;
• materiality and correction policy;
• required projections, their owners and acknowledgement rules.

Dublin Core terms supply broadly used properties for identifier, creator, issued time, modified time, source, provenance and rights. The Web Annotation Data Model provides selectors and time states for linking a claim to a specific segment and representation. These vocabularies reduce local ambiguity, but the publication profile should remain small enough that authors and systems can satisfy it consistently.

Validation is more than a schema pass

Syntax validation checks that required fields exist and values have the right form. Semantic validation asks whether they can all be true together. A policy cannot become effective before approval when the governing process forbids it. Two exclusive versions cannot both be effective for the same scope. A version that declares supersedes: v17 must resolve v17 and preserve its history. A restricted object cannot project into an index that cannot enforce the required entitlement.

SHACL demonstrates how graph constraints can be expressed and validated. JSON Schema, relational constraints or ordinary code may be entirely sufficient. The crucial design choice is to make publication conditions executable. A checklist in a policy document does not stop a malformed object from entering a retrieval corpus.

Prepare, project, acknowledge, activate

A high-consequence release should not make a new version eligible the moment the source owner presses Publish. It should first enter a staged state. The pipeline validates the object, records approval, projects the version into each required surface, and receives an acknowledgement containing the stable object ID, exact version ID, content hash, projection policy version and completion time. Only then does the eligibility registry activate the version.

This is deliberately weaker than a claim of distributed atomicity. A vector index, catalogue and cache will not share one database transaction. The pipeline instead makes partial completion visible and prevents an incomplete candidate from silently becoming current. Delivery can be at least once because consumers apply events idempotently by event ID and object version. Periodic reconciliation compares registry state with observed projection state in case an event or acknowledgement was lost.

The fraction is not a quality score. A missing high-risk projection must not be averaged away by several low-risk successes. Required sets therefore come from the object’s control profile. An internal glossary may need only a catalogue and staff search. A customer-treatment policy used by several agents may require catalogue, deterministic policy service, keyword index, vector index, graph projection, answer-cache purge and staff portal before activation.

Attribution must survive transformation

Publication often transforms content: documents are parsed, sections are chunked, tables are normalised, entities are extracted and embeddings are generated. The final claim may depend on one paragraph from one version plus a deterministic calculation. Attribution must therefore travel through the transformation, not be reattached as a decorative source list after generation.

A useful lineage chain is: source version → extraction run → semantic unit → projection version → retrieval event → rendered claim. OpenLineage provides run, job and dataset facets for pipeline lineage. PROV-O supplies a more general entity, activity and agent model. Neither automatically delivers assertion-level support, so the publication profile should preserve selectors or semantic-unit IDs where a reviewer must resolve a particular claim.

Cryptographic provenance can strengthen integrity. The C2PA specification binds signed claims and assertions to digital assets. A valid signature can show that identified bytes and provenance assertions have not been altered undetectably. It does not establish that the signer had institutional authority, that the content remains current, or that a later withdrawal has not occurred. Integrity is one input to authority, not a substitute for current eligibility.

Correction and withdrawal are publication operations

A publication system proves its quality after release, when an error, conflict or change appears. Creation-only pipelines accumulate certainty while losing currency. A correction should classify the change, create an appropriate successor, update relationships, regenerate affected projections and locate prior use. A withdrawal should revoke eligibility immediately, preserve a status record and verify downstream closure.

Material correction versus editorial repair

Not every comma needs a new version identity. The publication policy should define materiality by meaning and consequence. A typo that cannot change interpretation may update a presentation layer with a recorded edit. A changed threshold, exception, obligation, data source, calculation or scope creates a new material version. The predecessor remains addressable, receives a typed relation to the successor and becomes ineligible for current use after the successor activates.

Cross-domain version vocabularies already encode similar relations. DataCite distinguishes new versions and obsolescence. Crossref Crossmark exposes the current status of published content, including corrections, retractions and updates, even when a status indicator is embedded in a downloaded PDF. Scholarly publishing is not enterprise policy management, but it demonstrates an important principle: the current status must remain resolvable from the old object, because old copies continue to circulate.

Thought experiment: deletion without a tombstone

Two harvesters synchronise nightly from the same source. In world A, the source deletes a withdrawn object from its listing. In world B, the source emits a record containing the stable identifier, deletion time and withdrawn status. Both worlds remove the payload. The harvesters behave differently.

In world A, a harvester that sees no record cannot distinguish intentional withdrawal from a temporary listing failure, permissions change or missed page. It may retain its last known copy. In world B, the harvester receives a positive statement that the object is no longer eligible and can remove or quarantine its projection. The OAI Protocol for Metadata Harvesting explicitly includes deletion datestamps and deleted-record headers. The ResourceSync specification likewise represents create, update and delete changes. These protocols expose why absence is a weak revocation signal.

A tombstone should reveal only what policy permits: stable ID, state, event time, authority for the status, successor or correction link where applicable, and a bounded reason class. The sensitive payload can be removed or access-restricted. The tombstone survives long enough for every legitimate consumer to observe it and for past references to resolve to a status notice rather than a broken link.

Revoke first, clean up second

Urgent withdrawal reverses the activation order. The eligibility registry moves the version to suspended or withdrawn immediately. Retrieval admission checks that registry before returning a candidate, so a stale vector may remain physically present but cannot lawfully enter a new context. Invalidation events then remove or quarantine content from indexes and caches. Reconciliation verifies that each registered consumer has applied the revocation.

HTTP itself recognises that caches need invalidation. RFC 9111 defines invalidation as removing a stored response or marking it invalid so that it must be revalidated. Enterprise knowledge has more projections than an HTTP cache, but the principle holds: a changed origin does not, by itself, prove that every reusable representation has stopped serving the old state.

Evidence from scholarly communication shows why this boundary matters. A study of retracted biomedical papers found continued citation and frequent lack of awareness of the retraction in citation contexts. The mechanism is not identical to an enterprise assistant, but the lesson is direct: changing status at the origin does not guarantee that downstream users observe the change. The study is a negative result for origin-only correction.

The Committee on Publication Ethics retraction guidance and its position on visible corrections emphasise linked, prompt and accessible notices. Enterprise content may also face privacy, legal-removal and safety constraints, so the exact public notice differs. The transferable mechanism is persistent status, visible linkage and a record that lets prior users discover the change.

Part III: Make the mechanism fail in a small world

A minimal worked example

Consider one policy object with stable ID kb:policy:hardship. Version v1 states that eligible customers receive a 14-day collections pause. Four projections are required: catalogue, keyword search, vector index and answer cache. The release policy says a version cannot activate until all four acknowledge the exact version and content hash.

Publication of v1 succeeds. A correction creates v2 with a 30-day pause and a supersedes link to v1. In the positive path, every projection applies v2, the cache purges v1 and the verifier grants activation. Withdrawal then writes a tombstone to every projection and confirms that none still serves the object.

In the negative path, the correction event never reaches the vector index or answer cache. The source, catalogue and keyword index look correct. An end-to-end answer test might even pass if it happens to route through keyword search. The publication verifier fails because two required projections still expose v1. That failure is the artefact’s central result: correct source content is insufficient evidence of correct published state.

Executable publication verifier

The following Python 3.10+ programme uses only the standard library and synthetic content. It models exact-version projection, correction and tombstone withdrawal. Save it as publication_pipeline_lab.py and run python3 publication_pipeline_lab.py. The positive cases must pass. The negative correction must fail for the two deliberately dropped consumers.

"""Synthetic verifier for a governed knowledge-publication pipeline.

Python 3.10+. No third-party packages. All identifiers and content are fictitious.
The verifier checks exact versions and persistent withdrawal tombstones across
four required projections.
"""
from __future__ import annotations

from dataclasses import dataclass, field
from hashlib import sha256
from typing import Dict, Iterable, List, Tuple


@dataclass(frozen=True)
class KnowledgeVersion:
    object_id: str
    version_id: str
    text: str
    state: str
    supersedes: str | None = None

    @property
    def digest(self) -> str:
        return sha256(self.text.encode("utf-8")).hexdigest()[:12]


@dataclass
class Projection:
    name: str
    active: Dict[str, Tuple[str, str]] = field(default_factory=dict)
    tombstones: Dict[str, str] = field(default_factory=dict)

    def publish(self, item: KnowledgeVersion) -> None:
        self.active[item.object_id] = (item.version_id, item.digest)
        self.tombstones.pop(item.object_id, None)

    def withdraw(self, object_id: str, version_id: str) -> None:
        self.active.pop(object_id, None)
        self.tombstones[object_id] = version_id


REQUIRED = ("catalogue", "keyword_search", "vector_index", "answer_cache")


def fresh_projections() -> Dict[str, Projection]:
    return {name: Projection(name) for name in REQUIRED}


def fan_out(
    projections: Dict[str, Projection],
    event: str,
    item: KnowledgeVersion,
    drop_for: Iterable[str] = (),
) -> None:
    dropped = set(drop_for)
    for name, projection in projections.items():
        if name in dropped:
            continue
        if event in {"PUBLISH", "CORRECT"}:
            projection.publish(item)
        elif event == "WITHDRAW":
            projection.withdraw(item.object_id, item.version_id)
        else:
            raise ValueError(f"Unknown event: {event}")


def verify(
    projections: Dict[str, Projection],
    item: KnowledgeVersion,
    expected: str,
) -> List[str]:
    failures: List[str] = []
    for name in REQUIRED:
        projection = projections[name]
        if expected == "ACTIVE":
            observed = projection.active.get(item.object_id)
            wanted = (item.version_id, item.digest)
            if observed != wanted:
                failures.append(f"{name}: observed {observed}, expected {wanted}")
            if item.object_id in projection.tombstones:
                failures.append(f"{name}: active object also has a tombstone")
        elif expected == "WITHDRAWN":
            if item.object_id in projection.active:
                failures.append(f"{name}: still serves {projection.active[item.object_id]}")
            if projection.tombstones.get(item.object_id) != item.version_id:
                failures.append(f"{name}: missing tombstone for {item.version_id}")
        else:
            raise ValueError(f"Unknown expected state: {expected}")
    return failures


v1 = KnowledgeVersion(
    object_id="kb:policy:hardship",
    version_id="kb:policy:hardship:v1",
    text="Eligible customers receive a 14-day collections pause.",
    state="effective",
)

v2 = KnowledgeVersion(
    object_id=v1.object_id,
    version_id="kb:policy:hardship:v2",
    text="Eligible customers receive a 30-day collections pause.",
    state="effective",
    supersedes=v1.version_id,
)

# Positive path: every required projection applies every event.
good = fresh_projections()
fan_out(good, "PUBLISH", v1)
assert not verify(good, v1, "ACTIVE")
print("positive publish: PASS")

fan_out(good, "CORRECT", v2)
assert not verify(good, v2, "ACTIVE")
print("positive correction: PASS")

fan_out(good, "WITHDRAW", v2)
assert not verify(good, v2, "WITHDRAWN")
print("positive withdrawal: PASS")

# Negative path: two consumers miss the correction event.
bad = fresh_projections()
fan_out(bad, "PUBLISH", v1)
fan_out(bad, "CORRECT", v2, drop_for={"vector_index", "answer_cache"})
failures = verify(bad, v2, "ACTIVE")
assert failures, "The negative control must expose stale projections."
print("negative correction: FAIL as expected")
for failure in failures:
    print(" -", failure)

positive publish: PASS
positive correction: PASS
positive withdrawal: PASS
negative correction: FAIL as expected
 - vector_index: observed ('kb:policy:hardship:v1', '6709027b26a5'), expected ('kb:policy:hardship:v2', 'f42912b8d5e9')
 - answer_cache: observed ('kb:policy:hardship:v1', '6709027b26a5'), expected ('kb:policy:hardship:v2', 'f42912b8d5e9')

The programme omits authentication, effective time, retry queues, partial chunk failure and impact analysis so the causal feature remains visible. The verifier does not ask whether a search happens to return v2. It asks whether every declared projection carries the exact release state. A production implementation should obtain observations independently where possible; a consumer should not be allowed to mark itself healthy merely because it accepted a message.

A synthetic propagation test

Take six surfaces: origin, catalogue, keyword index, vector index, policy API and answer cache. A correction occurs at minute zero. In an origin-only design, the source becomes current immediately while five derived surfaces remain stale until a nightly rebuild. In an evented design, acknowledgements arrive after 1, 2, 4, 8 and 12 minutes. The values below are synthetic, chosen to expose the shape rather than estimate a real platform.

The result does not prove event-driven systems are always faster. A badly operated event bus can be slower than a simple rebuild. It shows which variable a release process must observe: stale eligible surfaces over time. The origin-only design has no direct measure of that state. The evented design can fail too, but acknowledgements and reconciliation make the failure inspectable.

The serious negative control

Now remove the conditions that justify the machinery. Put low-consequence, low-volatility content in one authoritative content-management system. Serve every request directly from that system. Keep no vector copy, no generated answer cache, no exported derivative and no independent catalogue. Use standard HTTP validators and a short cache lifetime. In this bounded world, an edit plus cache invalidation may be a sufficient publication mechanism.

This negative control matters. It prevents “governance” from becoming an excuse to build a platform around every paragraph. The pipeline earns its cost when content has consequence, changes materially, fans out to independent surfaces, or must support reconstruction and withdrawal. When those burdens are absent, preserve the simple baseline.

stateDiagram-v2
  [*] --> Claim
  state "Thought experiment: identical<br/>paragraphs, unequal authority" as Claim
  state "Four properties of published<br/>knowledge" as Test
  state "One object, several fallible<br/>projections" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

A production-shaped correction

The following Northbridge Bank scenario is synthetic. It combines common enterprise mechanisms without describing a client deployment or measured outcome. Its purpose is to show how release, activation, correction and impact review differ.

Northbridge maintains a hardship-treatment procedure used by a staff portal, a deterministic eligibility service and an assistant that drafts case notes. The procedure has stable object ID policy:hardship:treatment. Version 42 is currently effective. A policy team prepares v43, changing a threshold and clarifying one exception. The source authoring system records the draft, but the version cannot leave the candidate state until required metadata, references and structured rule examples pass validation.

The policy owner approves v43 at 09:10. Its effective time is 10:00. The pipeline stages the exact version in the catalogue, keyword index, vector index, graph, policy API and staff portal. Each projection acknowledges v43 and its hash. The answer cache acknowledges purge of any v42-derived entry. At 09:42 the publication receipt is complete, but the eligibility registry still resolves v42 because v43 is future-effective. At 10:00 the registry activates v43. There is no period in which half the estate treats it as current.

At 13:15, quality review finds that a table row reversed the intended comparison operator. The source team does not overwrite v43. It opens a material correction linked to the exact section, creates v44 and marks v43 suspended for new decisions. The registry revocation prevents v43 from entering new contexts immediately. The pipeline stages v44, runs the positive and negative rule examples, obtains approval and projects it. Once the receipt closes, v44 activates.

Correction is only half the work. Usage events identify decisions and generated notes that cited v43 between 10:00 and 13:15. The materiality rule does not assume that every one is wrong. It selects cases whose input fell near the corrected threshold or used the affected exception. Those cases enter review with the v43 evidence packet, the correction notice and the v44 rule. Historical receipts remain immutable. The correction adds a new evidential fact; it does not rewrite what the workflow saw earlier.

What the scenario changes

The publication pipeline does not ask a language model to notice which version is current. It makes current eligibility a deterministic registry decision. It does not rely on index rebuild logs as proof of usable publication. It checks exact-version projection receipts. It does not delete v43 and lose the basis of earlier decisions. It marks v43 ineligible, preserves its lineage and opens a bounded impact review.

The scenario also preserves a human decision right. The pipeline can identify affected cases, reconstruct the evidence and calculate whether a threshold changed. It should not silently decide redress, customer communication or control breach classification unless a separate authorised process grants that action. Knowledge governance improves the evidence boundary; it does not acquire authority merely because it is well instrumented.

Part IV: Operating the pipeline

The hard part is not choosing a message bus. It is establishing ownership and a complete consumer boundary. A publication service cannot promise withdrawability when unregistered teams copy its content into private indexes. Every supported consumer should have an owner, purpose, projection type, version semantics, entitlement capability, correction and deletion capability, acknowledgement contract, service objective and reconciliation schedule.

The consumer registry is part of the control

A consumer registration should answer: Which object classes can it ingest? Does it retain full text, metadata, embeddings, generated answers or all four? Can it stage a future version without exposing it? Can it process a tombstone? Can it report the exact active version independently? How quickly must it apply an urgent revocation? Which past outputs or decisions can it trace back to the object?

Unknown consumers are not a documentation inconvenience. They are an unbounded revocation surface. Access logs, event subscriptions, service catalogues and periodic scans can reveal undeclared copies, but technical discovery will never be perfect. The assurance claim should therefore state the declared boundary and any known export channels. “Withdrawable” means withdrawable across registered, authorised use, not metaphysical erasure.

Lifecycle states need retrieval semantics

Measure publication and revocation separately

Operational dashboards often count documents ingested, chunks created and index jobs completed. Those measures can all improve while the estate becomes less trustworthy. A decision-relevant set focuses on state agreement and recovery:

• projection completeness at activation: exact-version acknowledgements divided by required projections, with no compensating average across mandatory surfaces;
• activation lead time: approval to complete receipt, separated from planned future-effective delay;
• correction propagation latency: correction event to exact-version acknowledgement by each projection;
• revocation closure latency: withdrawal decision to zero authorised stale-serving surfaces;
• stale-serve rate: adversarial requests that still return a superseded, suspended or withdrawn version;
• lineage coverage: material claims and derived artefacts that resolve to exact source versions;
• unknown consumer count: detected copies or subscriptions outside the registry;
• impact-review closure: affected prior decisions dispositioned against the correction policy.

Report percentiles and the long tail. A median revocation time can hide one rarely used cache that serves a withdrawn instruction for days. Test with failure injection: drop a correction event, reorder two versions, replay an old publish event, omit a tombstone, return a false acknowledgement, restore a stale backup and disable the eligibility registry. The release gate is credible only if these failures are detected and routed to an owner.

Release roles and decision rights

The content owner decides meaning and scope. The accountable approver grants institutional authority. Records, legal, privacy and security define retention and removal constraints. The knowledge platform implements identifiers, validation, projection and revocation. Consumer owners prove they honour lifecycle events. Product teams record use and outcome lineage. An incident owner coordinates urgent suspension and impact review.

These roles should not collapse into the model or the platform team. A model may propose metadata, classify a change or identify candidate dependencies. It should not infer approval from polished language, declare its own source current, or withdraw an object without delegated authority. The publication pipeline is precisely where institutional judgement becomes a testable machine contract.

Control-profile decision instrument

Three variables explain most of the control burden. Consequence asks what happens if the wrong version is used. Volatility asks how often meaning or applicability changes. Replication asks how many independent surfaces can serve or derive from the object. The figure below turns those variables into an architecture choice.

Implementation sequence

1. Choose one consequential domain. Inventory decisions and the small set of governing objects rather than ingesting an entire repository.
2. Mint stable object and version identities. Record authority, scope, effective state, provenance and correction policy.
3. Register every production projection. Include caches, exports and generated artefacts, not only search indexes.
4. Implement executable validation. Test required fields, lifecycle consistency, scope conflicts, entitlement capability and predecessor resolution.
5. Add staging and publication receipts. Keep candidates ineligible until mandatory projections acknowledge the exact version and hash.
6. Add revocation before optimisation. Build suspension, tombstones, invalidation and readback while the domain is still small.
7. Capture use lineage. Record which object version supported each material claim or decision so correction can find its blast radius.
8. Inject failures. Miss events, lie in acknowledgements, replay old versions and restore stale backups; convert every escape into a regression test.

The strongest objection

A critic may argue that ordinary source control, approval workflow and periodic indexing already solve this problem. In a bounded corpus with one serving surface, they may. The proposal weakens if teams can show that every consumer resolves the authoritative source at request time, that cache invalidation is bounded and observable, that material versions remain reconstructible, and that withdrawal has no independent projection to chase.

The proposal strengthens as soon as an organisation adds replicas whose state can diverge: search indexes, embeddings, graphs, generated-answer caches, document exports, fine-tuning corpora or downstream applications. The key test is empirical. Inject a correction and a withdrawal, then ask each surface what it can serve. If simple mechanisms achieve the required closure reliably, keep them. If they cannot, the extra pipeline is not ceremony. It is the missing causal mechanism.

Failure boundary

No publication architecture can promise perfect recall of every copy. A user may photograph a screen. An email attachment may leave the managed estate. A model may have absorbed content during training, in which case retrieval deletion does not remove the learned association. A legal hold may require retaining bytes that current users must not access. A downstream system may be unavailable during revocation.

The defensible claim is narrower. The pipeline can stop future authorised retrieval within its declared boundary, preserve a resolvable status, identify known derivatives and prior uses, retry or quarantine unreachable consumers, and expose unresolved residue to an accountable owner. It should never translate “the source was deleted” into “the knowledge is gone.”

sequenceDiagram
  participant Q as Question
  participant M as Mechanism
  participant E as Evidence
  participant D as Decision
  Q->>M: The edit that did not travel
  M->>E: Thought experiment: identical paragraphs, unequal authority
  E-->>M: compare rival explanations
  E->>D: Make reversibility a release condition
  D-->>Q: revise scope or act

Make reversibility a release condition

The most dangerous knowledge defect is often not an invented sentence. It is an old, unauthorised or corrected sentence that remains easy to retrieve. Source repositories cannot solve that alone because publication creates a distributed set of representations, relationships and uses.

The architecture decision is to separate authoring from activation. Give every governed object stable identity and immutable material versions. Validate authority, scope and lifecycle before projection. Stage the version across required surfaces. Activate only from an exact publication receipt. When meaning changes, publish a typed successor. When authority ends, revoke eligibility first, emit a tombstone, invalidate every registered projection and prove closure through readback and reconciliation.

This design will not make content infallible. It does something more practical: it makes correction and withdrawal ordinary, testable capabilities rather than promises made after an incident. The research programme that follows is clear. Measure stale-serving surfaces under injected correction and revocation, compare simple and evented baselines, and scale the pipeline only where consequence, volatility and replication justify it.