AI Limitations Hallucination

Overview

AI hallucination — the phenomenon where a language model generates plausible-sounding but factually incorrect or entirely fabricated content — is one of the most practically important limitations for product professionals to understand deeply. It is not a bug that will be patched away; it is a fundamental characteristic of how large language models work. Models generate text by predicting what tokens are statistically likely to follow previous tokens, drawing on patterns learned from training data. When the model encounters a question where the training data is sparse, ambiguous, or where the question itself is poorly formed, the model does not say "I don't know" — it generates the most statistically plausible continuation, which may have no factual grounding whatsoever.

For product managers, hallucination is not an abstract AI safety concern. It is a day-to-day professional risk. A PRD containing fabricated competitor metrics that gets presented to leadership. A market sizing estimate based on invented research figures that shapes a board discussion. An executive briefing with a quoted statistic that no published study ever contained. These scenarios are not hypothetical edge cases — they have happened in real organizations, with real consequences for the PMs involved. The professional who sent the document is accountable for its accuracy, regardless of which tool generated the first draft.

At the same time, hallucination risk is manageable. The key is not to avoid AI tools for research and analytical tasks — it is to develop a calibrated understanding of which types of AI outputs are high-risk, which are low-risk, and how to apply verification effort proportionally. A PM who verifies everything AI produces will be no more efficient than a PM who uses no AI at all. A PM who verifies nothing will eventually cause a significant professional incident. The middle path — targeted, systematic verification based on output type and stakes — is the professional standard that this topic builds toward.

This topic covers the mechanics of how hallucinations manifest specifically in product work, the practical verification techniques that fit into a real PM schedule, a calibrated framework for deciding when to trust versus verify, and how to build team-level skepticism norms that protect your entire function without creating bureaucratic paralysis.

How AI Hallucinations Manifest in Product Work

Hallucinations in product management contexts do not usually look like obvious nonsense. They look like plausible, well-formatted, confidently stated information that happens to be wrong. This makes them particularly dangerous, because the cognitive load required to identify a hallucination in a polished AI output is higher than the cognitive load required to identify an obvious error in a rough draft.

The most common hallucination patterns that affect PM work fall into six categories. Metric hallucinations are fabricated statistics presented as factual: market size figures ("The global customer experience software market is valued at $14.2B, growing at 18% CAGR"), adoption rates, conversion benchmarks, industry average metrics, or research study findings. The model has encountered thousands of market research reports in its training data, learned the pattern and format of market size statistics, and can generate convincing-looking figures on demand — even when no study with those specific numbers exists. Competitor hallucinations are invented or distorted facts about competitor products: features that do not exist, pricing that is outdated or fabricated, capabilities that are confused between vendors, and market share claims that are not grounded in any research. Research citation hallucinations — sometimes called "ghost citations" — involve AI generating plausible academic or industry research citations that reference papers that do not exist, authors who did not write the cited work, or real papers with fabricated findings attributed to them. Historical hallucinations involve incorrect dates, timelines, or event sequences — for example, incorrect information about when a feature was launched, when a company was founded, or when a regulation came into effect. Feature specification hallucinations can occur when AI is asked about technical capabilities: it may generate API specifications, SDK capabilities, or integration details that reflect a plausible pattern rather than the actual product's behavior. Regulatory and legal hallucinations are particularly high-risk: AI may cite regulations, standards, compliance requirements, or legal precedents that are misquoted, misattributed, or entirely fabricated.

Why do hallucinations happen? Understanding the mechanism helps you predict when they are most likely to occur. Three root causes are most relevant for PM work. Training data gaps: when a topic is underrepresented in the model's training data — a niche market, a specific regional regulation, a recent product launch, a specialized technical domain — the model has less signal to draw from and must rely more heavily on analogical pattern matching, which increases hallucination risk. Pattern completion bias: LLMs are fundamentally pattern-completion engines. When you ask a question that follows a recognizable pattern (e.g., "What is the market size of [X]?"), the model will produce a well-formatted, statistically-plausible-sounding answer even if no factual anchor exists, because that is what the trained pattern produces. Confidence miscalibration: most current LLMs do not have well-calibrated uncertainty — they do not reliably signal when they are uncertain. A model may express the same tone of confidence when generating a well-grounded fact and when generating a fabrication, which prevents the reader from using expressed confidence as a filter for verification.

