AWSAWS Certified Generative AI Developer - Professional2026-103.4 Implement responsible AI principles
Explain answers through evidence and boundaries
Completed by the knowledge check
Learning objective
Present evidence-backed explanations and source attribution without exposing private model reasoning.
Core idea
An explanation lets a reader check what supports an answer and understand its limits. It does not need to reveal the model’s internal reasoning. For an architect, the decision is what evidence your application releases, to whom, and under which checks.
Build a public explanation from approved facts, source attribution, applicable business rules, and known limitations. Treat model reasoning as a separate kind of output. A convincing narrative about how the model reached its answer is not evidence that the answer is correct. Conversely, a short explanation with a verifiable source and a clear limitation can be useful without any reasoning transcript.
Separate the answer, its evidence, and operational diagnostics in your response contract. That separation gives you a reviewable boundary: the public response contains only fields deliberately approved for the reader.
How it works
Map claims to source evidence
Amazon Bedrock’s Citation structure associates a generatedResponsePart with retrievedReferences. AWS documents this structure for the citations fields in RetrieveAndGenerate and InvokeAgent responses. A RetrievedReference carries content, location, and metadata. Use those fields to construct attribution rather than asking a model to invent document titles or URLs.
A source reference supports inspection, but its presence does not establish that every nearby claim follows from the source. Check the cited passage against the consequential claim before publishing its explanation. Lesson 3.1.6 covers evidence verification; the concern here is how you present that verified relationship. Preserve the distinction between a statement supported by the passage and an application decision made under an approved rule.
For example, a passage can establish the filing deadline. Your explanation can then state that the submitted date is after that deadline. The source does not prove unrelated eligibility requirements, and the explanation must not imply that it does. If the answer combines multiple sources, attribute each supported part and state when a required source is missing or contradictory.
Project a public evidence contract
Do not forward retrievedReferences unchanged to a browser. A storage location or metadata field can reveal information the caller is not entitled to receive. Select public document labels, authorized access paths, and the minimum supporting excerpt. Permission-filtered retrieval belongs to 1.4.6; permissions on the explanation itself still matter after retrieval succeeds.
Keep an internal source identifier and revision in your evidence record so that reviewers can reconstruct what the reader saw. The public label can be more limited than the internal record. Source-lineage design belongs to 3.3.3. Here, the architectural requirement is that an abbreviated public explanation remains connected to the retained evidence rather than becoming an untraceable paraphrase.
If a public source is unavailable, say what could not be checked. Do not replace the missing source with a more elaborate model narrative. Give the reader an actionable next step, such as requesting an authorized policy document or escalating a disputed decision for review.
Keep reasoning out of the explanation
The Bedrock ReasoningContentBlock API type distinguishes reasoningText from redactedContent. The latter contains reasoning encrypted by the model provider for safety reasons. These are reasoning content types, not source-attribution fields. Their existence in an API schema does not make them a public explanation contract or promise that every model returns them.
Use an allowlist of response fields. Publish the final answer and approved evidence projection; exclude reasoning blocks, raw model outputs used for debugging, and agent trace rationale. Do not try to decode provider-redacted reasoning or ask a second model to reconstruct hidden reasoning. That would manufacture a story without giving the reader independent evidence.
Bedrock agent traces also contain sensitive diagnostic material, including rationale and model invocation data. Lesson 3.4.2 covers selecting execution events from those traces. A trace-derived statement such as “the system queried the approved policy source” can explain an observable action. It does not require publication of the model’s private rationale for choosing that action.
Key distinctions and trade-offs
Explanation versus reasoning: An explanation states the evidence and rules supporting the released outcome. A reasoning transcript describes intermediate model processing. Only the former is your public accountability contract.
Attribution versus correctness: A citation identifies a source relationship. Verification determines whether the passage supports the claim. Attractive citation formatting cannot repair an unsupported conclusion.
Transparency versus disclosure: Readers need enough information to assess the result, but source paths, sensitive excerpts, and diagnostic text can exceed their permissions. More exposed text does not automatically mean a more trustworthy explanation.
A concise explanation is cheaper to review and less likely to disclose unrelated content. Too little detail, however, can prevent a reader from identifying the wrong policy version or challenging a material error. Choose the level of explanation according to the decision’s consequences and the reader’s access, then validate that contract with representative examples.
Architecture / decision scenario
A benefits assistant answers whether an expense is covered. RetrieveAndGenerate returns an answer with citations, but one retrieved passage describes a different plan year. A separate cited passage for the current plan year establishes the filing rule, but not coverage eligibility. The model also produces a plausible account of how it interpreted the policy.
The application rejects the unsupported coverage conclusion. It presents the verified filing rule with its approved source label and states that coverage cannot be established from the available plan-year evidence. It offers human review instead of exposing the reasoning narrative as justification.
For an authorized reviewer, the retained record includes the original reference location, metadata, and the rejected claim. The public response excludes storage paths and diagnostic reasoning. If later evidence resolves coverage, the application issues a new supported explanation rather than silently editing the meaning of the earlier evidence record.
Common exam traps
- Treating a model’s explanation of its reasoning as proof of correctness.
- Assuming a citation validates every sentence in the answer.
- Forwarding reference metadata or source locations without a disclosure decision.
- Treating provider-redacted reasoning as content the application should recover.
- Publishing raw agent traces to satisfy a transparency requirement.
- Omitting uncertainty because the answer has a well-formatted source list.
What to remember
- Explain released outcomes with verified evidence, approved rules, and limitations.
- Use
Citation.generatedResponsePartandretrievedReferencesfor attribution. - Project reference content, location, and metadata into an authorized public contract.
- Keep reasoning content and trace rationale separate from public explanations.
- Preserve enough internal evidence to review a challenged answer.
Knowledge check
A benefits assistant concludes that an expense is covered. The only cited passage for the current plan year establishes the filing deadline, not coverage eligibility, and the model adds a persuasive account of how it interpreted the policy. What should the public explanation contain?
A RetrievedReference returned with an answer contains metadata that includes an internal storage path the caller is not entitled to see. Reviewers must still be able to reconstruct what the caller was shown. What should the application do?
A model response includes a ReasoningContentBlock with redactedContent beside its final answer. A product manager asks to show the model’s reasoning to make answers more transparent. What should the application publish?
redactedContent is encrypted by the provider for safety reasons. An allowlist publishes the answer and its verified evidence. A reconstructed or decoded narrative gives the reader a story, not independent evidence.