Plausibility Filter

The filter operates by embedding a reality-check instruction within the system prompt. This instruction explicitly tells the model to evaluate its proposed output against a commonsense knowledge base. For example, it might instruct: 'Before finalizing your answer, verify it does not contradict basic physical laws (e.g., objects cannot travel faster than light) or established historical timelines (e.g., Shakespeare could not have used a telephone).' The model is prompted to perform this internal validation step and, if a violation is detected, to output a predefined rejection token or a request for clarification instead of the implausible content.

A plausibility filter is implemented as a structured constraint within a system prompt or a verification step in a chain-of-thought process. A typical architecture includes:

• Primary Instruction: The core task (e.g., 'Write a story about a scientist').
• Plausibility Rule: A clear, conditional directive (e.g., 'Ensure all scientific equipment described existed in the 19th century').
• Rejection Protocol: A specified action for violations (e.g., 'If any detail is anachronistic, output: [ANACHRONISM_DETECTED]').
• Fallback Behavior: Guidance for what to do after a rejection (e.g., 'Then, ask the user for a corrected detail'). This creates a deterministic boundary for generation.

It is critical to distinguish a plausibility filter from a factual consistency check. A factual check verifies claims against provided source documents (e.g., 'Does your summary match the provided article?'). A plausibility filter checks against intrinsic, world-model knowledge the model is assumed to possess. For instance, a model might correctly summarize a provided fictional story about a talking cat (factually consistent with the source) but a plausibility filter would flag an output claiming a cat solved a quantum physics equation unless the story's universe established that as possible. It guards against category errors and logical impossibilities.

Plausibility filters are highly effective for temporal bounding and physical law enforcement.

Example 1 - Temporal: In a historical Q&A agent, the prompt includes: 'Your knowledge is bounded to events before 2020. If asked about a post-2020 event, state you cannot answer as it is beyond your knowledge cutoff.' This prevents the model from fabricating future events.

Example 2 - Physical: For a physics tutor: 'When explaining mechanics, all examples must obey Newton's laws. If you generate an example that violates conservation of energy, output: [LAW_VIOLATION] and revise.' This catches internally consistent but physically impossible narratives.

Plausibility filters are not foolproof. Their efficacy depends on the model's own world model accuracy and the precision of the instruction. Key limitations include:

• Model Blind Spots: If the base model has an incorrect or incomplete understanding of a commonsense principle (e.g., nuanced causality), the filter may fail.
• Over-Constraint: Poorly designed filters can cause excessive rejection of creative but valid content (e.g., flagging metaphor as implausible).
• Adversarial Prompts: A user might deliberately phrase a query to bypass the filter's logic (e.g., 'Write a fictional story where the premise is that gravity is repulsive').
• Scope Ambiguity: Defining the exact boundary of 'plausible' for edge cases (e.g., futuristic technology) can be challenging.

Plausibility filters are most powerful when combined with other hallucination mitigation patterns in a defense-in-depth strategy:

• With Grounding Prompts: First ground the response in source documents (factual check), then apply the plausibility filter to the grounded output.
• With Self-Verification: Use a ReAct-style loop where the model first generates an answer, then is prompted to critique it for plausibility in a subsequent step.
• With Confidence Thresholds: Instruct the model to only apply the filter to statements where its internal confidence is high, avoiding confusion on ambiguous topics.
• With Retrieval-Augmented Generation (RAG): The RAG system provides factual grounding, and the plausibility filter acts as a final commonsense sanity check on the synthesized answer.

This instruction explicitly prohibits the model from generating content that contradicts established laws of physics. It is crucial for scientific, engineering, or educational applications where factual integrity is non-negotiable.

• Example Instruction: "Before finalizing your answer, verify that it does not violate basic physical principles such as the conservation of energy, the laws of thermodynamics, or the speed of light as a universal constant. If a scenario you describe would require such a violation, state that it is physically impossible and explain why."
• Use Case: Preventing a model from describing a perpetual motion machine as feasible or a spaceship traveling faster than light without theoretical caveats.

This filter instructs the model to flag narratives or claims that involve impossible sequences of events, such as effects preceding causes or anachronisms.

• Example Instruction: "Your response must maintain logical temporal and causal relationships. Reject any narrative where an event is caused by something that happens later in time, or where technology, terminology, or known figures are placed in an incorrect historical period unless clearly labeled as alternate history."
• Use Case: Stopping a model from generating a story where a historical figure uses a smartphone in the 18th century without explanation, or a claim that a company's bankruptcy caused its founding.

This directive forces the model to perform a basic 'reality check' on any numbers, statistics, or magnitudes it generates or uses, catching gross exaggerations or impossible scales.

• Example Instruction: "Perform a sanity check on all quantitative claims. For example, a company's revenue cannot exceed global GDP, a building's height cannot be 100 miles, and a population cannot grow by 1000% in a day. If you generate a figure, ensure it is within plausible orders of magnitude for the context. Flag and correct any that are not."
• Use Case: Preventing a model from stating a local bakery serves 10 million customers daily or that a new processor performs 1 exaFLOP on a smartphone.

