Self-Consistency and Verification Prompts for More Reliable Answers

Why a second answer is not automatically a better answer

Ask an AI assistant a difficult question once and it may make a mistake. Ask it three times and it may make the same mistake three times. Ask it to “check carefully” and it may produce a more polished version of the original error.

Yet repeated attempts and deliberate checking can improve reliability. The difference lies in what you repeat, what you compare, and what counts as evidence.

Self-consistency means generating multiple candidate solutions and looking for agreement between their answers. Verification means testing an answer against something that could establish whether it is correct: a calculation, a document, an executable test, a rule or a trustworthy external source.

These techniques solve different problems. Self-consistency helps reveal unstable answers and sometimes identifies a stronger candidate. Verification helps establish whether that candidate deserves your trust.

Neither makes an AI system infallible. Both become useful when you turn vague instructions such as “be accurate” into specific checks with observable outcomes.

This article develops a practical workflow for doing that. You will see how to compare numerical answers, audit a policy summary, check generated code and decide when further prompting is no longer worth the effort.

The central principle is simple:

Do not ask only whether the model agrees with itself. Ask what would demonstrate that its answer is wrong.

What self-consistency actually means

The research technique and the everyday adaptation

The research paper Self-Consistency Improves Chain of Thought Reasoning in Language Models describes sampling multiple reasoning paths and selecting an answer based on agreement across those paths.

Instead of relying on one generated solution, the method gathers several candidates. If different routes converge on the same final answer, that answer may be more dependable than a single attempt.

For everyday use, a practical adaptation is:

1. Give the same well-specified problem to the model several times.
2. Keep the attempts separate so later answers do not simply imitate earlier ones.
3. Extract the final answer from each attempt.
4. Group equivalent answers.
5. Investigate disagreement and check the leading answer.

This is not identical to every research implementation. A chat interface may not expose sampling settings, and separate chats do not guarantee statistical independence. Nevertheless, separating attempts reduces one obvious source of contamination: showing each new attempt what it is expected to confirm.

For more background on how sampling affects variation, see Temperature, Top-p and Sampling: How AI Chooses Its Next Word.

Where agreement is useful

Self-consistency is easiest to apply when answers have a recognisable form:

• A number with a unit.
• A date calculated from explicit rules.
• A multiple-choice option.
• A category from a fixed list.
• A short factual answer.
• A structured extraction from a document.

Suppose five independent attempts produce delivery estimates of eight, eight, eleven, eight and eleven working days. You have a leading answer, but also a warning: the task may contain an ambiguity or a repeated counting mistake.

The useful next step is not “choose eight because it won”. It is “identify why some attempts counted three additional days”.

For open-ended tasks, such as proposing a business strategy, simple voting is less meaningful. Two recommendations can differ while both being reasonable. You need evaluation criteria, not merely a tally.

What agreement does not establish

Multiple outputs from the same model share training, design and often the same informational blind spots. They may all recall the same outdated rule or make the same plausible assumption.

Imagine asking five people to check a train time when all five consult the same obsolete timetable. Their agreement is real, but it does not validate the timetable.

The same distinction applies to AI:

• Answer agreement means outputs converge.
• Evidence agreement means relevant evidence supports a conclusion.
• Independent corroboration means support comes from sources or methods that do not merely repeat the same underlying claim.

These are different levels of assurance.

This is especially important for factual questions. If every attempt confidently invents the same publication title, majority voting will not rescue you. The failure is missing or unreliable knowledge, not unstable calculation. Why AI Hallucinates: Causes, Types and How to Reduce Them explains that distinction in more detail.

What verification adds

Turn answers into testable claims

A long answer is difficult to check as one unit. Break it into claims that can individually pass or fail.

Consider this sentence:

The annual plan costs £240, saves 20% compared with monthly billing, and can be cancelled at any time for a full refund.

It contains at least three claims:

1. The annual price is £240.
2. The annual price represents a 20% saving.
3. Cancellation always produces a full refund.

Each needs a different check. The price requires a current pricing source. The percentage requires a calculation using the correct monthly price. The refund statement requires contract or policy wording.

A useful verification prompt makes those checks explicit:

Break the draft into independently checkable claims.

For each claim, return:
- Exact claim
- Claim type: factual, numerical, interpretive or recommendation
- Evidence needed
- Check that would confirm or contradict it
- Current status: supported, contradicted or unresolved

Do not treat the draft itself as evidence.
Do not fill evidence gaps with plausible assumptions.

This converts an impressionistic review into a list of concrete tasks.

Verification needs a reference point

Different tasks call for different reference points:

Task	Stronger verification method
Arithmetic	Recalculate with a calculator or executable expression
Document summary	Compare each material claim with quoted source passages
Code	Run tests against an explicit specification
Current policy	Check a dated, authoritative source
Data extraction	Compare extracted fields with their original locations
Recommendation	Test assumptions, constraints and consequences
Formatting	Validate against a schema or checklist

Asking another language model whether an answer “looks right” is weaker than checking it against a relevant reference point.

A second model can still be useful: it may notice missing cases or questionable assumptions. But its agreement is another judgement, not a substitute for evidence.

Blind checks reduce anchoring

If you show a checker the proposed answer first, you give it something to rationalise. A stronger approach is to ask the checker to answer a targeted question from the evidence before revealing the draft.

The paper Chain-of-Verification Reduces Hallucination in Large Language Models explores a workflow involving a draft, verification questions, answers to those questions and a revised response. One important design choice is reducing the influence of the original draft on verification.

An everyday version looks like this:

Using only the policy text below, answer this question:

Under which conditions is a customer entitled to a full refund?

Quote the relevant passages.
If the text does not establish a condition, say "not established".
Do not infer terms from common industry practice.

Policy:
[paste source text]

Only after receiving this answer should you compare it with the original refund claim.

Build a workflow before you build a longer prompt

Step 1: Define what success looks like

Before generating candidates, specify the task, relevant inputs and acceptance criteria.

For a calculation, acceptance criteria might include:

• Correct numerical result.
• Correct currency and rounding.
• No double-counted costs.
• Explicit treatment of fixed and variable charges.

For a summary, they might include:

• Every material statement supported by the supplied text.
• Important exceptions retained.
• No outside facts introduced.
• Ambiguous wording labelled as ambiguous.

This prevents a common failure: using verification to check the wrong interpretation of the task.

A compact specification can be more valuable than several paragraphs of instructions to “think deeply”.

Step 2: Produce separate candidates

Use three candidates as a manageable starting point for a moderately important task. That is a practical choice, not a magic number or an accuracy guarantee.

Where possible, use separate calls or chats. Give each the complete task and source material, but not the previous candidates.

Ask for an answer plus brief, checkable support:

Solve the task below independently.

Return:
1. Final answer
2. Assumptions that materially affect the answer
3. A concise calculation, source quotation or other checkable support
4. Any unresolved ambiguity

Do not invent missing inputs.
If essential information is absent, identify it.

Task:
[task and evidence]

You do not need a transcript of hidden internal reasoning. What you need is an external explanation that can be checked: equations, source passages, test results or clearly stated assumptions.

Step 3: Compare meaning, not typography

Equivalent answers can look different. “£1,200”, “1200 GBP” and “one thousand two hundred pounds” should normally fall into the same group.

Conversely, superficially similar answers may differ materially. “Within 30 days” is not necessarily equivalent to “within one month”. “Revenue” is not interchangeable with “profit”.

Use a comparison table:

Candidate	Normalised answer	Material assumption	Verification needed
A	£1,200	Fee excludes tax	Confirm tax treatment
B	£1,440	Fee includes 20% tax	Confirm tax treatment
C	£1,200	Fee excludes tax	Confirm tax treatment

Here the disagreement is not arithmetic. It is an unresolved input.

Step 4: Verify the decisive points

Do not check every sentence with equal effort. Identify the claims that would change the outcome if wrong.

Examples include:

• Whether a deadline includes weekends.
• Whether a discount applies before or after a fixed fee.
• Whether a policy exception applies to the customer.
• Whether a code function handles an empty input.
• Whether a source is current enough for the question.

This concentrates attention on errors that matter.

Step 5: Publish a result with its limits

A reliable final answer should distinguish the answer from its verification status.

For example:

The total is £1,200 excluding tax. The arithmetic has been recalculated. The supplied quote does not establish whether tax is included, so the amount payable remains unresolved.

That is more useful than either unjustified certainty or a vague “please double-check”.

For larger tasks, this staged approach is a form of Prompt Chaining: Breaking Complex Tasks Into Reliable Steps. Each stage should produce something the next stage can inspect, rather than merely extending the previous prose.

Worked example: comparing two subscription plans

The task

Suppose a small organisation is comparing two fictional software plans.

• Plan A costs £24 per user per month.
• Plan A gives a 15% discount on subscription charges when billed annually.
• Plan B costs £20 per user per month, billed annually, with no further discount.
• Plan B has a one-off £180 onboarding fee.
• There are 12 users.
• Ignore tax.
• Compare the first 12 months.

The task is:

Which plan is cheaper for the first 12 months, and by how much?

Use exactly 12 users.
Apply Plan A's discount only to subscription charges.
Include Plan B's one-off onboarding fee once.
Ignore tax.

Return the total for each plan, the cheaper plan and the difference.
Include the arithmetic expressions used.

Candidate answers and the disagreement they expose

Imagine three attempts return:

Candidate	Plan A	Plan B	Conclusion
A	£2,937.60	£3,060.00	A cheaper by £122.40
B	£2,937.60	£2,880.00	B cheaper by £57.60
C	£2,937.60	£3,060.00	A cheaper by £122.40

Two candidates agree. But the useful observation is more specific: all three agree on Plan A, while Candidate B appears to omit the onboarding fee.

Self-consistency has located a likely error. Verification must establish it.

Verify by explicit calculation

The checkable expressions are:

Plan A:
24 × 12 users × 12 months × 0.85 = 2937.60

Plan B:
20 × 12 users × 12 months + 180 = 3060.00

Difference:
3060.00 - 2937.60 = 122.40

A calculator or spreadsheet can evaluate these independently of the prose.

You can also cross-check monthly equivalents:

Plan A annual-billing equivalent:
24 × 0.85 = 20.40 per user per month

Plan A annual total:
20.40 × 12 × 12 = 2937.60

Plan B recurring annual total:
20 × 12 × 12 = 2880.00

Plan B first-year total:
2880.00 + 180 = 3060.00

These calculations use the same inputs but organise them differently. That makes it easier to spot a misplaced discount or duplicated charge.

Use a counterexample to test the scope

A good answer should not quietly turn “cheaper in the first year” into “always cheaper”.

If the rates remain unchanged and the onboarding fee does not recur:

• Plan A remains £2,937.60 in the second year.
• Plan B becomes £2,880.00.
• Plan B is then cheaper by £57.60.

This does not change the first-year answer. It prevents an overgeneralised recommendation.

A useful final response is:

Plan A is cheaper for the first 12 months by £122.40: £2,937.60 versus £3,060.00. This includes Plan B’s £180 onboarding fee once. If prices stay unchanged, Plan B has the lower recurring annual cost after the first year.

Exercise: change one assumption

Repeat the comparison for ten users, then answer these questions:

1. Did every candidate use ten rather than twelve?
2. Was the onboarding fee still added only once?
3. Did the leading answer survive recalculation?
4. Did any candidate confuse first-year cost with recurring cost?

The correct first-year totals are £2,448 for Plan A and £2,580 for Plan B. Plan A is cheaper by £132.

The exercise illustrates why copying a previous answer and changing a few words is risky. Verification should check that changed inputs actually propagate through the calculation.

Worked example: checking a policy summary

Start with a bounded source

Consider this fictional training policy:

Employees may claim up to £600 per calendar year for approved
professional training.

Written manager approval must be obtained before purchase.

Claims must be submitted within 30 days of payment.

Travel, accommodation and subscription renewals are excluded.

Employees serving a notice period are not eligible for new approvals.

An assistant produces this summary:

Every employee receives £600 a year for professional development. Submit a claim within a month, and your manager can approve it afterwards. Courses and related travel are covered.

The summary is fluent, short and substantially wrong.

Self-consistency alone may not help if repeated attempts simplify the same restrictive wording. The task needs source-level verification.

Extract claims and compare them with the text

Use this prompt:

Audit the summary against the supplied policy.

For each material claim:
- Quote the claim from the summary.
- Quote the relevant policy wording.
- Classify it as supported, contradicted or not established.
- Give a corrected version if necessary.

