Reality Check

The core mechanism of a reality check is an explicit instruction for the model to pause and evaluate whether its proposed output aligns with basic real-world physics, logic, or common sense. This is distinct from verifying against a provided source. For example, a prompt might instruct: 'Before finalizing your answer, ask: Could this sequence of events physically happen as described?' This targets commonsense hallucinations, where a model generates internally consistent but physically impossible scenarios.

A reality check is rarely a standalone instruction. It is typically integrated into a broader verification step or fact-checking loop within a complex prompt. The standard flow is:

• Generation: The model produces a draft response.
• Reality Check: The model is instructed to critique the draft for plausibility.
• Revision: The model corrects any identified implausibilities. This creates a self-correction mechanism, making it a key component of ReAct frameworks and Program-Aided Language Models where logical coherence is critical.

Reality checks are most effective against specific types of model error:

• Physical Impossibilities: Events violating laws of physics (e.g., instantaneous teleportation without mechanism).
• Temporal or Causal Nonsense: Illogical sequences (e.g., an effect occurring before its cause).
• Scale or Magnitude Errors: Wildly improbable quantities (e.g., a lemonade stand making billions in a day).
• Contradictions with Universal Knowledge: Statements contradicting well-established, non-esoteric facts (e.g., claiming humans can breathe underwater). It is less effective for nuanced factual errors requiring domain-specific source attribution.

Effective reality checks follow a consistent prompt design pattern:

1. Explicit Trigger: Use clear directive phrases like 'Perform a reality check:' or 'Assess plausibility:'.
2. Specific Criteria: Define the scope of the check (e.g., 'Check for physical feasibility, economic scale, and causal logic').
3. Structured Output: Often paired with structured output generation, forcing the model to list its assessment in a format like: `- Claim: [The claim made]
   • Plausibility: [High/Medium/Low]
   • Reason: [Brief explanation]` This pattern enforces deterministic output and makes the model's reasoning auditable.

Understanding the limits of a reality check is crucial for hallucination mitigation strategy.

• Not a Fact-Check: It does not verify against external data; that requires a grounding prompt or retrieval-augmented prompt.
• Model-Dependent: Its effectiveness relies on the model's embedded commonsense knowledge, which can be incomplete or biased.
• Ambiguous Scenarios: It struggles with edge cases that are improbable but not impossible.
• Cannot Replace Source Grounding: For factual accuracy on specific data, it must be combined with evidence requirements and source attribution instructions.

A reality check is one tool in a suite of context engineering methods for improving reliability. It is closely related to:

• Plausibility Filter: A passive rule that rejects implausible outputs; a reality check is the active instruction to apply that filter.
• Contradiction Detection: While contradiction detection looks for logical conflicts between statements, a reality check evaluates a single statement against world knowledge.
• Self-Verification Prompt: A broader category; a reality check is a specific type of self-verification focused on plausibility.
• Bounded Generation: A reality check helps enforce bounds by flagging outputs that stray into impossible scenarios.

In technical writing, a reality check prevents models from generating outputs that violate established scientific principles. For example, an instruction like 'Before finalizing, verify that no proposed chemical reaction violates the law of conservation of mass or energy' forces the model to apply basic physical filters. This is critical for generating educational content, research summaries, or draft engineering specifications where factual integrity is paramount. Common applications include:

• Peer-review assistance: Screening draft manuscripts for fundamental scientific impossibilities.
• Educational content generation: Ensuring textbook explanations or problem sets are physically coherent.
• Technical documentation: Preventing the suggestion of infeasible system specifications or processes.

Reality checks are used to ground financial projections and analyses in plausible economic scenarios. A prompt might instruct: 'Assess if the projected 500% quarterly growth rate is plausible given industry benchmarks and historical data before presenting it.' This forces the model to contextualize numbers against known realities, mitigating the risk of presenting extreme or impossible figures as fact. This application is vital for:

• Earnings report summaries: Flagging anomalies or outliers that defy sector norms.
• Market analysis: Ensuring predicted stock movements or economic indicators align with possible volatility ranges.
• Risk assessment reports: Validating that simulated stress-test scenarios remain within the bounds of economic history.

Even in creative domains, reality checks maintain internal consistency and basic plausibility within a story's established world. An instruction such as 'Confirm that the character's actions in Chapter 3 do not contradict their established abilities or the story's rules of magic/physics' guides the model to act as a continuity editor. This prevents jarring breaks in logic that undermine narrative immersion. Key uses include:

• Script and screenplay development: Ensuring character motivations and plot events remain consistent.
• Interactive fiction and game dialogue: Maintaining coherent character personas and world-state across branching paths.
• Generative world-building: Applying consistent rules to generated lore, geography, and societal structures.

