NVIDIANVIDIA-Certified Professional: Agentic AI2026-1010.3 Implement transparency mechanisms (explainable reasoning, decision traceability).
Preserve observed decisions for later audit
Completed by the knowledge check
Learning objective
Record faithful decision traces for audit, distinct from post-hoc explanations.
Core idea
A faithful decision trace preserves what the running system observed and did: the inputs available to a decision, the component that selected an action, the action attempted, and the resulting outcome. A model asked afterward to explain its behavior produces another interpretation. That interpretation can help a reader, but it cannot fill a missing execution record.
Faithfulness here means correspondence with observable execution, not access to every internal model computation. Keep generated explanations identifiable as generated artifacts. See 10.3.1 for user-facing explanations, 8.2.1 for distributed correlation, and 9.1.3 for audit-record integrity. This lesson decides what a reviewer can establish from the collected record and where that record stops.
How it works
Define the decision record before collection
Give each consequential decision an application-owned record that joins the workflow run and decision sequence to the selected action, component revision, applicable policy revision, supporting source references, and observed result. Name whether an entry describes a proposal, an attempt, or confirmed completion. These are application schema requirements, not reserved NeMo fields.
Preserve the information available at the time. A reference to a policy document that can change tomorrow is insufficient to identify which rule informed yesterday’s decision. Keep the version or a controlled snapshot reference with the decision. Distinguish the original tool result from a later interpretation of it.
NIST’s AI RMF connects documentation, transparency, and accountability. Collect what supports review of the decision and expose coverage limits, such as an uninstrumented service.
Collect execution events at their source
NeMo Agent Toolkit’s IntermediateStepManager publishes IntermediateStep workflow events, including function boundaries, LLM calls, tool usage, and intermediate operations. Exporters process those events asynchronously. To send spans to an OpenTelemetry collector, the documented configuration uses general.telemetry.tracing, an exporter with _type: otelcollector, and its endpoint; this integration requires nvidia-nat[opentelemetry] (see 4.3.3).
Write the decision record on the action’s own path, as part of committing the action; see 9.1.3 for durable collection and integrity. The observability page documents asynchronous background export, not a delivery guarantee. Treat Toolkit spans as enrichment whose arrival does not establish that the action and its decision record were committed together. Instrument the business selection and result, including the authorizing policy revision.
Guardrails adds another source of observed decisions. Its generation option log.activated_rails returns activated-rail details, while log.llm_calls returns LLM-call information including prompts, completions, tokens, and timing. Both work on LLMRails and IORails. internal_events and colang_history are Colang-specific: requesting them on IORails raises NotImplementedError.
On IORails, inspect log.activated_rails for stop: True to find the rail that stopped processing. The action’s return_value["failed"] distinguishes a rail failure from a policy block. Preserve that distinction in the application outcome: a detector failing to run is not the same decision as a detector successfully rejecting a request.
Separate span construction from explanation generation
Guardrails tracing is configured through tracing.enabled in config.yml. The documented LLMRails adapters include FileSystem with filepath for local JSON trace output and OpenTelemetry for an observability backend. OpenTelemetry requires the nemoguardrails[tracing] extra and application-level SDK configuration. The extra alone does not configure a destination.
The LLMRails tracing path constructs spans afterward from its recorded interaction log. This extracts recorded data rather than generating a retrospective narrative. Judge provenance by the underlying records, not when the span object was created.
IORails uses inline spans and is documented as an early-release engine whose span names and attributes can change. Guardrails(config, use_iorails=True) opts in; NEMO_GUARDRAILS_IORAILS_ENGINE=1 aliases the top-level LLMRails import to Guardrails. Passing an llm or using unsupported flows can cause fallback to LLMRails, changing the records the audit pipeline receives. Construct Guardrails(config, use_iorails=True, require_iorails=True) to raise ValueError for an incompatible configuration instead of silently accepting that engine change. Test the received format as part of qualification.
Make content and gaps explicit
Guardrails traces omit prompt and response content by default. tracing.enable_content_capture controls capture on both engines. On IORails, OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT overrides that flag: true or 1 forces capture on, and false or 0 forces it off. The environment variable is not consulted on the LLMRails path.
Metadata identifies operations without necessarily preserving the text needed for factual reassessment. When reviewers need the exact source passage or tool result, retain an authorized reference to that artifact in the decision record. Enabling all prompt capture can expose sensitive content without supplying a durable business record. See 9.2.2 for retention ownership.
Verify collection by comparing a controlled test run’s expected decisions with the received records. Guardrails warns that enabling capture without configuring a TracerProvider silently discards spans through a no-op tracer. Repair the SDK setup and rerun the test. For interruptions, test the engine’s actual behavior: IORails’ request span captures delivered text even after early exit, while its CLIENT span omits partial model output when the consumer cancels or the provider fails. An absent output field therefore needs interpretation alongside the terminal outcome.
Key distinctions and trade-offs
Choose what each artifact is allowed to establish:
| Artifact | Valid use | Limitation |
|---|---|---|
| Runtime event or rail log | Establish an observed operation or rail outcome | Coverage depends on instrumentation and successful collection |
| Span extracted from an interaction log | Reconstruct the recorded operation structure | Cannot recover events missing from the underlying log |
| Generated post-hoc explanation | Communicate an interpretation of recorded facts | Cannot serve as independent proof of the executed path |
| Captured prompt or completion | Inspect exact recorded content | Adds sensitive data and storage obligations; is not proof of tool success |
The audit owner defines the review questions; the platform owner verifies collection coverage. Content capture trades review detail against storage exposure, while metadata alone can prevent substantive reassessment.
Architecture / decision scenario
An energy company’s billing analytics agent proposes 20,000 tariff corrections daily. The audit team needs reviewable decisions for 90 days, while the platform allocates 100 GB for audit and diagnostic records. The team measures 200 kB per trace with enable_content_capture: true: retaining every full-content trace would consume 360 GB over that window, before indexing overhead. These are scenario measurements and decimal storage units, not NVIDIA limits.
A developer proposes full-content tracing as the audit record because it preserves the exact prompts and answers. The audit owner instead selects metadata-only tracing plus dedicated decision records containing policy and dataset revisions, the selected correction, and authorized references to source passages and tool results. In the trial, the combined records take 10 kB per decision, or 18 GB over 90 days. The referenced artifacts remain in their authorized stores under the retention ownership in 9.2.2. This fits the budget and ties the decision to the action’s commit path; a generated explanation cannot substitute for either.
During qualification, a blocked test request produces no spans because the host omitted its TracerProvider. The platform team repairs the setup and confirms that the received record identifies the stopping rail. A second test cancels a stream: reviewers see the interrupted outcome and understand why the IORails CLIENT span lacks partial output. A generated explanation may summarize either case, but missing records remain declared gaps. The analytics owner cannot promote “correction proposed” to “billing updated” without a confirmed tool result.
Common exam traps
- Treating a fluent retrospective explanation as a missing runtime record.
- Rejecting log-derived spans merely because span construction happens after execution.
- Treating full prompt capture as a durable decision record committed with the action.
- Accepting silent engine fallback when the audit parser expects IORails records.
- Confusing a rail failure with a successful policy block.
- Assuming content capture configures an OpenTelemetry SDK or behaves identically on both engines.
Where the exam guide differs
The study guide lists “NVIDIA Agent Intelligence Toolkit” among its suggested readings. The documented product is NeMo Agent Toolkit; its observability mechanism uses IntermediateStepManager and general.telemetry.tracing. Read the guide’s toolkit name as the predecessor name, while using the documented identifiers to choose an implementation. Guardrails separately documents IORails as early-release and distinguishes its inline spans from LLMRails log-derived spans; decision traceability does not imply identical records across engines.
What to remember
Preserve observed selection, action, and outcome with the revisions and sources that give them meaning. Trace events, log-derived spans, and generated explanations have different provenance. Verify that the collection path actually delivers records, and make missing content or coverage explicit rather than reconstructing it with model prose.
Knowledge check
A billing agent built on NeMo Agent Toolkit exports spans to an OpenTelemetry collector through an otelcollector exporter. An auditor finds a committed account correction with no matching span from a period when the collector was briefly unavailable. Every committed correction must have a reviewable decision record. Which change meets that requirement?
An audit parser expects the inline spans of NeMo Guardrails’ IORails engine. The service constructs Guardrails(config, use_iorails=True) and also passes an llm, and the received records turn out to have a different format. The service must refuse to start rather than run on a different engine. What should the team change?
require_iorails=True beside use_iorails=TrueNEMO_GUARDRAILS_IORAILS_ENGINE=1 in the deployment’s environmenttracing.enable_content_capture: true so spans carry message contentuse_iorails=False to pin the trace formatllm is one of the conditions under which the Guardrails facade falls back to LLMRails , and by default it only logs the reason. require_iorails=True raises ValueError instead of falling back. The environment variable is another way to opt in to IORails, not a refusal of fallback, and use_iorails=False selects LLMRails outright.During qualification, a NeMo Guardrails service has tracing.enabled set, the OpenTelemetry adapter selected, the nemoguardrails[tracing] extra installed, and content capture on. A blocked test request produces no spans at the collector, and nothing is logged as an error. Inspection finds that the host never configured the OpenTelemetry SDK. Which fix addresses this omission?
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true in the environmentLLMRails , whose spans are built afterward from the interaction lognemoguardrails[tracing] extra to register a span exporterTracerProvider in the application before constructing GuardrailsTracerProvider , the API returns a no-op tracer that silently discards every span and its captured content, on either engine. The extra supplies the integration but no destination, and the environment variable only decides whether content is captured on spans that are still discarded.A service runs NeMo Guardrails on the IORails engine. A content-safety input rail stops some requests; in a few of them the safety model’s endpoint was unreachable. The audit record must distinguish “detector failed to run” from “request violated policy”. What should the application read?
internal_events log, which lists the events each rail generatedactivated_rails entry and its action’s return_value["failed"]output_vars: True on the calllog.activated_rails entry with stop: True identifies the rail that stopped processing, and the action’s return_value["failed"] distinguishes a rail failure from a policy block. internal_events raises NotImplementedError and output_vars raises ValueError on IORails. A refusal alone does not establish whether the detector ran successfully; the structured action result supplies that distinction.A logistics agent proposes 5,000 rate changes a day, and auditors must be able to reassess each decision against its exact source passage for 180 days. Source artifacts are retained separately in an authorized store for the full review window; the trace and decision-record budget is 50 GB. In a trial, a full-content trace takes 100 kB, while a metadata-only trace plus a decision record takes 8 kB. These are scenario figures. Which record design fits?
References
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- NVIDIA, Observe Workflows
- NVIDIA, Logging and Debugging Guardrails Generated Responses
- NVIDIA, Tracing Configuration for the NVIDIA NeMo Guardrails Library
- NVIDIA, Capturing Prompt and Response Content
- NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide