TrustGuide5 min

Add citations and evidence to AI-generated recommendations

How to make AI recommendations easier to trust, dispute, and improve inside operational software.

Real workflow example

An AI assistant says a customer is high churn risk. The account manager needs to know whether that comes from ticket sentiment, usage drop, billing issue, or missing onboarding.

Require every risk factor to include a source id, source type, and short evidence summary. The UI renders those sources beside the recommendation.

The account manager can trust, challenge, or correct the recommendation quickly.

Implementation approach

This guide is anchored in OpenAI structured outputs guide. Use the official API behavior as the boundary, then design the surrounding product state so the feature can be reviewed, retried, and improved.

Require each recommendation to include supporting evidence IDs or snippets.
Render evidence next to the recommendation, not behind a separate debug panel.
Flag unsupported recommendations and route them to manual review.
Let reviewers mark evidence as useful, wrong, stale, or insufficient.
Use those review labels to improve retrieval and prompt instructions.

Code or config snippet when useful

type citations_evidence_ai_recommendations_workflow_state = {
  sourceId: string;
  status: "draft" | "needs_review" | "approved" | "blocked";
  evidence: Array<{ source: string; summary: string }>;
  nextAction: string;
};

Field notes

Recommendations without evidence create review burden instead of reducing it.
Evidence should point to source records, document sections, or tool results.
The UI should separate facts from the model's recommendation.

Mistakes to avoid

Do not cite sources that were not actually retrieved.
Do not bury evidence in a debug drawer.
Do not mix evidence and model opinion in the same sentence.

Ready checklist

Evidence field required
Source links visible
Unsupported output blocked
Reviewer evidence feedback
Facts and judgments separated

Practical tip

Practical note

Evidence is part of the product UX. If users cannot see it, they cannot calibrate trust.

Use this as an implementation constraint, not just advice. The interface, server code, and validation path should make the same behavior true.

Apply this to a build