Skip to content

Chapter 4.12 — Knowledge source catalog and governance

🎯 Objective

Consolidate, in a single place, a responsibility that appears scattered across the rest of the book: knowing which knowledge sources exist, whose they are, where they come from, how fresh they are and who may use them. RAG, GraphRAG, semantic memory and fine-tuning all consume "corporate knowledge" — but rarely does anyone maintain the governed inventory of those sources. This chapter is about that inventory.

🧭 A note on the name. A "registry" / "catalog" of knowledge sources is established data governance vocabulary (data catalog, source registry) — it is not a product name. That is why it is used here. Names like "Memory Bank", "Engine Orchestration" or "Evaluation Center", sometimes proposed to organize an AI platform's capabilities, are not adopted in this book: they sound like commercial modules, and the concepts behind them already have better and more precise names (respectively persistent memory — Ch. 3.6, harness/runtime — Ch. 3.3-3.4, and eval harness — Ch. 2.11, 5.4). The concept of a source catalog, on the other hand, was not consolidated in the book — hence this chapter.

🧠 Core concept

A knowledge source catalog is the metadata about the sources, distinct from the vector index or the graph itself. For each source (a document collection, a database, a graph, an external feed), it records:

Attribute Why it matters
Identity and description Knowing what the source is and what it covers
Owner Who is accountable for correctness, updates and access
Origin / lineage Where the data came from and which transformations it went through
Sensitivity classification Public, internal, confidential, restricted
Access policy Which roles/tenants may retrieve from it
Jurisdiction / residency Where the data may be processed and stored
Update cadence and freshness How current it is; median and p95 age of items
Version Version of the content, the pipeline and the embedding model used
Lifecycle status Active, deprecating, quarantined, removed
Traceability Linking a RAG answer back to the source and the exact version

The thesis is the same as the rest of Part 4: what is not cataloged is not governable. Without a catalog, nobody answers "from which source, in which version, did this answer come?" — and that is exactly the question that appears in an audit and in an incident.

🏗️ How this shows up in production

The concept has been touched at several points; the catalog is what connects them:

  • RAG ingestion (Ch. 2.6) produces lineage and sensitivity classification per document — the catalog aggregates this by source.
  • Knowledge graphs (Ch. 2.9) need an ontology owner and a schema version — they enter the catalog.
  • Data quality (Ch. 1.2) defines per-dataset contracts — the catalog references those contracts.
  • Supply chain (Ch. 4.9) treats datasets and models as artifacts with provenance — the source catalog is the "knowledge" face of this.
  • Governance and audit (Ch. 4.11) requires an inventory — the source catalog is part of that inventory, alongside the model and agent inventory.

🚨 Failure modes

  • "Ghost" source. A RAG index points to a drive nobody maintains; the content ages and nobody notices.
  • No owner. A wrong document is retrieved and cited; there is no one to escalate the correction to.
  • Mixed jurisdictions. Content from one region enters an index served to another, with no residency record.
  • Blind re-embedding. The embedding model is swapped without knowing which sources/indexes depend on it.
  • Contaminated source without quarantine. A malicious document (vector poisoning, Ch. 4.5) has no fast removal path because the source is not cataloged.

🛡️ Controls and practices

  • A versioned catalog (it can be a declarative file, a governed table or an existing data catalog — the point is that it exists and has an owner).
  • Every source has a named owner (technical and business).
  • Mandatory classification when a new source is added; a source without classification does not go to production.
  • A per-source access policy referenced by policy-as-code (Ch. 4.7) and enforced in the storage/retriever (Ch. 2.7).
  • Freshness and indexing lag monitored per source, with an SLA (Ch. 5.5).
  • An explicit lifecycle: approval to add a source, quarantine for a suspect one, deprecation with a window (Ch. 7.4).
  • End-to-end traceability: the answer cites the source; the source appears in the catalog; the catalog links to the version and the owner.

📌 Checklist

  • [ ] Is there an inventory of knowledge sources with an owner per source?
  • [ ] Does each source have a recorded sensitivity classification and jurisdiction?
  • [ ] Is the per-source access policy enforced in the storage/retriever, not just in the prompt?
  • [ ] Are freshness and indexing lag monitored per source?
  • [ ] Is there a process to approve, quarantine and deprecate sources?
  • [ ] Is it possible to link a RAG answer back to the source and the exact version?

📚 References