Back to course syllabus
Design answers that can show their evidenceLesson 3 of 11

How do you approve sources before adding them to a RAG knowledge base?

Decide which exact documents and revisions may ground a RAG answer by checking authority, ownership, use rights, audience, effective dates, and conflicts before indexing.

DECISION TOPICGrounded answers
LESSON OUTPUT · rag-source-registerUPDATED · Oct 1, 2026
GUIDES READ0 / 11
HOW TO USE THIS LESSON

Read with one real task in mind, then complete the workbench. The lesson is done when another person can review what you made.

A knowledge base can retrieve the wrong document perfectly. A shared folder may contain a signed procedure, an advance draft, an FAQ that paraphrases it, and a copied vendor page. Search relevance does not decide which one may govern a customer’s answer. Make that decision before chunking and indexing, while the original record and its accountable owner are still visible.

This guide starts after the decision to use RAG and ends with an admission record for each exact source revision. It does not measure search rank, enforce a caller’s permissions, or prove that a later source change reached the index. Those are separate retrieval, access, and index update checks.

Approve a version for a purpose, not a file name forever

Begin with the questions the assistant is allowed to answer. For each candidate, ask who created the original, where the controlled record lives, who may approve its use, and which product, region, population, and period it covers. An approved document is not universally authoritative: a service manual can govern a repair instruction for one hardware revision while an FAQ only explains how to find the manual. An uploader or index operator is not automatically the policy owner.

Record the stable source ID and revision separately from the file name or URL. Keep a pointer to the original record, its publication date, effective start and end, and the revision it supersedes. A file hash helps detect changed bytes; it does not establish whether the content is true or approved. W3C PROV-O supplies useful relations such as derivation, revision, attribution, and invalidation. You can borrow those lineage concepts in ordinary metadata without implementing RDF, OWL, or PROV-O; they do not decide the business authority of a document.

NIST’s voluntary AI Risk Management Framework lists availability, representativeness, and suitability among the data-selection considerations in Map 2.3. Its Govern 6.1 outcome addresses intellectual-property and other rights risks from third parties. For an intake gate, this suggests recording who has checked the intended use of an external copy. A public web link, by itself, is not a recorded approval to copy, embed, or redistribute its contents. Legal permission and source accuracy are distinct questions.

Give every candidate a disposition

Use five decisions for the proposed answer scope:

DecisionWhen it fitsServing consequence
AdmitOrigin, owner, rights review, audience, effective scope, and conflict rule are recorded and approved.Eligible only for the named question class and valid period, subject to runtime access checks.
StageThe revision is approved but becomes effective later.Exclude it from current-as-of answers. Permit a labeled future-policy answer only if its disclosure is approved; schedule the changeover and verification.
HoldAn owner, rights decision, effective date, or material conflict is unresolved.Do not let it ground a production claim; send the open question to its owner.
RejectThe responsible reviewer has denied this copy or its copying rights for the proposed use.Never put it in the serving path, even for historical questions.
RetireA previously admitted revision is superseded or withdrawn from current use.Exclude it from current answers. Allow a superseded revision for dated historical questions only with explicit approval; a withdrawal for error needs its own owner decision.

Do not let the newest edit timestamp settle an authority conflict. A freshly edited summary can contradict a still-effective signed policy. Compare the exact clauses and their scopes, then ask the steward with decision authority to resolve the difference. If two effective authorities disagree and no priority rule exists, hold the affected claim. The no-evidence response gate determines what to tell the user while the issue remains open.

Carry the approval into the serving path

The register should produce an eligibility rule: source ID and revision, admitted question class, audience, effective window, and current state. A future or held revision can remain in a controlled staging store, or the serving system can exclude it with an enforced filter. A sentence in the model prompt is not an admission control. Sample indexed children to ensure that parent ID, revision, scope, and eligibility state survive splitting. Keep restricted appendices as separate permission units if their audience differs from the main document.

Azure AI Search indexers can pull text and metadata from configured sources into an index. Successful ingestion therefore shows a pipeline moved data; it does not certify that the source owner approved a policy or that every query enforces its audience. The actual document access trace checks request-time authorization. When an owner changes a source state, the index refresh trial checks that old chunks, vectors, caches, and citations have followed. Do not label the served knowledge base current merely because the register was edited.

Example one: a future manual appears early

In a fictional equipment-support library, AsterLab Pump P4 Manual Rev B is approved and effective on 2026-10-01. It specifies a 90-day filter interval. Rev C is also approved, but its 60-day interval takes effect on 2026-11-01. A dealer FAQ edited on 2026-09-29 already says “60 days” without stating that future date.