This filter targets violations of basic, shared world knowledge that are not necessarily scientific laws but are universally understood truths about everyday life.

• Example Instruction: "Ensure all descriptions align with commonsense reality. For instance, humans cannot breathe underwater unaided, trees do not grow in a week, and a single car cannot carry 500 people. If your output depends on such an impossibility, you must reject the premise or note the implausibility."
• Use Case: Catching a model generating a recipe that calls for 'boiling water at 50°C' or a logistics plan that assumes a sedan can transport a full orchestra.

This instruction requires the model to ensure its own output is free from internal contradictions, a key subset of plausibility where the narrative breaks its own established rules.

• Example Instruction: "Before providing your final answer, scan it for internal contradictions. A character cannot be in two distant cities simultaneously without explanation, a policy cannot both raise and lower taxes in the same clause, and a technical specification cannot list a device as both waterproof and incapable of withstanding moisture. If you find a contradiction, resolve it or state that the scenario is inconsistent."
• Use Case: Essential for long-form generation, legal document drafting, or creating consistent technical specifications.

This advanced filter instructs the model to adhere to the rules of formal logic and mathematics, rejecting statements that are logically false or mathematically undefined.

• Example Instruction: "Your reasoning must adhere to formal logic. Do not assert that 'A implies B' and 'A is true' but 'B is false.' Do not claim a mathematical object violates its own definition (e.g., a square with five sides). If a user query contains a logical paradox (e.g., 'This statement is false'), identify it as such rather than attempting to resolve it within the faulty framework."
• Use Case: Critical for educational tools, code generation (avoiding logically impossible conditions), and philosophical or technical Q&A.

A grounding prompt is an instruction that explicitly requires a language model to base its response solely on provided source material, verifiable facts, or a specific knowledge base. This technique directly prevents the model from extrapolating or inventing information not present in the context.

• Core Mechanism: Instructs the model to act as a "citable summarizer" or "context-only responder."
• Example Instruction: "Answer the question using only the information provided in the following document. Do not use any prior knowledge."
• Primary Use Case: Retrieval-Augmented Generation (RAG) systems, where user queries must be answered strictly from retrieved chunks.

A factual consistency check is a prompt instruction that directs a model to verify that all statements in its output are internally consistent and align with established facts or the provided context. It is often implemented as a follow-up step in a chain.

• Core Mechanism: Asks the model to review its own or another's output for contradictions or unsupported claims.
• Example Instruction: "Review the following summary. List any factual claims that cannot be directly supported by the source document provided earlier."
• Implementation Pattern: Frequently used within fact-checking loops and self-verification prompts to create multi-stage validation.

A self-verification prompt guides a model to act as its own critic, systematically checking its initial response for errors, inconsistencies, or unsupported claims before finalizing an answer. This introduces a deliberate reasoning step that reduces rash generation.

• Core Mechanism: Splits the task into Generate then Verify phases within a single prompt or conversational turn.
• Example Instruction: "First, draft an answer to the question. Second, review your draft. For each factual statement, confirm it is present in the source text. Revise any statements that cannot be confirmed."
• Benefit: Increases accuracy without requiring a separate, more powerful verification model.

The no fabrication rule is an absolute prompt prohibition that explicitly instructs the model not to invent details, quotes, data, or citations that are not present in the provided context. It is a foundational, non-negotiable guardrail for high-stakes applications.

• Core Mechanism: Uses strong, imperative language to set a zero-tolerance boundary.
• Example Instruction: "You must not make up any information. If the answer is not in the provided text, say 'I cannot find that information in the provided sources.'"
• Critical For: Legal document analysis, medical advice systems, and any domain where unsupported information carries significant risk.

A confidence threshold is a prompt parameter that instructs a model to only state information if its internal certainty exceeds a specified level; otherwise, it must express uncertainty or decline to answer. This technique calibrates the model's output to its actual knowledge.

• Core Mechanism: Leverages the model's ability to estimate its own confidence, often prompted explicitly.
• Example Instruction: "Only provide a numerical answer if you are highly confident (over 90% sure). If your confidence is lower, output 'Insufficient confidence to answer precisely.'"
• Relation to Calibration: Part of calibration prompt strategies aimed at improving the reliability of a model's self-assessment.

Structured verification is a prompt pattern that forces a model to output its fact-checking process in a predefined, machine-readable format. This makes the verification step explicit, auditable, and easier to evaluate programmatically.

• Core Mechanism: Requires output in a specific schema, such as JSON or a markdown table, listing claims and evidence.
• Example Instruction: "Output a JSON array where each object has 'claim', 'source_passage', and 'is_supported' (true/false) keys."
• Advantage: Enables deterministic output parsing and integration into automated evaluation-driven development pipelines, providing clear telemetry on hallucination rates.