The highest-risk prompt types in PM work are those that ask for specific numbers, specific dates, specific citations, or specific facts about competitors and markets. Conversely, the lowest-risk prompt types are those that ask for structure, synthesis of provided content, generation of options, or evaluation of options against a provided framework. When you provide the facts and ask AI to synthesize, structure, or evaluate them, you are using the model's genuine strengths. When you ask the model to recall or generate specific factual claims, you are in hallucination territory.

Hands-On Steps

1. Run a hallucination test on your current AI tool. Ask it three questions that require specific factual recall: a market size figure for a niche market relevant to your product, a specific fact about a competitor's feature set, and a citation to a research study about a topic in your domain. Then spend 15 minutes verifying each answer. Record how many are accurate, partially accurate, or fabricated. This exercise builds direct calibration with the tool you use most.
2. Review any AI-generated content that your team has produced in the past month (PRDs, research summaries, competitive analyses, market sizing documents). Identify any specific statistics, competitor facts, or research citations in those documents. Verify at least three of them against primary sources. Note any discrepancies.
3. Build a personal "hallucination risk flag" mental model. Before accepting any AI-generated factual claim, ask: "Is this a specific number, a specific date, a specific company fact, or a citation?" If yes, flag it for verification. If no — if it is a structural observation, a synthesis, or a generalization — proceed with lower verification priority.
4. Design a brief "hallucination exposure" exercise for your team. Select a realistic product work task (e.g., "summarize the competitive landscape for enterprise project management tools") and have each team member run it through AI without verification, then compare the AI outputs to each other and to one verified source. Discuss what diverged and why.
5. Create a personal log of hallucinations you encounter over the next month. For each one, note the prompt type, the hallucination category, and the verification method that caught it. After a month, review the log — you will likely identify a pattern in which types of prompts generate the most risk in your specific work context.

Prompt Examples

Prompt:

I need you to help me review an AI-generated market analysis for potential hallucinations before I share it with stakeholders. Please read the following excerpt and: (1) identify any specific statistics, market size figures, growth rates, or quantitative claims, (2) identify any specific citations to research studies, analyst reports, or industry data, (3) identify any specific claims about competitor products, features, or market share, (4) for each identified item, rate the hallucination risk as HIGH (specific figures, citations, competitor facts), MEDIUM (general trends, broadly documented patterns), or LOW (structural observations, widely known facts), and (5) recommend which items I should verify before sharing. Here is the excerpt: [PASTE CONTENT]

Expected output: A structured risk assessment of the AI-generated content, with each high-risk claim flagged and a prioritized verification list. Use this as a pre-publication checklist for any AI-assisted document that will be shared with stakeholders or used in decision-making.

Learning Tip: The most reliable hallucination signal is hyper-specificity. When an AI response includes very precise figures (not "roughly 15%" but "14.7%"), very specific citations (not "several studies have shown" but "a 2023 Gartner study found"), or very detailed competitor claims (not "Salesforce competes in this space" but "Salesforce's enterprise tier includes X, Y, and Z at $450/seat/month"), your verification alarm should trigger immediately. Precision is the hallucination tell — genuine knowledge tends to include appropriate hedging; confabulated knowledge often presents itself with false precision.

Verification Techniques — Cross-Referencing, Source Checking, and Confidence Calibration

Knowing that hallucinations exist is not enough — you need a practical verification system that fits inside a real working day. A product manager's schedule does not have room for treating every AI output as a research paper requiring full academic citation checking. What it does have room for is a tiered verification workflow where effort is proportional to stakes, and where the highest-risk claims get systematic verification while low-risk outputs proceed with minimal friction.

The verification hierarchy is the organizing principle. Every factual claim in an AI-generated document has a source tier that determines where to verify it. Tier one is the AI output itself — this is a starting hypothesis, not a fact. Tier two is a primary source: the original study, the vendor's official documentation, the regulatory text, the company's own press release, the product page, the published annual report. Tier two verification means you have gone to the actual source and read the original claim. Tier three is expert review: a subject matter expert (internal or external) with direct knowledge of the domain reviews the claim. For high-stakes decisions — board presentations, external publications, regulatory submissions — tier three verification is the standard. For internal working documents, tier two is usually sufficient.