Also list policy conditions omitted from the summary.
Use only the supplied policy.

Policy:
[paste policy]

Summary:
[paste summary]

A useful audit would identify:

Summary claim	Status	Reason
Every employee receives £600	Contradicted	It is a claim allowance up to £600, with eligibility conditions
Submit within a month	Imprecise	The source specifies 30 days
Approval can happen afterwards	Contradicted	Written approval is required before purchase
Related travel is covered	Contradicted	Travel is explicitly excluded

It should also flag missing exclusions and the notice-period restriction.

Verify omissions as well as statements

Fact-checking often focuses only on what an answer says. Summaries can also mislead through what they leave out.

Ask a separate coverage question:

List every policy condition that could change:
- whether an employee is eligible;
- whether a purchase qualifies;
- how much can be claimed; or
- whether a claim is submitted correctly.

Then mark each condition as present or absent in the summary.

This is a different test. A summary might contain no outright false sentence yet still omit a critical deadline.

The related guide Summarising Documents: Checking What Was Missed explores this coverage problem further.

Produce a corrected summary

A defensible revision is:

Eligible employees may claim up to £600 per calendar year for approved professional training. Written manager approval is required before purchase, and claims must be submitted within 30 days of payment. Travel, accommodation and subscription renewals are excluded. Employees serving a notice period cannot receive new approvals.

Notice that the revision does not answer questions the policy leaves open. It does not invent a reimbursement timetable or explain how part-time allowances work.

A further verification prompt could ask:

Which practical questions remain unanswered by this policy?
Separate missing information from contradictions.
Do not supply invented policy terms.

Possible unanswered questions include whether the allowance is prorated for new starters and what evidence must accompany a claim.

Exercise: create a trap summary

Write a two-sentence summary that deliberately introduces three errors:

1. Change a deadline.
2. Remove a condition.
3. Add a plausible benefit.

Run the audit prompt in a fresh chat. Check whether it catches all three.

Then remove the false statements but keep one important omission. Run the coverage check. This tests whether your workflow catches both incorrect content and missing content, rather than merely producing a convincing review.

Worked example: verifying generated code

Specify behaviour before asking for implementation

Suppose you need a Python function that returns the median of a list of numbers.

Requirements:

• Accept a list of integers or floats.
• Do not modify the original list.
• Return the middle value for odd-length lists.
• Return the mean of the two middle values for even-length lists.
• Raise ValueError for an empty list.
• Assume inputs contain only finite numbers.

Without these details, an AI-generated function may be “correct” under a different interpretation.

A candidate implementation is:

def median(values):
    if not values:
        raise ValueError("median requires at least one value")

    ordered = sorted(values)
    midpoint = len(ordered) // 2

    if len(ordered) % 2:
        return ordered[midpoint]

    return (ordered[midpoint - 1] + ordered[midpoint]) / 2

Reading the code is useful. Running meaningful tests is stronger.

Generate tests from the specification, not the code

If a checker sees the implementation first, it may write tests that mirror what the code already does. Instead, give it only the requirements:

Write Python assertions for the following specification.

Cover:
- A single item
- An odd number of unsorted items
- An even number of items
- Negative values
- Duplicate values
- Empty input
- Preservation of the original list

Derive expected results from the specification.
Do not assume any implementation details.

Specification:
[paste requirements]

A small test set is:

assert median([5]) == 5
assert median([9, 1, 3]) == 3
assert median([8, 2, 4, 6]) == 5
assert median([-5, -1, -3]) == -3
assert median([2, 2, 9]) == 2

original = [3, 1, 2]
median(original)
assert original == [3, 1, 2]

try:
    median([])
except ValueError:
    pass
else:
    raise AssertionError("Expected ValueError for empty input")

These tests expose common mistakes: failing to sort, selecting the wrong middle elements, mutating the input or returning an arbitrary value for an empty list.

Check the tests themselves

Tests can be wrong too. Verification therefore includes checking the expected outputs.

For [8, 2, 4, 6], the sorted list is [2, 4, 6, 8]; the middle pair is 4 and 6; the median is 5. That expectation is easy to inspect.

More advanced testing can check relationships rather than isolated examples. For finite inputs where numerical precision is appropriate:

