Module 12 Summary
The idea this module was built around
Retrieval quality is a data-preparation problem long before it is a model problem. The shape of the table decides what an assistant can find, cite, and be prevented from seeing.
What you can now do
- Build a retrieval table at one row per retrievable thing, with a stable unique identifier
- Attach the metadata that makes an answer checkable: identity, freshness, provenance, visibility, facets
- Enforce access in the query rather than in the prompt
The three rules this module leaves you with
Content must name its own subject. A chunk reading Status completed. Total 1000.00. is unusable alone - the model cannot tell which order it describes and will attach it to the wrong one. Order 501 placed on 2026-06-21 for IN. Status completed. Total 1000.00. survives retrieval on its own.
Identifiers must be stable. Derive doc_id from the source key, never from a row number, or a rebuild renumbers everything and invalidates every citation ever issued.
Permissions belong in the WHERE clause. "Only use documents the user may see" is a request to a model, not an access control. If a restricted row reaches the context window, treat it as disclosed.
Figures worth remembering
1,000 orders in, 1,000 rows out, 1,000 distinct doc_id - the grain check that stops fan-out from duplicating every fact you are about to expose. And 62 orders belong to customers with no recorded country: without COALESCE, their content reads for . Status completed. and teaches the model nothing.
Before you move on
Take any table you would point an assistant at and ask the three questions: does one row equal one citable thing, does the content stand alone, and is the filter enforced in the query?