Source Triangulation

A single source can confirm a hallucination rather than debunk it — making hallucination detection harder. If an AI model fabricates a plausible-sounding claim — say, a software library feature that does not actually exist — and you verify it against a source that the model also drew from during training, you may find superficial confirmation. The model's training data and your verification source can share the same knowledge base, so errors in one appear consistent with the other.

Triangulation breaks this circularity by requiring sources of fundamentally different types. Official documentation, community forums, academic papers, and working code examples represent different knowledge creation processes with different incentive structures and quality controls. A fabricated API feature might appear in a model's training data, but it will be absent from the official documentation, unmentioned on developer forums, and missing from working codebases. The absence across multiple independent source types is the signal that catches what single-source checking misses.

The principle applies beyond technical claims. Business statistics, historical facts, attributed quotes, and research findings are all categories where AI models can generate plausible fabrications that pass superficial verification. Each domain has its own set of independent source types that serve the same triangulation function.

Define three or more source categories appropriate to the domain. For technical claims: official documentation, community discussions (Stack Overflow, GitHub issues, Reddit), and working implementations (open-source repositories, tutorials with runnable code). For business claims: industry reports, news coverage, and company filings or official announcements. For scientific claims: peer-reviewed papers, institutional databases, and expert commentary or reviews.

Apply claim decomposition and check each claim against at least two source categories. Full triangulation across all categories is ideal for high-stakes decisions but impractical for routine verification. A practical approach is to always check the most authoritative source type first (official documentation for technical claims, primary research for scientific claims) and escalate to full triangulation when the first check raises any doubt or when the decision's consequences are significant.

Pay attention to the character of the evidence, not just its presence. 'Multiple blog posts mention this feature' is weaker confirmation than 'the official changelog for version 3.2 documents this feature,' even though both are technically confirmations from external sources. Source authority matters as much as source count.

Combining triangulation with the structured verification habits described in /aisapedia/verification-checklists creates a robust workflow for high-stakes AI-assisted decisions. The checklist ensures you do not skip verification steps; triangulation ensures the verification itself is meaningful.

When sources disagree, the pattern of disagreement is itself diagnostic. If official documentation says a feature exists but community discussions show no one has successfully used it, the feature may be documented but broken, deprecated, or behind an unadvertised feature flag. If community discussions reference a technique but documentation is silent, the technique may be an unofficial workaround that could break in future versions without notice.

Complete absence across all source types is the strongest hallucination signal. When a claim cannot be confirmed by any independent source — no documentation, no community mention, no working example, no academic reference — the claim should be treated as fabricated until proven otherwise. This is especially important for technical decisions where acting on a hallucinated capability could waste significant development time and budget.

Partial confirmation with inconsistencies is more nuanced. If two out of three source types confirm a claim but the third contradicts it, the contradiction deserves investigation rather than dismissal. The contradicting source may be outdated, or it may be revealing a limitation or caveat that the confirming sources omit. The goal of triangulation is not simple majority voting but understanding the full picture that multiple perspectives reveal.

For low-stakes tasks — brainstorming, creative exploration, internal rough drafts, personal learning — full triangulation adds friction without proportional value. The cost of being wrong on a brainstorming list is negligible. Reserve systematic triangulation for decisions that are expensive to reverse: technology selections, public-facing claims, contract terms, published content, and any AI output that will be cited or relied upon by others.

A useful heuristic: if the AI output will leave your screen — where citation verification matters — (sent to a client, published externally, used as input to a downstream system, or cited in a decision document), it warrants triangulation. If it stays on your screen as a personal thinking aid or exploratory draft, quick sanity checks against a single authoritative source are sufficient.

This risk-based approach matches the effort of verification to the consequences of error. It aligns with the broader principle described in /aisapedia/stakes-based-review — the higher the stakes of the decision, the more rigorous the verification process should be, and vice versa.

AI tools with built-in web search capabilities — such as Perplexity — can accelerate the first pass of triangulation. Querying a search-enabled model with 'Find official documentation, community discussion, and working code examples that confirm or deny this claim' produces an initial source check that covers multiple categories in a single query. This initial pass identifies which claims are well-supported and which warrant deeper manual verification.

For technical domains, maintaining bookmarks to authoritative sources — official documentation sites, API changelogs, specification repositories — reduces the friction of manual verification. When a claim needs checking, navigating directly to the authoritative source for that domain is faster than a general web search. Over time, practitioners develop a mental map of where to look for each type of claim, making triangulation increasingly efficient.

Team-level triangulation practices scale the effort across multiple people. When one team member verifies a claim and documents the sources, that verification is available to the entire team. A shared log of verified claims — with source links and verification dates — prevents duplicated verification effort and builds an organisational knowledge base of confirmed facts that anyone can reference without repeating the triangulation process.