• Reordering a list should not change its median.
• The median should lie between the smallest and largest input values.
• Adding the same amount to every input should shift the median by that amount.

These properties help identify errors beyond the hand-picked cases. They still need sensible numerical tolerances for floating-point inputs.

Distinguish suggested tests from executed tests

An assistant that merely writes assertions has not demonstrated that the implementation passes them.

Require clear status:

State separately:
- Tests proposed
- Tests actually executed
- Observed results
- Remaining untested behaviour

Do not describe tests as passed unless they were run.

If the assistant cannot execute code, run the tests yourself in an appropriate environment. Passing this small suite establishes limited evidence, not universal correctness or production readiness.

The same principle applies to spreadsheets, SQL and shell commands: an apparently sound explanation is not an execution result.

Design prompts that challenge rather than reassure

Ask for falsification

“Confirm that this is correct” points the reviewer towards agreement. “Find the most consequential way this could be wrong” creates a different task.

A useful prompt is:

Review this answer for material errors.

Identify up to three plausible failure points.
For each:
- State the claim or assumption at risk.
- Describe a concrete check.
- Apply the check if the necessary evidence or tools are available.
- Report supported, contradicted or unresolved.

Do not invent faults to satisfy the requested count.
Do not rewrite the answer unless a change is justified.

The final two instructions matter. Otherwise, a reviewer may manufacture objections or make needless changes to an already correct answer.

Separate error detection from rewriting

Asking for criticism and a polished rewrite in the same breath can cause the rewrite to outrun the evidence.

Use two stages:

1. Produce an audit with supported corrections.
2. Revise only the claims affected by those corrections.

This preserves correct material and makes changes traceable.

The paper Self-Refine: Iterative Refinement with Self-Feedback explores iterative feedback and revision. However, results from a particular workflow do not establish that any request to “improve your answer” will improve factual accuracy.

Research including Large Language Models Cannot Self-Correct Reasoning Yet illustrates limitations of correction without external feedback in studied settings. The practical lesson is not that revision never works. It is that unsupported introspection should not be mistaken for verification.

Make evidence easy to inspect

Ask for concise evidence beside each important claim:

Return a table with:
claim | evidence location | supporting quotation or calculation |
status | limitation

For documents, use page numbers, section headings or paragraph identifiers if available. For web sources, include the source URL and the relevant date where it matters.

Do not accept a citation merely because it looks official. Check that the source exists, that the quoted passage appears there and that it supports the particular claim.

A structured table also makes unresolved items harder to hide in fluent prose. For automated workflows, Prompting for Structured Output: JSON, Tables and Schemas explains how to make such records easier to process.

Common mistakes that weaken the whole process

Generating “independent experts” in one response

A prompt asking one model to simulate five experts can produce varied perspectives. It does not create five independent sources of knowledge.

The simulated experts may share the same assumption, and their discussion may converge because the model is composing a coherent conversation.

Use this technique for brainstorming objections, not as evidence that five genuine checks have occurred.

Repeating an underspecified question

If the input omits a jurisdiction, date, unit or definition, repeated answers may simply sample different assumptions.

Before taking a vote, ask:

Are these candidates answering the same question?

If not, clarify the task or report conditional answers. More samples cannot resolve missing information that only the user or a source can provide.

Treating majority vote as a confidence percentage

Four matching answers out of five do not mean “80% likely to be correct”.

The outputs are not necessarily independent, and the sampling process is not a calibrated measurement of correctness.

Record “four of five candidates agreed” if useful. Do not translate that directly into a probability.

Likewise, a model’s self-reported confidence is not automatically reliable. Language Models (Mostly) Know What They Know investigates self-evaluation under particular conditions; it is not a licence to treat every conversational confidence score as calibrated.

Asking for sources without checking support

A real source can be irrelevant. A relevant source can be outdated. A current source can be quoted accurately but interpreted too broadly.

For each decisive factual claim, check:

1. Does the source actually contain the relevant information?
2. Does it apply to the right time, population and jurisdiction?
3. Does it support the exact wording of the claim?
4. Is a more direct source available?

For organisation-specific questions, retrieval can supply the right documents, but retrieval is only the beginning. Retrieval-Augmented Generation (RAG) Explained for Beginners describes how that information reaches the model; verification checks whether the answer uses it faithfully.

