NVIDIANVIDIA-Certified Professional: Agentic AI2026-1010.3 Implement transparency mechanisms (explainable reasoning, decision traceability).
Explain actions with checkable supporting sources
Completed by the knowledge check
Learning objective
Explain actions and cite evidence without exposing raw chain-of-thought.
Core idea
An action explanation should help someone check what happened, which information supports it, and what remains uncertain. Give the outcome, the applicable constraint, and the supporting source. A long account of a model’s internal reasoning is a different artifact: it can contain sensitive information and does not establish that a tool executed successfully.
NIST’s AI Risk Management Framework distinguishes transparency about what happened from explanations of the system’s mechanisms and interpretation of an output in context. Tailor the explanation to the recipient’s task. An employee needs to understand a reimbursement recommendation; an operator investigating the same interaction needs execution records. See 10.3.2 for those records.
How it works
Assemble the explanation from observable results
Start with a small application-owned explanation record: the requested action, its observed status, the constraint applied, supporting document identifiers, and any missing information. These are proposed application fields, not a vendor response schema. Populate the action status from the tool result, rather than taking the status from the answer model’s text.
For example, distinguish “I found a policy that permits reimbursement” from “Your reimbursement was submitted.” The former needs a supporting policy passage; the latter also needs the submission tool’s confirmed result. If the tool times out without confirmation, explain the uncertain outcome. A retrieved policy cannot establish that a transaction completed.
Use a template for stable status and policy statements. If an LLM writes the surrounding prose, give it the approved record and source passages, then check its claims against that record before release. An unsupported statement becomes a narrower answer or an explicit limitation. This makes explanation quality a check of correspondence, rather than a contest over which answer sounds most persuasive.
The action status comes from the tool result, and generated prose is checked against the approved record before release.
Preserve source identifiers through the answer
NVIDIA RAG Blueprint exposes ChainResponse.citations.results when citations are enabled through enable_citations; see 6.5.2 for source records and per-claim support. A source record’s score measures retrieval relevance, not the probability that an action is correct. Present the applicable passage alongside the observed action status, so the recipient can distinguish policy support from execution confirmation.
On LLMRails, configure the self check facts flow under rails.output.flows and define its self_check_facts prompt. The prompt receives {{ evidence }} from $relevant_chunks and {{ response }} for the answer. Set $check_facts = True before the bot message to trigger the check selectively. The self_check_facts action returns a score from 0.0 to 1.0; the documented flow refuses the response below 0.5. This adds an LLM call and depends on the check model following its prompt. The model-based alignscore check facts option also reads retrieved chunks; both flows are unsupported on IORails.
Keep tool-status correspondence application-owned: grounding against passages cannot confirm a tool’s result. When support is missing, omit the unsupported recommendation and explain the missing information or request the necessary document. When support exists but the source is inaccessible to the recipient, disclose that limitation rather than inventing a citation. The explanation should leave the recipient with a supported outcome and a clear next step.
Keep reasoning outside the response boundary
NeMo Guardrails documents reasoning inspection through bot_thinking. In the documented Colang 1.0 pattern, an output rail accesses $bot_thinking; a Python action can read context.get("bot_thinking"); a moderation prompt can use the bot_thinking template variable. Check for its presence because not all models provide reasoning traces. NVIDIA describes the examples as patterns to adapt, rather than production-ready implementations.
Inspection is an internal moderation capability. Keep bot_thinking outside the application’s public response projection, and expose only the approved explanation and citations. The Agent Toolkit’s /v1/workflow/stream and /v1/chat/stream expose intermediate work through intermediate_data: events; /v1/workflow/full returns raw IntermediateStep objects, including LLM_END payloads. All intermediate steps stream by default on the full route; filter_steps=none suppresses them. Because filter_steps is caller-controlled, a public front end must enforce the approved projection on the server or a proxy and prevent direct access to unfiltered routes. Hiding a panel after text arrives does not undo disclosure.
Debugging interfaces need a separate boundary too. Guardrails options.log.llm_calls can return prompts and completions, and output_vars: True returns the complete Colang context on LLMRails. Do not serialize these objects into the public answer. explain() is an LLMRails debugging summary, not a ready-made customer explanation; it raises NotImplementedError on IORails. See 9.2.1 for PII controls on each exposure surface.
Key distinctions and trade-offs
Choose the artifact according to the recipient’s question:
| Artifact | Deciding condition | Mechanism | Cost or limitation |
|---|---|---|---|
| User explanation | Someone must understand a result or next step | Application-approved status and concise rationale | Requires checking the text against observed outcomes |
| Supporting citation | Someone must verify a factual or policy claim | ChainResponse.citations.results and source identifiers | Source access and claim support still need validation |
| Diagnostic detail | An operator must inspect generation behavior | Guardrails options.log or explain() on LLMRails | May contain prompts, completions, and internal context |
| Reasoning inspection | An internal rail must assess available reasoning | Colang 1.0 $bot_thinking | Model-dependent availability and sensitive content |
A template reduces generation work and makes status wording consistent, but cannot describe every unusual combination of facts. An LLM can summarize a complex record, at the cost of another generation and another claim-checking obligation. Choose the template where a small set of outcomes covers the task; use generated prose where the added interpretation serves a real reader need.
Architecture / decision scenario
A corporate travel assistant handles employee reimbursement questions. Its product target is a response within 3 seconds, and its privacy rule prohibits showing internal reasoning or another employee’s records. In a team trial, retrieval and the base answer take 1.9 seconds, a templated explanation adds 0.1 seconds, and a second model call for explanation adds 1.4 seconds. These are scenario measurements, not NVIDIA performance claims.
A developer proposes displaying the reasoning stream to explain why a hotel expense was rejected. The product owner instead selects a checked status template with policy citations: the policy passage states the nightly allowance, and the response identifies the submitted amount and the amount requiring review. The application takes the passage identifier and page from the RAG source records and verifies support before presenting it.
If the submission tool has not confirmed receipt, the assistant says the submission outcome is unconfirmed. It must not convert a valid expense recommendation into a claim that payment processing started. Available bot_thinking remains an internal rail input; it never enters the public projection. The template path takes 2.0 seconds; the second-call path takes 3.3 seconds and misses the target before any additional fact check. Complex exceptions therefore need a deferred response or a separately agreed budget. The product owner owns explanation coverage; the integration owner owns correspondence with tool outcomes.
Common exam traps
- Treating a plausible chain-of-thought transcript as proof that an action completed.
- Treating a citation list as an explanation of which action was taken or completed.
- Passing
output_vars: Trueto the client to explain an answer: it returns the complete Colang context onLLMRails, while IORails raisesValueErrorforoutput_vars. - Assuming
explain()works on both Guardrails engines or produces audience-ready prose. - Hiding reasoning visually after the stream has already delivered it.
Where the exam guide differs
The study guide uses “explainable reasoning” and lists “Chain-of-Thought (CoT) Prompting” among its suggested readings. Read that wording as a transparency objective, not a requirement to publish raw reasoning. NeMo Guardrails documents bot_thinking for internal inspection using Colang 1.0; a user explanation instead presents checked outcomes and supporting sources. On an exam item, distinguish a request to understand an action from a request to inspect model reasoning.
What to remember
Explain the confirmed outcome, the applicable constraint, and the cited support. Validate that the source supports the claim and that the tool result supports the status. Keep reasoning and debugging data behind an explicit response boundary, even when internal rails inspect them.
Knowledge check
An employee asks a travel assistant to submit a hotel expense. Retrieval returns a policy passage that permits the expense, and the call to the submission tool times out without returning a result. What should the assistant’s explanation state?
A public web application calls a NeMo Agent Toolkit server’s /v1/workflow/full route directly from customers’ browsers. A new requirement says customers must never receive intermediate steps such as LLM_END payloads. Which design meets the requirement?
filter_steps=none to every request it sends/v1/chat/stream route of the same server/v1/workflow/full all intermediate steps stream by default, and filter_steps is a parameter the caller controls, so a customer can simply omit it. The projection has to be enforced on a server or proxy, with direct access to unfiltered routes blocked. /v1/chat/stream also carries intermediate work as intermediate_data: events, and hiding a panel after text arrives does not undo the disclosure.A support application runs NeMo Guardrails on the IORails engine. Product asks for a short explanation, shown to customers, of why the assistant recommended a refund. Which source should that explanation be built from?
explain() summary of the last generation, returned with the answeroutput_vars: True in the optionslog.llm_calls in the optionsexplain() is an LLMRails summary that raises NotImplementedError on IORails, output_vars raises ValueError on IORails, and log.llm_calls returns prompts and completions that can contain sensitive internal content.An expense assistant must answer within 2.5 seconds, and its privacy rule prohibits showing internal reasoning. Retrieval and the base answer take 1.8 seconds in a team trial; a templated explanation adds 0.1 seconds and a second model call adds 1.2 seconds. Every rejection falls into one of four fixed reasons. Which explanation approach fits?
score measures retrieval relevance.References
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- NVIDIA, API - RAG Server Schema
- NVIDIA, Guardrailing Bot Reasoning Content
- NVIDIA, Logging and Debugging Guardrails Generated Responses
- NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide
- NVIDIA, NVIDIA NeMo Agent Toolkit API Server Endpoints
- NVIDIA, Hallucinations & Fact-Checking
- NVIDIA, Rail Engine Support