The most important practical verification skill is source triangulation for statistics: never accept a quantitative claim from AI without identifying at least one named primary source. If AI claims "the SaaS churn benchmark for mid-market is 12%," your verification step is to find a published report — a Bessemer Venture Partners benchmark report, a ChurnZero industry survey, a Gainsight customer success report — that actually contains that figure. You are not verifying that the model is right; you are replacing the model's claim with a citable, traceable fact. If you cannot find a named primary source for a specific figure, the figure should not appear in a document that will inform decisions.

Citation checking is a specific technique for the ghost citation hallucination. When AI produces a reference to a research paper, study, or report, verify it using this sequence: (1) Search for the paper title in Google Scholar, PubMed (for academic papers), or a direct search. (2) Verify that the authors listed match the actual paper's authors. (3) Verify that the finding attributed to the paper is actually in the paper — not just that the paper exists, but that the specific claim AI attributed to it appears in the actual text. A common hallucination pattern is to cite a real paper but attribute findings from a different paper to it, or to reverse the paper's conclusions. (4) If you cannot find the paper, do not assume it is buried in an obscure database — assume it may not exist and remove the citation entirely.

Prompting for uncertainty is an underused technique that reduces verification workload by surfacing the high-risk claims at source. You can instruct AI to explicitly flag its own uncertainty rather than presenting everything with uniform confidence. This does not eliminate hallucinations — the model's self-reported uncertainty is itself imperfect — but it narrows the set of claims that require verification. Phrases like "tell me which of these claims you are most and least confident about" or "mark any specific statistics or facts where you are uncertain of the source" will often produce useful uncertainty flags, especially in more recent and capable models.

For time-constrained PMs, the quick verification workflow is a 10-minute process that covers the most critical verification priorities without requiring deep research dives. Step one (2 minutes): scan the document for all specific statistics, citations, and competitor facts — highlight them. Step two (5 minutes): for each highlighted item, run a quick Google search with the specific claim as the search query. If the first two or three results confirm the claim from credible sources, accept it. If results conflict or show no evidence of the claim, flag for deeper verification or removal. Step three (3 minutes): for any competitor-specific claims that you could not confirm in step two, check the competitor's official product pages, recent press releases, or pricing pages directly. Do not spend more than 60 seconds per competitor claim — if the claim is not easy to confirm from official sources, remove it from the document.

Hands-On Steps

1. Take an AI-generated competitive analysis or market research summary from your recent work. Apply the quick verification workflow: scan for all specific statistics and competitor facts, run Google verification searches for each, and note which claims are confirmed, which are unconfirmed, and which are contradicted by primary sources.
2. Practice prompting for uncertainty. Take a complex factual question relevant to your product domain (e.g., "What are the key GDPR requirements for SaaS companies processing EU customer data?") and run two versions of the prompt: one without uncertainty instructions, one with the addition "Please flag any specific claims where you are uncertain about the exact details, and indicate your confidence level for each section." Compare the two outputs and assess how much the uncertainty flagging changes the verification workload.
3. Build a source library for your product domain's most commonly referenced statistics. Identify the five most frequently cited benchmarks or market data points in your domain (e.g., industry average churn rate, typical enterprise sales cycle length, common NPS benchmark ranges). Find the primary source for each and bookmark or document it. When AI produces one of these figures in future, you already know the primary source to check against.
4. Test the ghost citation technique deliberately. Ask AI to recommend three industry research reports or studies on a topic relevant to your product. For each recommended report, search for it and verify its existence. This calibrates your trust level for AI-generated citations in your specific domain.
5. Create a verification symbol system for your team's shared documents. Use a simple marking convention: a checkmark (✓) next to statistics that have been verified against primary sources, a question mark (?) next to claims that are plausible but unverified, and a flag next to claims that were contradicted. This makes the verification status of any document visible at a glance.

Prompt Examples

Prompt:

I am going to share an AI-generated product market analysis with you. Please review it with a critical, skeptical lens and do the following: (1) list every specific quantitative claim (statistics, percentages, market figures, growth rates), (2) list every specific citation or reference to a study, report, or research source, (3) list every specific claim about a named competitor's product, features, or market position, (4) for each item, indicate your confidence level in its accuracy (HIGH/MEDIUM/LOW) and explain briefly why you are or are not confident, (5) flag any claims that you believe are likely hallucinations or that you would strongly recommend I verify before using in stakeholder communications. Here is the document: [PASTE DOCUMENT]