Burying the evidence in a huge context

Pasting every available document into a chat does not ensure that the model will use the relevant passage.

Lost in the Middle: How Language Models Use Long Contexts documents sensitivity to the position of information in long contexts in studied settings.

A practical response is to identify relevant sections, preserve their surrounding qualifications and ask targeted questions. Keep enough context to interpret a clause correctly, but avoid making the checker search through unrelated material unnecessarily.

Checking only easy details

It is tempting to verify spelling, arithmetic and formatting while leaving the central assumption untouched.

A beautifully formatted mortgage comparison is still misleading if it compares different repayment periods. A correct percentage is useless if its denominator represents the wrong population.

Start with the claim whose failure would most change the decision.

Match verification effort to the stakes

Use three practical levels

Not every answer needs a multi-stage audit. The goal is proportionate checking.

Light check: Suitable for low-stakes, reversible tasks such as a meeting agenda or an informal explanation. Review for obvious errors, unmet requirements and unsupported claims.

Targeted verification: Suitable for budgets, document summaries, published factual content and routine analytical work. Generate separate candidates where helpful, check decisive claims and preserve source references.

High-assurance review: Appropriate when errors could affect health, legal rights, safety, significant money or important organisational decisions. Use authoritative evidence, validated tools and appropriately qualified human review. Prompting alone is not sufficient assurance.

The NIST AI Risk Management Framework provides a broader foundation for thinking about AI risks in context. The practical implication here is that the cost of being wrong should influence how much checking you require.

Set a stopping rule

Verification can become an endless conversation. Set a stopping rule before you begin.

For example:

Stop when:
- All decision-critical claims have been checked;
- No unresolved contradiction changes the conclusion; and
- Remaining uncertainty is explicitly stated.

If a critical claim cannot be checked with available evidence,
stop and report what information or expert review is needed.

This is better than continuing until the model sounds confident.

For a bounded calculation, one independent recalculation may settle the issue. For a disputed interpretation of policy, several additional AI responses may add nothing. The next useful action may be asking the policy owner.

Protect sensitive information

Verification sometimes involves sending the same material to several services. That can multiply exposure of confidential data.

Before using multiple models or external tools:

• Remove unnecessary personal information.
• Check which services your organisation permits.
• Share the minimum relevant extract.
• Avoid uploading confidential documents merely to gain an extra vote.
• Keep source access controls intact.

A more varied checking process is not automatically worth a greater privacy risk.

A complete practice session

Choose a task with a knowable answer

For your first session, avoid a broad question such as “Which career should I choose?” Pick something you can verify:

• Compare two fictional quotations.
• Summarise a short public policy.
• Extract deadlines from a document.
• Write and test a small function.

Choose a task with several plausible failure points but manageable evidence.

Run the exercise step by step

Step 1: Write the specification. Include inputs, exclusions, required output and the conditions for a correct answer. Spend time removing ambiguity.

Step 2: Generate three separate candidates. Use identical task wording initially. Save each answer without editing it.

Step 3: Normalise the outputs. Put numerical answers into the same units. Separate conclusions from assumptions. Mark materially different interpretations.

Step 4: Predict the likely failure. Before asking for an audit, write down what you think may be wrong. This keeps you actively involved rather than outsourcing all judgement.

Step 5: Create blind verification questions. Ask about decisive facts without including the candidate conclusion. For example, “What costs recur annually?” rather than “Is Plan A cheaper?”

Step 6: Apply an external check. Use the original document, a calculator or executed tests. Record what actually happened.

Step 7: Reconcile the results. Keep supported claims, correct contradicted ones and label unresolved issues.

Step 8: Write a final answer with a verification note. State the conclusion, its scope and any missing evidence that could change it.

Evaluate the workflow, not just the answer

Afterwards, ask:

• Did checking catch a material error?
• Did all candidates share a mistaken assumption?
• Did the verifier introduce a new mistake?
• Was the source sufficient to answer the question?
• Which check provided the most useful evidence?
• Could a simpler process have reached the same assurance?

Keep a short record across repeated tasks. Do not judge a method by one impressive rescue or one disappointing failure.