In legal contexts, a reality check ensures generated clauses, timelines, and obligations are logically consistent and practically executable. A prompt directive like 'Verify that the proposed contract clause does not create a logically impossible condition (e.g., payment due before service is rendered) or contradict another section' applies a formal logic filter. This reduces the risk of generating legally nonsensical or self-defeating text. Applications include:

• Contract generation: Screening for temporally impossible sequences of events or obligations.
• Regulatory compliance summaries: Ensuring described processes align with the practical constraints of the regulated industry.
• Policy document analysis: Identifying internal contradictions or requirements that are physically impossible to fulfill.

When generating product requirements or user experience flows, reality checks validate feasibility against technological and human constraints. An instruction such as 'Before describing the feature, assess if the proposed one-click action is physically possible on a standard smartphone touchscreen' grounds the output in real-world interaction design principles. This prevents the specification of magical or unimplementable interfaces. This is used for:

• Feature brainstorming: Filtering out ideas that violate basic UI/UX heuristics or hardware limitations.
• Technical requirement documents: Ensuring described system behaviors are computationally plausible.
• User story generation: Creating scenarios that reflect realistic user capabilities and environments.

For summarizing historical events or news, reality checks prevent anachronisms and spurious causal claims. A prompt might state: 'Before finalizing the timeline, confirm that no cited event is placed outside its verified historical period or attributed to a person known to be deceased at that time.' This applies a temporal and causal plausibility filter, crucial for educational and journalistic assistive tools. Specific applications involve:

• Educational content creation: Preventing the misdating of events or invention of non-existent treaties/battles.
• News article summarization: Flagging summaries that imply causations not present in the source articles.
• Biographical generation: Ensuring the sequence of a subject's life events adheres to the verified historical record.

An instruction that explicitly requires a language model to base its response solely on provided source material, verifiable facts, or a specific knowledge base to prevent extrapolation and fabrication. This is a foundational technique for Retrieval-Augmented Generation (RAG) architectures.

• Mechanism: The prompt acts as a hard constraint, tethering the model's generative process to the input context.
• Example Instruction: "Answer the question using only the information contained in the provided documents. Do not use any outside knowledge."
• Key Benefit: Directly addresses the 'open-book' vs. 'closed-book' problem, forcing the model into an open-book reasoning mode.

A directive that instructs a model to verify that all statements in its output are internally consistent and align with established facts or the provided context. This is often implemented as a self-verification prompt in a multi-step process.

• Process: The model is instructed to generate a response, then review it to flag any contradictions or unsupported claims.
• Distinction from Reality Check: While a reality check assesses plausibility, a factual consistency check assesses logical and informational coherence against a defined set of facts.
• Use Case: Critical in summarization tasks to ensure the summary does not contradict the source text.

A prompt directive that mandates the model to cite the specific documents, data points, or references supporting each factual claim in its response. This enforces verifiable claim generation and is essential for auditability.

• Format Enforcement: Often paired with a citation format specification (e.g., [Doc1, Section 2]).
• Primary Function: Creates a direct, traceable link between the model's output and its source, enabling human-in-the-loop verification.
• Enterprise Application: Foundational for legal, medical, and financial AI applications where provenance is non-negotiable.

A prompt instruction that trains a model to explicitly state when it lacks sufficient information or is unsure about a fact, rather than guessing. This is often governed by a confidence threshold parameter.

• Instruction Example: "If you cannot find sufficient evidence in the context to support a complete answer, state 'Insufficient information provided' for that specific part."
• Psychological Basis: Counters the model's inherent tendency towards confident completions, aligning its communicative behavior with its actual epistemic state.
• Safety Impact: Reduces the risk of high-confidence hallucinations, which are the most dangerous type of fabrication.

An instruction that directs a model to identify and resolve conflicting statements within its own output or between its output and the provided source material. It is a core component of a fact-checking loop.

• Operational Mode: Can be performed as a self-correction step or as a cross-reference instruction across multiple sources.
• Output: The model may be prompted to list detected contradictions and then produce a revised, consistent version.
• Advanced Use: Integral to multi-source synthesis tasks where conflicting information from different documents must be reconciled.

An absolute prompt prohibition that explicitly instructs the model not to invent details, quotes, data, or citations absent from the provided context. This is the most direct hallucination guardrail.

• Instruction Style: Uses definitive language like "Do not invent," "Do not extrapolate," or "Only use what is given."
• Relation to Bounded Generation: Serves as the strictest form of bounding, limiting generation to a closed set of provided tokens.
• Implementation Challenge: Requires the model to have robust contextual anchoring capabilities to distinguish between retrieval from context and recall from parametric memory.