Expected output: A structured audit of the document's factual claims organized into three categories with confidence ratings and hallucination risk flags. This prompt effectively turns AI into its own fact-checking layer, surfacing the highest-risk claims for human verification without requiring you to manually identify every quantitative claim in the document.

Learning Tip: Build verification into your document completion ritual, not as a separate task that follows completion. When you finish editing an AI-assisted document, make "verification pass" the last required step before saving it as complete — not something you do before a meeting if you have time. Treating verification as a conditional step creates the conditions for a high-pressure moment to be the one where you skip it.

When to Trust AI Output vs. When to Verify Independently

The verification question that actually saves time is not "should I verify this?" — that produces the answer "yes" for everything and changes nothing. The question that changes behavior is "how much verification does this specific output type, at this specific stakes level, require?" Building a calibrated trust-versus-verify framework allows you to invest your verification effort precisely where it matters, rather than either verifying everything (inefficient) or nothing (risky).

The trust calibration matrix operates on two dimensions: output type (what kind of content did AI produce) and stakes level (what decisions will be influenced by this output and who will see it). Output types run from low-risk (structural, organizational, stylistic) to high-risk (specific factual claims about external reality). Stakes levels run from low (internal working notes that will be refined before use) to high (external stakeholder presentations, regulatory submissions, public communications, board materials).

High-trust scenarios — where AI output can be used with light or no verification — are those where the AI is working with information you provided (not generating information from its training data) and the output is structural or analytical rather than factual. When you paste five customer interview summaries and ask AI to identify common themes and organize them into a synthesis framework, the output is a reflection and structuring of your data — the AI cannot hallucinate facts that you gave it. When you ask AI to reformat a requirements table, write a meeting agenda based on an issue list you provided, or generate three alternative ways to frame a problem statement, it is working with provided inputs and producing structural outputs. These scenarios carry minimal hallucination risk.

Additional high-trust scenarios include: AI writing assistance (grammar, clarity, tone editing of your own content), generating multiple options for evaluation (where the output is options, not facts — you evaluate the options using your own judgment), summarizing long documents you have provided (the summary may miss nuances but it cannot fabricate content that was not in the source material), and building templates or frameworks (structural artifacts with no factual claims).

Verify-always scenarios are those where AI is generating specific factual claims about external reality from its training data. These are non-negotiable verification requirements, regardless of time pressure: any specific quantitative statistic being cited in stakeholder communications; any citation to a research study, industry report, or expert source; any claim about a specific competitor's product features, pricing, or market position; any regulatory or compliance requirement; any claim about technology capabilities (API specifications, integration capabilities, SDK behavior); any claim about market size, growth rates, or industry benchmarks; and any historical dates or timelines that are material to a decision.

The stakes amplifier means that even output types that are generally high-trust require verification when the stakes level is elevated. A casual team Slack summary of AI-assisted research can tolerate unverified claims (everyone understands it is a working note). The same content in a board presentation requires full verification of every quantitative claim. The stakes escalation triggers for moving from light verification to full verification are: the output will be seen by senior leadership or external stakeholders; the output will be used to justify a significant resource or investment decision; the output will be published externally; or the output will be used in a regulatory or legal context.

A practical way to operationalize this framework is with a document-level stakes classification before beginning any AI-assisted document. Before opening your AI tool, ask: who is the audience for this document, and what decision will it influence? If the audience is your immediate team and the decision is a working hypothesis, apply light verification. If the audience includes leadership, customers, or external parties, or if the decision involves significant resource allocation or public commitment, apply full verification.

Hands-On Steps

1. Draw the trust calibration matrix as a 2x2 grid: axes are Output Type (structural vs. factual) and Stakes Level (internal working document vs. stakeholder/external). For each quadrant, write two examples from your own recent work. This exercise makes the framework concrete and personal rather than theoretical.
2. Review your last 10 AI-assisted documents. For each one, retrospectively classify it on the trust calibration matrix and assess whether the verification effort you applied was appropriate. Note where you over-verified (low-stakes structural output) and where you under-verified (high-stakes factual content).
3. Build a simple pre-document checklist with two questions: "Is this output primarily structural (drawing from what I provided) or primarily factual (drawing from AI training data)?" and "Who is the audience, and what will they decide based on this?" Use the answers to set your verification effort level before beginning the task.
4. Practice the "provided vs. generated" distinction. For a single AI-assisted task, track which parts of the output came from information you provided in the prompt versus which parts came from the model's training knowledge. Verify only the latter.
5. Establish a team norm around document-level stakes labeling. Add a header line to team working documents: "Verification status: [Working draft — factual claims unverified / Stakeholder-ready — key statistics verified against primary sources]." This makes the verification status of any document immediately visible and creates social accountability for the review.