For a repeatable workflow, build a small collection of representative tasks with known answers or review criteria. Compare single-pass answers with verified answers, including time and cost. Avoid tuning everything to one example and assuming the improvement will generalise.

A reusable prompt pack

These templates are deliberately modular. Use only the stages the task needs.

Candidate-generation prompt

Task:
[question]

Inputs and evidence:
[material]

Requirements:
[units, dates, exclusions, output format]

Produce an independent answer.

Return:
- Final answer
- Material assumptions
- Concise, checkable support
- Missing information or unresolved ambiguity

Do not invent missing facts.

Candidate-comparison prompt

Compare the candidates below against the original task.

Group equivalent final answers.
Identify disagreements in:
- Inputs
- Assumptions
- Calculations
- Source interpretation
- Scope

Do not decide correctness by majority vote alone.
For each material disagreement, propose a decisive check.

Original task:
[task]

Candidates:
[candidate answers]

Blind-verification prompt

Answer the verification questions using only the supplied evidence
and tools that are actually available.

For each question:
- Give the answer.
- Provide a source quotation, calculation or observed test result.
- State any limitation.

Do not claim to have browsed, calculated with a tool or run code
unless that action actually occurred.

Evidence:
[material]

Verification questions:
[questions without proposed answers]

Reconciliation prompt

Revise the draft using the verification results.

Rules:
- Keep supported claims.
- Correct contradicted claims.
- Remove or qualify unsupported claims.
- Preserve unresolved uncertainty.
- Do not introduce new factual claims without evidence.

Return:
1. Final answer
2. Material corrections made
3. Remaining limitations

Draft:
[draft]

Verification results:
[results]

The value of these templates is not a special phrase. It is the separation of generation, comparison, evidence collection and revision.

The habit that matters most

Reliable AI use is not a contest to find the sternest wording for “be correct”. It is a habit of making important claims inspectable.

Use self-consistency to discover whether an answer is stable and where interpretations diverge. Use verification to determine whether the answer survives contact with evidence. Use human judgement to decide whether the remaining uncertainty is acceptable.

When a task is important, a shorter answer with checked calculations, traceable sources and clear limits is usually more useful than a longer answer that merely sounds certain.

FAQ

Is self-consistency the same as asking the AI to try again?

Not quite. “Try again” often produces a revised answer influenced by the first attempt. Self-consistency involves generating multiple candidates and comparing their final answers. Separate attempts reduce direct copying, although they still share the model’s underlying limitations.

How many candidate answers should I generate?

Start with a small number that you can inspect, such as three. Increase it only if additional attempts provide useful variation. There is no universal optimum. If every candidate relies on the same missing fact, obtain that fact rather than generating more answers.

Should I increase temperature to get more diverse answers?

Possibly, if your interface exposes it and the task benefits from candidate variation. Higher temperature changes sampling; it does not add knowledge or guarantee useful diversity. Keep inputs and acceptance criteria stable, and evaluate whether the resulting candidates improve the workflow.

Is asking a second model better than asking the same model again?

A second model may bring different capabilities and error patterns, but independence is not guaranteed. Models can share source material and common misconceptions. Different verification methods, such as calculation plus document checking, can be more valuable than a second model’s opinion.

Can an AI verify its own answer without tools?

It can identify contradictions, compare text with supplied evidence, reconsider assumptions and suggest tests. Those are useful activities. However, it cannot establish a current external fact from missing evidence, and it should not claim to have executed tests or consulted sources it did not access.

What should I do when the candidates disagree?

Classify the disagreement first. Different arithmetic calls for recalculation. Different assumptions call for clarification. Different factual claims call for source checking. Different recommendations may reflect different priorities. Do not average incompatible answers or choose a majority until you understand what caused the split.

Do I need detailed step-by-step reasoning from the model?

You need enough checkable support to evaluate the answer, not an exhaustive account of internal reasoning. Ask for equations, relevant quotations, assumptions, brief explanations and observed test results. These artefacts are generally more useful for verification than a long narrative about how the answer was reached.

Can verification prompts eliminate hallucinations?

No. They can help expose unsupported claims and improve a workflow, but they may also miss errors or introduce new ones. Reliability depends on the evidence, tools, task specification and review process. For consequential decisions, verification prompts should support appropriate professional or human review, not replace it.