Retrieval can find the relevant policy and still supply the wrong evidence: the indexed revision may be superseded, outside the user's access scope, or approved for a different purpose. Better ranking cannot resolve a lifecycle decision that the source system never recorded.
Before expanding enterprise RAG, make someone accountable for those decisions and make the decisions observable in retrieval. The owner determines which source is authoritative and when its status changes. The retrieval team implements that status alongside access checks. Neither role substitutes for the other.
Define what the collection is allowed to answer
Start with a collection whose purpose is specific enough to test: approved support procedures for a product, current underwriting guidance for a defined workflow, or versioned engineering runbooks. "All company knowledge" leaves accuracy, access and conflict resolution without useful boundaries.
For each collection, identify an accountable person or function with a maintained contact and a backup. A role label without anyone accepting the work is insufficient. The owner needs authority to correct, supersede or suspend sources and a route for resolving disagreement with other source owners.
Record the questions the collection supports, its authoritative source, its review trigger and the response when evidence is missing. Review can follow a source change, a domain-specific interval, an incident, or a combination. Age is a signal to review; it is not proof that a document is false.
For an already approved public archive, an external authority and an internal custodian may provide the necessary accountability. Historical analysis may legitimately retrieve old revisions. Mark that purpose explicitly so historical evidence cannot silently become current operating guidance. An unowned collection intended to drive consequential actions should remain outside that workflow until its accountability is resolved.
Carry the owner's decision into the retrieval path
The following is a proposed collection contract, not a product standard. Keep each field only where it changes an eligibility or incident decision.
| Record | Decision it supports | Failure to test |
|---|---|---|
| Source identifier and revision | Which original supports this chunk? | An answer cites the current title but uses an older revision. |
| Accountable owner and escalation route | Who can resolve a disputed source? | A team name exists, but nobody accepts the correction. |
| Status, effective period and superseding source | Is this evidence valid for the requested purpose and date? | Old and new policies remain equally eligible. |
| Verification record and review trigger | Has the responsible function checked this use? | A recent edit is mistaken for substantive approval. |
| Collection, tenant and access metadata | May this caller receive these chunks? | Authorized collection membership is mistaken for access to every document. |
Metadata does nothing until the application applies it. A retrieval_eligible flag does not exclude a document by itself; a filter, a source selection rule or a later eligibility check must consume it. The same constraint applies to access metadata.
Microsoft's Azure AI Search security-filter pattern illustrates the distinction: the application applies principal identifiers in a query filter, but those identifiers are strings, not authentication. A system using that pattern must establish the caller's identity and construct the filter from trusted identity data. A user-supplied group name is not an access grant.
Trace the rule through every retrieval path, including lexical search, vector search, fusion and reranking. A filtered path can lose its protection if another path contributes unrestricted candidates. Check the final evidence set before it is supplied to generation, with current authorization where the workflow requires it. Collection ownership determines source authority; it does not grant access to another tenant's content.
Supersession is a transition, not a checkbox
When a replacement is approved, the owner names the revision it replaces and the point at which the replacement takes effect. The ingestion team carries that change into chunks, indexes and caches. Record which source revision each generated answer used so a disputed answer can be traced back.
A source marked deprecated can remain searchable in a historical workflow while being excluded from current-policy answers. Deleting it is a separate decision, with separate retention and storage consequences. Exclusion from RAG does not prove physical deletion.
For a consequential workflow, define what happens during propagation. If the index cannot yet distinguish the active revision, suspend the affected answer or route it for review. Do not silently choose between conflicting policies by similarity score. A less consequential historical search can return both, with their dates and status visible.
A status change also needs verification outside the ingestion job's success message. Query for the superseded source through the paths users can reach. Check saved retrieval results and answer caches: a cached answer can retain stale evidence even after new searches exclude it. This is the integration work behind a lifecycle rule, not an instruction to build a new governance platform.
Separate source defects from retrieval defects
When an answer is wrong, inspect the cited revision before tuning embeddings.
If the approved source is itself wrong, the owner corrects it and identifies affected downstream uses. If the correct source exists but was not retrieved, inspect ingestion, candidate generation, filtering and ranking. If both conflicting revisions were retrieved, inspect lifecycle state and the answer's treatment of dates. If the evidence is sound but the answer misstates it, test generation and citation fidelity.
A cluster of incidents from one collection is a reason to investigate that collection, not proof that its owner failed. A broken connector, stale cache or mismatched filter can create the same pattern. The distinction is developed in When Enterprise RAG Needs a Data Owner, Not Another Vector Database.
Do not close an incident because a new owner field exists. Close it against the failed user question and the observed retrieval result after correction.
Test an expansion before accepting it
Use synthetic documents or approved test fixtures to exercise the collection's rules. These are proposed acceptance tests; they are not reported AW deployment results.
- Approve a replacement and ask the same current-policy question. Verify the answer's source revision and confirm the superseded revision cannot contribute current guidance.
- Ask a historical question. Verify the older revision remains available only where the product's historical scope and caller's access permit it.
- Change the caller's access while retaining the same question. Verify all contributing search paths and cached results honor the changed permission.
- Supply a draft and a conflicting active source. Verify the workflow follows its declared authority rule or abstains; similarity cannot decide approval status.
- Exceed the review trigger. Verify the collection's documented response: owner review, qualified use or suspension, according to the task's consequence.
Retain source identifiers, revisions, decision timestamps and the minimal evidence needed to reproduce each failure. Keep restricted document text out of broadly accessible telemetry. The production-ready RAG checklist covers the adjacent pipeline work; this pass establishes who controls the evidence and whether that control reaches the answer.
Expand the corpus when these transitions work for the intended use. If the owner can deprecate a source but the answer can still cite it as current, the missing work is between the source decision and the serving path.