Prompt Examples

Prompt:

I am going to describe a product management task, and I want you to help me calibrate my verification effort. For the following task, tell me: (1) which parts of your output will draw on information I provide you (low hallucination risk), (2) which parts will draw on your training data knowledge (higher hallucination risk), (3) which specific elements of the output I should verify before using in stakeholder communications, and (4) what primary sources or search queries I should use to verify the high-risk elements. Task: [DESCRIBE YOUR SPECIFIC TASK, E.G., "Write a competitive landscape analysis comparing our product to three enterprise project management competitors, including their key features, pricing, and market positioning."]

Expected output: A structured breakdown of the proposed output's components into low-risk (user-provided) and high-risk (AI-generated) categories, with a specific verification checklist and recommended search queries for the high-risk elements. This meta-prompt approach lets you front-load the verification planning before any content is generated, making the verification workflow faster and more systematic.

Learning Tip: The fastest way to reduce verification workload without increasing risk is to shift from "AI generates, you verify" to "you provide facts, AI structures." When you paste the research you have already done — the actual market figures from named reports, the actual competitor pricing from vendor sites, the actual user quotes from your interviews — and ask AI to synthesize and structure them, you are feeding it your verified facts. The AI can then produce outputs with dramatically lower hallucination risk, because the factual content is grounded in what you provided.

Building a Team Culture of Healthy Skepticism Toward AI-Generated Content

Individual verification habits protect individual outputs. Team-level skepticism norms protect the entire product function's credibility and decision quality. In a team where AI-generated content flows into documents, presentations, and stakeholder communications without consistent verification standards, the organization's tolerance for AI assistance will eventually be broken by a single high-profile hallucination incident. Building the culture before the incident is both more effective and less costly than rebuilding trust after it.

The core team norm to establish first is the citation norm: AI-generated factual claims do not appear in stakeholder documents without a verified source. This is not a rule that every AI output needs citations — internal working documents, brainstorming outputs, and structural drafts are exempt. It is a rule specifically about content that will inform decisions made by people who will rely on it being accurate. The citation norm creates a clear binary: stakeholder document = factual claims verified and sourced; working document = clearly labeled as unverified. This distinction is enforced not through policing but through mutual accountability — when a team member shares a stakeholder document with unverified statistics, others ask "what's the source for that figure?" as a normal, non-accusatory question.

Implementing lightweight verification practices requires accepting that perfect verification is not the goal — proportional verification is. Three lightweight practices that teams can adopt without significant friction are: (1) the 5-minute pre-send scan: before sending any AI-assisted document to a stakeholder, spend five minutes scanning specifically for quantitative claims and competitor facts — not reading the whole document again, just scanning for the high-risk content categories. (2) The draft-label convention: any document where AI contributed factual content (not just formatting or structural help) is labeled "AI-assisted — key statistics TBC" until the verification pass is complete. This makes the verification status visible and prevents premature sharing. (3) The hallucination check prompt: teams establish a standard final prompt to run on any AI-generated stakeholder document before approval — something like "Review this document and flag any statistics or factual claims that you are uncertain about" — as a built-in self-audit step before human verification.

Recognizing AI overconfidence at the team level requires developing a shared vocabulary for discussing AI output quality. When AI produces a beautifully formatted, grammatically polished, confidently stated document, it creates an implicit aura of authority that is unrelated to factual accuracy. Teams that fall into this trap treat the visual quality of AI output as a proxy for factual quality — a cognitive bias that needs to be explicitly named and countered. The antidote is to normalize questions like "this looks polished but have we actually verified the numbers?" as expressions of good judgment rather than unnecessary skepticism. Team leaders model this behavior by asking it of their own AI-assisted outputs, not just others' work.

