NVIDIANVIDIA-Certified Professional: Agentic AI2026-106.5 Enable real-time access and reasoning over structured and unstructured knowledge.
Join authorized facts to attributable passages
Completed by the knowledge check
Learning objective
Fuse structured and unstructured evidence with authorization and provenance checks.
Core idea
A structured result can establish what happened; a document can explain the rule that applies. Combining them requires a join in meaning as well as a join in identifiers. You need the same entity, applicable period, authorized audience, and attributable source before the model reasons across both.
See 6.5.1 for query execution and 6.3.3 for source identity, ingestion permissions, and trusted query-time filtering. This lesson owns the query-time decision: which retrieved facts may enter the combined context, which claims they support, and when the assistant must withhold a conclusion. OWASP’s vector and embedding guidance identifies both cross-tenant leakage and conflicts between federated sources as risks of retrieval systems.
How it works
Apply access decisions before synthesis
Retrieve each source under the authenticated caller’s scope. A permitted SQL result does not confer permission to read every document describing that customer. Conversely, a public policy does not authorize disclosure of a private operational record. Apply access decisions independently, then combine only allowed results. Filtering a final answer after unrestricted retrieval leaves unauthorized material inside the model context.
Use the NVIDIA RAG Blueprint’s trusted collection_names and mandatory filter_expr path from 6.3.3 for documents, and the restricted query connection from 6.5.1 for structured data. Authorize these paths independently before fusion; a successful access check on one side cannot stand in for the other. Keep enable_filter_generator disabled on the protected document path: the metadata documentation shows it rewriting an existing filter_expr, and generation failures can also remove filtering. The fusion stage accepts only results accompanied by each path’s successful access decision.
Preserve what each source actually proves
Represent the combined inputs with an application-defined source record. For a database result, retain the query identifier, authorized scope, entity key, covered interval, execution time, and returned values with units. For a passage, retain document identity, version, locator, applicable period, and the access decision. These fields let the synthesis stage distinguish a claim about a customer from a generic description of the product.
Populate the document source record from the RAG server API rather than relying on a rendered citation panel. Set the generation request’s enable_citations to request citations, then read the response’s citations.results. Each SourceResult carries document_id, document_name, score, and metadata, including metadata.content_metadata. Use document_id as the returned source identifier and document_name as its readable label; neither replaces the applicable version and locator needed for a claim.
Preserve an application-defined version field in content_metadata during ingestion, and carry it into the source record with the returned page information. The metadata documentation identifies page_number as an extracted field that appears in citations; the API schema also exposes metadata.page_number. Resolve the supplied locator and version against the source record instead of inventing a page when one is missing. For a passage without a page locator, retain another verified source locator or mark the citation incomplete before asserting a claim that requires it.
The API describes score as relevance. Use it for matching, not to decide whether a policy governs a transaction. A high-scoring result with a missing version can still be unsuitable for an account-specific interpretation. The sample UI shows document names, relevance scores, and previews for inspection, but is documented for experimentation rather than production; the fusion stage consumes and validates the API fields directly.
Join by stable entity identifiers and applicable dates, not similar names. An application-defined claim ledger can assign each proposed sentence its supporting result IDs and passage IDs. A calculation cites its database inputs; a policy interpretation cites its clause. A conclusion spanning both requires both. If one side is missing, return the supported partial answer and identify the unresolved part without revealing a restricted source’s content.
Treat conflicting sources as a decision about authority. A product overview may describe a standard allowance while an account-specific agreement overrides it. The business owner defines that precedence in the source record’s authority classification. If two applicable authoritative sources still disagree, preserve the disagreement and send the unresolved interpretation to the designated owner. More fluent synthesis does not resolve incompatible premises.
Key distinctions and trade-offs
| Check | Question it answers | Mechanism in this design | Cost or limitation |
|---|---|---|---|
| Authorization | May this caller receive this material? | Identity-derived collection selection and mandatory filter_expr | Requires trusted metadata and protection against backend bypass |
| Relevance | Does the material address the question? | Optional criteria and retrieval ranking | A strong match may be unauthorized or inapplicable |
| Provenance | Which source and version support the claim? | Source record and claim ledger, surfaced through citations | Adds metadata and context overhead |
| Applicability | Does this rule govern this entity and period? | Stable-key join plus effective interval and authority classification | Missing or conflicting inputs can prevent a conclusion |
Keeping all candidate passages increases token cost and creates more opportunities for mismatched clauses. Reducing context after authorization should preserve the exact supporting passage and its locator, rather than retaining only an unattributed summary.
Architecture / decision scenario
A commercial-insurance employee assistant explains a client’s deductible using policy-system rows and contract PDFs. It serves 12 broker teams. A response must finish in six seconds, and brokers may access only their assigned clients. A retrieved standard contract says a deductible is USD 5,000; the client’s effective endorsement says USD 2,000. These are scenario values.
A proposed shortcut searches all broker collections, chooses the highest-scoring passage, and hides unrelated citations afterward. The service owner rejects it: unauthorized passages would already have entered synthesis, and the highest relevance score cannot select the governing endorsement.
The authorization adapter selects the broker’s permitted collection and submits an explicit client scope in filter_expr, with generated filtering disabled. The database tool independently applies the caller’s client scope. Neither path’s successful result authorizes data from the other path.
The source records join the policy row and endorsement by policy identifier and effective date. The claim ledger attributes the USD 2,000 deductible to that endorsement and the coverage state to the database result. If the broker lacks access to the endorsement, the assistant does not infer its contents from the standard form. The underwriting owner resolves the interpretation; the platform owner repairs schema failures; the identity owner repairs incorrect assignments.
Common exam traps
- Applying authorization only after the model has read the retrieved context.
- Treating LLM-generated filters as mandatory permission enforcement.
- Confusing filter-schema validity with trustworthy access metadata.
- Using a relevance score to decide which contract governs a transaction.
- Citing a document that mentions the subject but does not support the claim.
- Joining sources by display name while ignoring entity IDs and effective dates.
What to remember
Authorize both retrieval paths independently, preserve source identity through synthesis, and connect each claim to the inputs that support it. Use Blueprint filtering as a retrieval mechanism inside a trusted access path. Resolve source applicability before generation; return a partial or unresolved answer when the authorized inputs cannot support the full conclusion.
Knowledge check
A broker assistant searches every broker’s document collection, passes the top passages to the model, and then removes citations to clients the broker is not assigned to before displaying the answer. Which change closes the access gap?
filter_expr . Fewer passages or a better ranking change relevance, not who may read what.A fusion stage combines policy-database rows and contract passages about one client into a single answer. Which evidence should it require before either result enters the combined context?
document_name citation attached to each passageFor a protected contract collection, an authorization adapter derives the caller’s client scope from identity. The team wants natural-language filtering while preserving that mandatory scope. Which configuration follows this Bite’s protected retrieval path?
filter_expr with filter generation enabledfilter_expr with filter generation disabledfilter_expr , and generation failures can leave retrieval unfiltered. The protected path therefore supplies the identity-derived filter with generation disabled; neither passing an existing filter to the generator nor relying on the broker’s wording preserves mandatory permission enforcement.A broker asks for client K’s deductible. Retrieval returns a standard contract stating USD 10,000 with a relevance score of 0.91, and K’s endorsement, in effect today, stating USD 4,000 with a score of 0.74. K’s policy row references that endorsement, and the underwriting owner ranks an effective endorsement above the standard contract. Which input should decide the deductible the assistant reports?
score as relevance: it says the standard contract matches the question well, not that it governs K’s policy. Applicability comes from joining on a stable policy identifier and an effective date, then applying the owner’s authority classification, which puts the endorsement first. Ingestion order says nothing about authority, and weighing both passages in synthesis leaves to the model a precedence the owner has already defined.A sales assistant explains why an order received its price. The order rows are authorized for the user, but the customer’s negotiated pricing agreement sits in a collection the user may not read. The public price list is available to everyone. How should the assistant answer?