Coding platforms sell the path from idea to artifact. Source-linked answer products sell something quieter: the right to be believed. Anyone can generate fluent text; the product here is the evidence chain behind it. This lesson studies that chain through one public example — Perplexity — and turns it into a checklist you can apply to any research product, including Research Desk.

The visible mechanism

Perplexity presents itself as an answer engine, and its interface shows the mechanism plainly: you ask a question, it searches the live web in real time, and it returns a conversational answer with numbered inline citations linking to the sources it used. Follow-up questions keep context; harder questions escalate to Pro Search (multi-step agentic searching) or Deep Research (a longer run that reads many more sources and returns a structured, fully cited report). This description reflects the product's current public behavior and help documentation as of September 2026 — recheck https://www.perplexity.ai/ before quoting plan or feature details, which change.

Strip it to the pipeline a builder should study:

query → live search → retrieval + ranking → synthesis constrained by sources
  → cited answer → user inspection

The load-bearing step is the constraint: the model is supposed to assert only what it first retrieved, with each factual claim carrying a footnote to the page it came from. That single rule separates an answer engine from a text generator. It is also why the citations are the product, not decoration — they are the user's only path to verification.

This lesson uses Perplexity as a mechanism example, not an endorsement. What matters is the visible pattern — answers connected to sources, retrieval you can reason about, an interface for inspection — because Sonariq/Research Desk (Lesson 56.2) needs the same mechanics for a different user and corpus.

Answer quality is not evidence quality

Fluent, well-organized prose is answer quality. Whether a careful reader can verify each claim is evidence quality. The two fail independently, and confusing them is the signature error of this product category:

• A fluent answer with weak citations feels trustworthy and is not. The footnote may point to a page that says something slightly different, says it in another context, or does not clearly support the claim at all.
• A clunky answer with strong citations is more useful than it looks. The user can check the primary pages and reach the right conclusion despite the prose.
• An uncited crucial claim is a defect regardless of fluency. If the load-bearing sentence has no footnote, the chain is broken where it matters most.

Teach yourself to read citations adversarially. Open three footnotes on any substantive answer and ask: does this page actually state the claim? Is it primary enough (the filing, the paper, the official record) or is it a page quoting another page? Is anything load-bearing left uncited? That five-minute drill teaches more about trust design than any architecture diagram.

Provenance, freshness, permission, error: product decisions

Four choices determine whether citations deliver trust or theater. None of them is "pick a stronger model":

1. Provenance. Which sources are eligible, and does the user see why? Source selection — allowed domains, primary-over-secondary preference, quality thresholds in ranking — decides what the answer can ever claim. Show the source list, not just the footnotes, so selection itself is inspectable. 2. Freshness. Retrieved-now beats trained-then. Live search keeps answers current past any training cutoff, but only if retrieval actually ran for this question and the cited pages carry visible dates. A 2026 answer resting on a 2022 page without a date shown is a freshness bug with a trust cost. 3. Permission. What the system is allowed to fetch, quote, and show — robots directives, paywalled or licensed sources, premium datasets, the user's own uploaded files — is a policy decision with legal and ethical weight. "We cite it" never settles "we were entitled to reproduce it." 4. Error behavior. What happens when sources conflict, when nothing relevant is found, or when retrieval fails mid-run? Honest products say so: surface the disagreement instead of silently picking a side, label thin evidence as thin, and offer the no-answer ("no reliable source found") as a first-class outcome. A confident answer built on nothing is the worst failure this category has.

Each choice belongs in the spec, the interface, and the tests — not in the prompt alone.

Apply it to any research product

Carry the pattern back to Research Desk. Different corpus, same trust mechanics: every brief claim traces to an approved source; primary sources outrank commentary; each citation shows its date; conflicts between two filings are flagged rather than averaged; missing material is labeled missing. The Deep Research parallel is instructive too — a long, structured, fully cited report is exactly what a research brief aspires to be — but the mechanism transfers while the responsibility stays local: your source list, your freshness rules, your permission boundaries, your error states.

The general rule: if your product presents model-generated information as if it were found information, you owe the user the chain. No chain, no claim.

Exercise: inspect one answer, then write TRUST-FEATURES.md

First, take any source-linked answer (Perplexity or your own product) and interrogate three citations: support, primacy, coverage. Write down what passed and what failed.

Then produce TRUST-FEATURES.md for your product with this checklist:

# Trust Features — [Product name]

## Citation rules (when a claim needs a footnote, what counts as support)
## Source selection (allowed sources, primary preference, exclusions)
## Freshness (retrieval timing, date display, staleness flags)
## Permission (what may be fetched, quoted, shown; what may not)
## Uncertainty (how conflicts, gaps, and low-confidence claims display)
## Failure states (no sources found, retrieval error, stale provider)
## Verification path (what the user clicks to check each claim themselves)

Done means: a TRUST-FEATURES.md where every checklist item has a concrete rule, not an aspiration ("cite sources" is an aspiration; "every numerical claim carries a footnote to the page containing that number, with retrieval date shown" is a rule). Verify: pick one claim in your product's output and walk the verification path yourself — source opens, claim matches, date visible — in under a minute. Common failure: a checklist that describes the model ("uses advanced RAG") instead of the user's inspection path. Trust is what the user can check, not what the system claims about itself.

Check your understanding

• Why can a fluent, well-formatted answer still fail on evidence quality?
• For each of provenance, freshness, permission, and error handling: what does the user see when it is done well?
• What should the product do when two trusted sources disagree?

Sources and unknowns

• Answer-engine behavior (real-time search, inline numbered citations, Pro Search, Deep Research structured reports): Perplexity public product and help center (L1/L2, verified September 2026 via https://www.perplexity.ai/ and its help documentation; plan names, prices such as Pro tier, and feature availability change — recheck live).
• Retrieval-and-ranking internals beyond public descriptions (index composition, ranking weights, model routing): undisclosed — described here only at the visible-mechanism level; no invented internals.
• Unknowns (explicit): exact source pool and ranking signals per query; citation-support accuracy rates; premium-source coverage; current pricing and limits — recheck live before quoting.

In the final lesson of this class you stop analyzing other people's products and synthesize your own: the one-page application blueprint.