The long-term cultural goal is a team that uses AI with both high fluency and high discipline: moving fast on structural and synthesis tasks while applying systematic verification to factual claims, and maintaining consistent habits regardless of time pressure. This culture is built through repeated modeling by senior team members, brief regular reminders (a monthly "AI hygiene" note in the team newsletter, a verification checklist pinned in the team's shared space), and a blame-free incident review process when hallucinations do make it through — one that treats the incident as a process failure to fix, not a personal failure to punish.

Hands-On Steps

1. Introduce the citation norm to your team in your next team meeting. Explain the distinction between working documents (verification not required) and stakeholder documents (factual claims require a verified source). Discuss what this means for the team's specific workflow and agree on a practical implementation approach.
2. Create a "hallucination incident" template for your team — a brief, standardized record of any AI hallucination that makes it into a shared document. Include fields for: what the claim was, what the accurate information was, what type of prompt generated it, and what verification step was missed. Reviewing these quarterly builds team-wide pattern recognition.
3. Run a team workshop on AI overconfidence. Select three AI-generated documents from your team's recent work. As a group, identify which claims in each document were structural (AI organizing provided content) versus generative (AI drawing on training data). Discuss which claims required verification and which received it.
4. Establish a "healthy skeptic" recognition norm. When a team member catches a hallucination before it reaches stakeholders — either in their own work or a colleague's — acknowledge it as a positive contribution, not as a criticism. The goal is to make hallucination catching feel like a professional win, not an awkward correction.
5. Integrate an AI skepticism check into your team's document review process. Add one item to your existing document review checklist: "Has AI-generated factual content (statistics, citations, competitor claims) been verified against primary sources?" This makes verification part of the review gate, not an optional extra.

Prompt Examples

Prompt:

I want to create a brief training exercise for my product team on AI hallucination risk. The team uses Claude and Copilot daily for research synthesis, requirements writing, and competitive analysis. Design a 30-minute team workshop that includes: (1) a 5-minute introduction to what hallucinations are and why they matter for PM work (using a real example pattern, not a made-up scenario), (2) a hands-on exercise where team members test for hallucinations in a sample AI-generated competitive analysis, (3) a demonstration of two verification techniques (quick Google verification and prompting for uncertainty), and (4) a take-home reference card summarizing the team's verification norms. Include all content, instructions, and materials needed to run the workshop.

Expected output: A complete, runnable 30-minute workshop package including facilitator notes, exercise instructions, a sample AI-generated document (with planted hallucinations for the exercise), verification technique demonstrations, and a one-page take-home reference card. This is ready to use in your next team session with minimal preparation.

Learning Tip: The single most effective cultural intervention for AI skepticism is the first time a senior team member says, out loud and in front of the team, "I almost sent this to the VP without checking — it turned out this number was completely made up." Vulnerability modeling — where experienced practitioners openly acknowledge their own near-misses — normalizes the verification conversation and signals that catching hallucinations is a sign of good practice, not inexperience. If you are a team lead, start with your own story.

Key Takeaways

• AI hallucinations in product work most commonly manifest as fabricated market statistics, invented competitor details, ghost citations (real-sounding but nonexistent research references), and false regulatory or compliance claims. Each of these can cause serious professional damage if they make it into stakeholder documents or decision-making materials.
• Hallucinations happen because LLMs are pattern-completion engines, not fact retrieval systems. They generate statistically plausible text, not verified fact. Training data gaps, pattern completion bias, and confidence miscalibration are the three root causes most relevant for PM work.
• The verification hierarchy — AI output as hypothesis, primary source as tier-two verification, expert review as tier-three — is the framework for applying verification effort proportionally. Not every claim requires tier-three review; only high-stakes external documents do. Most internal work requires tier-two verification of specific statistics and competitor facts.
• The trust calibration matrix (output type x stakes level) gives you a practical decision rule for each document: high-trust for structural outputs based on your provided content, verify-always for specific factual claims drawn from AI training data, with stakes level amplifying verification requirements for any output type.
• Lightweight team verification practices — the pre-send scan, draft labeling, the final hallucination check prompt, and the citation norm for stakeholder documents — protect the team's credibility without creating heavy process overhead.
• AI overconfidence is a cognitive bias risk: well-formatted, polished AI output creates an implicit authority signal that is unrelated to factual accuracy. Teams that develop shared vocabulary for questioning AI-generated claims, and that model verification behavior at the senior level, build the skepticism norms that protect against high-profile hallucination incidents.