Design Citation and Source-Transparency Anatomy

Workflow area: Trust & Failure States · Tier: Core · Hands-on time: ~35 minutes

A citation in an AI answer is doing serious work: it claims this statement came from that source. Users calibrate their trust on it, mostly without clicking. That makes citation design a failure-state design problem wearing a typography costume — because citations fail in ways a footnote never had to handle: the link dies, the source doesn't actually say what the answer claims (misattribution), the source is real but weak, or the model cites confidently while paraphrasing loosely. Shape of AI classes citation patterns among its Trust Builders for a reason: this anatomy, more than any other single surface, decides whether users can practice appropriate reliance on your feature or just vibes.

When to use — and when not to

• Use it when your AI feature makes checkable claimsRAG answers, research assistants, summarizers over documents: anything asserting facts a source could confirm needs this anatomy before launch.
• Use it when stakes vary across answersthe same product answering "office wifi password" and "contract termination terms" needs verification affordances that scale with consequence.
• Use it to retrofit a feature whose citations are decorativenumbered links nobody can preview, sources listed but not sentence-linked: users have learned they're wallpaper, and this pass makes them functional.
• Skip it for generative work with no truth claimbrainstorming, copy drafts and image generation assert nothing checkable; provenance there is a disclosure problem (pb-52), not citation anatomy.
• Skip inventing confidence percentagesif your retrieval pipeline can't genuinely distinguish source quality, don't design UI that pretends it can; signal only what the system knows.

The recipe

1. 1.

   Inventory what your pipeline actually knows. Sit with engineering and list the per-claim metadata that truly exists: source URL and title, retrieval timestamp, document date, passage-level match (or only document-level?), source type (your docs vs. open web), anything approximating retrieval confidence. Every UI element you design must map to real metadata — citation UI that outruns the pipeline is fabricated trust, the exact disease it's meant to cure.

2. 2.

   Design the inline reference layer. Decide claim-to-source binding: sentence-level markers give precision but crowd dense answers; paragraph-level reads cleaner but weakens the "which claim?" link. Design marker anatomy (numbered chips, favicon chips, superscripts), density rules (max markers per paragraph before consolidation), and — critically — what an uncited sentence means in your product: visibly unmarked as model synthesis, not ambiguously naked.

3. 3.

   Design the hover/tap preview. The preview is where trust calibration actually happens — most users verify here or nowhere. Show: source title and favicon, the verbatim passage the claim rests on (highlighted within a snippet), document date and retrieval date, and the jump-to-source action. The verbatim passage is non-negotiable when the pipeline supports it; paraphrase-in-preview quietly re-introduces the misattribution risk the preview exists to catch.

4. 4.

   Signal source quality without editorializing. Distinguish classes the system genuinely knows: your organization's verified docs vs. open web, primary vs. aggregator, fresh vs. stale (show the date and let users judge). Prefer factual badges ("Internal KB · updated Mar 2026") over invented scores ("93% reliable"). Sample spec fragment for engineering:

   Copy

   CITATION CHIP — states & anatomy
   default: [favicon] [n] — tap/hover opens preview card
   preview: title · source-class badge · doc date · retrieved date ·
            verbatim passage (claim-matching span highlighted) ·
            "Open source" action
   stale:   doc date > 12mo → date badge amber; copy: "May be outdated"
   dead:    target 404s on open → chip turns hollow; copy: "Source
            unavailable — retrieved [date]"; answer text UNCHANGED,
            claim marked "unverifiable", never silently deleted
   mismatch (user reports or recheck fails): chip red-outline; copy:
            "Source may not support this claim" + report action
   

5. 5.

   Design the failure states — this is the heart of the playbook. Three mandatory ones. Dead link: the claim doesn't vanish; it degrades honestly to "unverifiable, retrieved on [date]." Misattribution: a user opens the source and can't find support — give them a one-tap "source doesn't say this" report, and design what the answer does when reports accumulate. No citation available: the model wants to assert something retrieval didn't ground; decide product policy — suppress the claim, or show it explicitly marked as ungrounded synthesis. Write each as a state with copy, using your pb-28 rubric.

6. 6.

   Scale verification affordances with stakes. Define your high-stakes claim classes (medical, legal, financial, irreversible actions) and give them heavier anatomy: expanded-by-default source passage, "verify before acting" microcopy, perhaps a second-source indicator. Low-stakes claims keep lightweight chips. One anatomy, two intensities — stakes-blind citation design over-frictions the trivial and under-protects the consequential.

7. 7.

   Test whether calibration actually happens. Prototype with realistic answers (pb-37 wiring helps) including one seeded misattribution and one dead link. In usability sessions, watch: do users notice the marks, use previews, catch the seeded flaws? A citation anatomy nobody interacts with is decoration — iterate density and preview affordance until the seeded misattribution gets caught by most participants.

Make it yours

• Shape of AI as pattern vocabulary: audit your design against its Trust Builders — citations, provenance, footprints — and borrow interaction patterns from documented products rather than reinventing chip anatomy from zero.
• Claude for the adversarial pass: paste your citation spec and ask for the ways it fails — "list scenarios where this anatomy misleads a user about source support" — then design against the credible attacks (log accept/reject, pb-19 style).
• Design tokens for trust states: encode the citation states (verified, stale, unavailable, disputed) as semantic tokens in your system so every AI surface in the product renders source status identically — trust anatomy is a design-system citizen, not a per-feature invention.

Quality check

• Every UI element maps to real pipeline metadataengineering confirmed each badge, date and passage is available per-claim; nothing displayed is inferred by the UI layer.
• Previews show verbatim passagesnot paraphrases; the preview's job is letting users catch misattribution, so it must quote.
• All three failure states are designed with copydead link, misattribution, uncited claim; each degrades honestly instead of vanishing or bluffing.
• Uncited synthesis is visibly distincta reader can always tell grounded claims from model inference at a glance.
• Stakes tiers exist and differ visiblyhigh-consequence claims carry heavier verification affordances than trivia; you can point to the rule that decides the tier.