The source register admits Rev B for current P4 interval questions and stages Rev C. The FAQ can help users find the official manual, but its interval claim is held until the engineering steward resolves the mismatch and states its scope. A question about the rule as of 2026-10-15 needs Rev B. If someone asks in October what is planned for 2026-11-15, the assistant may state that the approved Rev C specifies 60 days from November 1, clearly marked as future-effective, only if the owner has approved advance disclosure and that future-answer route has been verified. If advance disclosure is forbidden, the register must record and enforce that restriction. Once November 1 arrives, current-as-of questions need Rev C after its serving changeover is verified. If dated historical questions are allowed, Rev B may remain retrievable for that narrow purpose, with the date made explicit. “Keep only the newest PDF” would fail both the present and historical cases.

Example two: a newer FAQ contradicts a policy

In a second fictional library, HarborWorks HR Policy TR-4 v2 was approved on 2026-09-15 for North-region employees and sets a lodging cap of 140 units per night. A staff FAQ edited on 2026-09-28 says 180 units without citing an approved amendment. An external partner also posted a copy of a travel guide, but the team has not reviewed its intended copying and indexing rights. A contractor asks about the cap, adding a population the policy does not cover.

The register admits TR-4 v2 only for its documented employee and region scope. It holds the conflicting FAQ cap and the external copy for separate owner and rights review; neither the later timestamp nor the public URL makes them an authority. The contractor question remains outside TR-4’s answer scope. HR must resolve the cap conflict or identify an applicable contractor policy before the assistant makes a specific entitlement claim. The register records the disputed clause and reviewer rather than inventing a blended number.

Use the register as a release input

Fill one row per exact revision in the workbench below. A reviewer should be able to answer: which source can support which claim for which requester and date, and who approved that choice? Add negative controls before release: a held FAQ must not ground a cap, a staged manual must not answer a current question, and a retired revision must not masquerade as current. Pair each with an admitted source that should still be found, so a blanket empty index cannot appear to pass.

The intake record is a decision, not a live index test. Feed its expected eligible set to retrieval evaluation; use the dedicated access and refresh checks for runtime enforcement and change propagation. Reopen the admission decision when the owner, source terms, authority, scope, or version lineage changes.

Boundary

An admission gate cannot prove that an approved source is objectively correct, that parsing preserved its clauses, or that the generated answer follows it. It also cannot grant a caller access merely by recording an audience field. Keep a named source steward, a review trail, and a route for unresolved authority; ask the model to use approved evidence, not to become the approving authority.

SOURCES CHECKED

Which first-party sources informed this guide?

Sources anchor definitions, risk boundaries, or operational facts. The decision framework and workbench are original to AI Vista.

  1. NIST AI Risk Management Framework CoreChecked 2026-10-01
  2. W3C PROV-O provenance ontologyChecked 2026-10-01
  3. Azure AI Search RAG overviewChecked 2026-10-01
  4. Azure AI Search indexer overviewChecked 2026-10-01
  5. Azure AI Search document-level access controlChecked 2026-10-01

AI tools may assist with research, outlining, and language editing. Facts, cases, and final wording are reviewed by the editor. Report an error through the contact page.

TAKEAWAY TOOL

RAG source admission register

Approve exact source revisions for named questions, audiences, and dates before indexing.

rag / source / register
USE THIS WHENBefore a new source or revision becomes eligible for a RAG answer
YOU WILL GETA version-level admit, stage, hold, reject, or retire decision with an accountable owner and dated scope

This workbench saves a draft in this browser. Use synthetic source IDs and controlled evidence pointers; do not paste internal source links, restricted clauses, real ACLs, license agreements, or personal information.

HOW TO USE01—03
  1. 01
    Describe the taskDescribe the result with a sanitized summary.
  2. 02
    Fill the decision fieldsRecord input categories, risk, evidence pointers, and handoff.
  3. 03
    Ask a colleague to reviewThe tool is ready when someone else can restate the decision.
DONE WHENFields are complete, boundaries are clear, and the result is reviewable.
Edits save automatically

LESSON READ

Finish the workbench, then mark it read.

The read state updates the syllabus and your course progress.

  1. 01Fields filled
  2. 02Case tested
  3. 03Reviewable

GUIDE PRACTICE NOTES

Leave a judgment you can review later.

The fictional examples below show the format. Your own notes stay in this browser. Record what worked, which boundary failed, or one question worth testing.

↗
RELATED GUIDEHow do you approve sources before adding them to a RAG knowledge base?See examples and local notes →
0 examples and local notesINSIGHTS · QUESTIONS · IDEAS