Self-Review and Answer Verification

Introduction

Large language models can generate useful answers quickly, but the first answer is not always fully correct, complete, or properly formatted. The model may misunderstand an instruction, overlook an important constraint, make a calculation error, produce invalid code, or include a claim that is not supported by the supplied information.

Self-review and answer verification prompting is the practice of asking the model to examine its own output before presenting or finalizing it. The model checks the answer against defined rules, finds possible problems, and revises the response where needed.

A simple generation prompt asks:

Explain dependency injection in simple language.

A verification-based prompt asks:

Explain dependency injection in simple language.
Review the answer before finalizing it.
Check technical accuracy.
Check whether the explanation is suitable for a beginner.
Remove unnecessary technical terms.
Include one practical Java example.
Return only the corrected final answer.

The second prompt does more than request content. It also defines how the content must be checked.

Self-review is useful for:

• Technical explanations
• Mathematical answers
• Code generation
• Data analysis
• Reports
• Business documents
• Structured JSON output
• Research summaries
• Policy-based responses
• Multi-step reasoning tasks

However, self-review should not be treated as guaranteed proof of correctness. A model may repeat the same mistake during review. Important answers should also be checked with external tools, trusted references, automated tests, or human experts.

What Is Self-Review?

Self-review is a process in which a model examines its own generated answer against a set of requirements.

The model may check:

• Whether every instruction was followed
• Whether the facts agree with each other
• Whether the reasoning is logically valid
• Whether calculations are correct
• Whether generated code works
• Whether the output follows the required format
• Whether important information is missing
• Whether claims are supported
• Whether uncertain statements are clearly marked

A self-review prompt normally contains three stages:

1. Generate the initial answer.
2. Check the answer against defined criteria.
3. Revise the answer before returning it.

A basic self-review prompt can be written as:

Answer the question.
Review your answer for correctness and completeness.
Identify any errors or missing points.
Correct all identified problems.
Return only the revised final answer.

What Is Answer Verification?

Answer verification is the process of testing whether an answer satisfies specific correctness conditions.

Verification is more focused than a general review. Instead of asking whether the answer “looks good,” the prompt defines what must be checked.

For example:

Verify whether every SQL query is valid for MySQL 8.
Check whether every selected non-aggregated column appears in the GROUP BY clause.
Check whether the query can return duplicate rows.
Correct the query if any issue is found.

The verification criteria are specific and testable.

A strong verification prompt should define:

• What must be verified
• Which standards or rules should be used
• What evidence should be examined
• What to do when an error is found
• What output should be returned

Why Self-Review and Verification Are Important

Self-review improves answer quality by adding a controlled checking stage.

Its main benefits include:

• Reducing instruction-following errors
• Detecting contradictions
• Finding missing requirements
• Correcting calculation mistakes
• Improving code reliability
• Preventing invalid output structures
• Separating facts from assumptions
• Making uncertainty visible
• Improving consistency across long answers
• Supporting safe use of AI-generated content

Without verification, a response may appear confident even when it is incomplete or incorrect.

For example, consider this request:

Calculate the total cost of 12 items priced at ₹249 each and add 18% GST.

A model may calculate the base cost correctly but apply GST incorrectly. A verification step can require the model to independently recompute each value.

Calculate the base cost.
Calculate the GST amount separately.
Calculate the final total.
Recalculate the result using a second method.
Compare both results before returning the answer.

This does not guarantee correctness, but it creates a stronger checking process.

Learning Objectives

After completing this chapter, you should be able to:

• Ask a model to review its own answer
• Check whether instructions were followed
• Verify factual and logical consistency
• Verify calculations using independent methods
• Review generated code for correctness
• Validate JSON, tables, and other output formats
• Identify missing information
• Detect unsupported claims
• Add useful confidence labels
• Design verification checklists
• Request an independent verification pass
• Revise answers after verification
• Create reusable verification prompt templates

Prerequisites

Before learning self-review and answer verification, you should understand:

• Basic prompt structure
• Clear task instructions
• Context and constraints
• Output format prompting
• Step-by-step task decomposition
• Structured output prompting
• Basic logical reasoning
• Basic code and calculation concepts

You do not need advanced programming knowledge, but technical knowledge is useful when verifying code-related answers.

Key Terminology

Basic Verification Workflow

A reliable answer verification workflow normally contains the following stages:

1. Understand the original task.
2. Extract all instructions and constraints.
3. Generate a draft answer.
4. Check instruction compliance.
5. Check factual and logical consistency.
6. Verify calculations or code where applicable.
7. Check the output format.
8. Identify missing information.
9. Identify unsupported claims.
10. Revise the answer.
11. Perform a final verification.
12. Return the corrected answer.

A reusable prompt for this workflow is:

Read the complete task carefully.
List the requirements internally before answering.
Produce a draft answer.
Check the draft against every requirement.
Check factual consistency.
Check logical consistency.
Check calculations and technical details where applicable.
Identify missing information and unsupported claims.
Correct every confirmed issue.
Return only the verified final answer.

The prompt does not need to request private hidden reasoning. It can request a short verification report, checklist result, or corrected answer.

Requesting an Answer Review

Requesting an answer review means explicitly asking the model to inspect its generated response before finalizing it.

A weak review instruction is:

Check your answer.

This instruction is too broad. It does not tell the model what to check.

A stronger review instruction is:

Review the answer before finalizing it.
Check whether every user requirement is covered.
Check whether any statement contradicts another statement.
Check whether technical terms are used correctly.
Check whether examples support the explanation.
Correct all confirmed issues.
Return only the revised answer.

The quality of the review depends on the quality of the review criteria.

Types of Answer Reviews

General review

Checks overall quality, clarity, correctness, and completeness.

Technical review

Checks domain-specific rules, terminology, code, architecture, formulas, or standards.

Editorial review

Checks grammar, readability, tone, structure, and repetition.

Compliance review

Checks whether the output follows all user instructions and restrictions.

Risk review

Checks whether the answer includes unsafe assumptions, missing warnings, or unreliable recommendations.

Example: Reviewing a Technical Explanation

Initial prompt:

Explain Java garbage collection to a beginner.
Use simple language.
Include one example.
Keep the answer below 300 words.

Review-enhanced prompt:

Explain Java garbage collection to a beginner.
Use simple language.
Include one practical example.
Keep the answer below 300 words.
Review the answer before returning it.
Check whether the explanation incorrectly suggests that garbage collection happens immediately.
Check whether the example is technically accurate.
Check the word limit.
Return only the corrected final explanation.

Example: Separate Review and Revision

Write an explanation of REST API idempotency.
After writing the draft, review it using the following criteria.
Confirm that GET, PUT, DELETE, and POST are described accurately.
Confirm that repeated requests are explained correctly.
Confirm that network retries are discussed.
List the detected issues briefly.
Provide a revised final answer.

This prompt requests both a review result and a corrected answer.

Best Practices

• Define specific review criteria.
• Review the answer against the original task.
• Separate confirmed errors from optional improvements.
• Ask the model to correct problems instead of only listing them.
• Use domain-specific checks for technical content.
• Request only the final revised answer when the review notes are not needed.
• Request a review report when auditing is important.

Checking Instruction Compliance

Instruction compliance means checking whether the answer follows every instruction in the prompt.

An answer can be factually correct and still fail the task because it ignores formatting, length, audience, tone, or content requirements.

For example, the user may request:

Explain inheritance in Java.
Use exactly five bullet points.
Include one code example.
Do not discuss interfaces.
Keep the answer below 250 words.

A response fails instruction compliance when it:

• Uses more than five bullet points
• Omits the code example
• Discusses interfaces
• Exceeds 250 words
• Uses difficult language

Instruction Compliance Process

1. Extract every explicit instruction.
2. Convert each instruction into a testable condition.
3. Check the draft against each condition.
4. Mark each condition as passed or failed.
5. Correct all failed conditions.
6. Perform the compliance check again.

Compliance Checklist Example

Prompt Example

Complete the requested task.
Before returning the answer, create an internal checklist of every explicit instruction.
Check each instruction individually.
Do not treat partial compliance as full compliance.
Revise the answer until every non-conflicting instruction is satisfied.
Return only the final compliant answer.

Handling Conflicting Instructions

Sometimes two instructions cannot both be followed.

Example:

Explain the topic in complete detail.
Keep the answer below 50 words.

The model should not silently ignore one instruction. It should identify the conflict or follow the higher-priority requirement when the priority is clear.

A conflict-handling prompt can say:

Detect any conflicting instructions.
Follow the higher-priority instruction when priority is clear.
When two user requirements cannot both be satisfied, state the conflict briefly.
Do not claim full compliance when a requirement was not satisfied.

Practical Compliance Prompt

Review the answer against the original request.
Check topic coverage.
Check audience level.
Check tone.
Check length.
Check prohibited content.
Check required examples.
Check output format.
Correct every compliance failure.
Return the verified answer.

Checking Factual Consistency

Factual consistency means ensuring that factual statements agree with the supplied information, trusted references, and other statements in the answer.

Two types of factual problems commonly occur:

• External factual error
• Internal factual contradiction

An external factual error occurs when a statement is incorrect in the real world.

An internal contradiction occurs when different parts of the answer disagree.

Example:

• Section one says a project started in January.
• Section four says the same project started in March.

Even when the correct date is unknown, the answer is internally inconsistent.

Factual Consistency Checks

A factual review should ask:

• Does each factual statement match the supplied context?
• Do names, dates, numbers, and versions remain consistent?
• Does one section contradict another section?
• Are technical definitions accurate?
• Are current facts being presented as current?
• Are assumptions clearly marked?
• Are examples being presented as real facts?
• Are sources available for important claims?

Prompt Example

Review every factual statement in the answer.
Compare each statement with the supplied context.
Check names, dates, quantities, versions, and technical definitions.
Identify contradictions between sections.
Mark uncertain facts instead of presenting them as certain.
Remove or correct unsupported factual statements.
Return the revised answer.

Example: Project Summary Verification

Context:

The project started in April 2025.
The team contains six developers.
The backend uses Java 21 and Spring Boot 3.
PostgreSQL is used as the database.

Verification prompt:

Write a project summary using only the supplied facts.
Verify that the start date remains April 2025.
Verify that the team size remains six developers.
Verify that Java 21 and Spring Boot 3 are not changed.
Verify that PostgreSQL is not replaced with another database.
Do not add facts that are not present in the context.

Closed-Context Factual Verification

When all facts must come from supplied content, use a closed-context instruction:

Use only the information provided in the reference text.
Do not use outside knowledge.
For every factual claim, confirm that it is supported by the reference text.
Remove claims that cannot be supported.
State “Not provided” when required information is missing.

Limitations

A model cannot always confirm external factual accuracy without access to reliable sources or tools. Self-review may improve consistency but cannot replace:

• Official documentation
• Trusted databases
• Current web sources
• Expert review
• Direct measurements
• Primary evidence

Checking Logical Consistency

Logical consistency means checking whether the conclusion follows from the evidence and whether different parts of the reasoning can all be true together.

A logically inconsistent answer may contain correct individual facts but combine them incorrectly.

Example:

1. All active users must have verified email addresses.
2. Rahul is an active user.
3. Rahul does not need a verified email address.

The third statement conflicts with the first two statements.

Common Logical Problems

• Contradictory statements
• Unsupported conclusions
• Circular reasoning
• Invalid cause-and-effect claims
• False comparisons
• Missing reasoning steps
• Overgeneralization
• Confusing correlation with causation
• Applying a rule outside its valid conditions
• Ignoring an exception

Logical Review Questions

• Does the conclusion follow from the stated facts?
• Are all required assumptions stated?
• Does any statement contradict an earlier statement?
• Is a possibility incorrectly presented as certainty?
• Is correlation being treated as causation?
• Is one example being used to prove a universal rule?
• Are alternatives ignored without justification?
• Are conditions and exceptions handled correctly?

Prompt Example

Check the logical consistency of the answer.
Identify the main conclusion.
Identify the facts and assumptions supporting the conclusion.
Check whether the conclusion follows from those facts.
Check for contradictions, circular reasoning, missing steps, and unsupported cause-and-effect claims.
Correct the reasoning where possible.
Clearly state when the available information is insufficient.

Example: Business Decision

Evaluate whether the company should launch the product.
Separate facts from assumptions.
Check whether each recommendation follows from the available data.
Do not assume that high website traffic guarantees high sales.
Consider at least one alternative explanation.
State which missing data could change the recommendation.

Example: Conditional Logic

Requirements:

• Premium users can export reports.
• Trial users cannot export reports.
• Administrators can export reports regardless of subscription type.

Verification prompt:

Review the access-control logic.
Check every user type separately.
Check whether the administrator exception overrides subscription restrictions.
Identify any condition that allows a trial user to export without administrator access.
Return the corrected decision table.

Logical Decision Table

Decision tables make logical verification easier because each condition can be checked separately.

Checking Calculations

Calculation verification checks whether formulas, values, units, intermediate steps, and final results are correct.

A calculation can fail because of:

• Incorrect arithmetic
• Wrong formula
• Incorrect order of operations
• Unit conversion error
• Percentage error
• Rounding error
• Missing value
• Duplicate value
• Incorrect sign
• Incorrect assumption
• Data copied incorrectly

Calculation Verification Process

1. List the input values.
2. State the formula.
3. Substitute the values.
4. Calculate intermediate values.
5. Check units.
6. Recalculate using a second method.
7. Compare the two results.
8. Apply rounding only at the required stage.
9. Return the verified result.

Example: GST Calculation

Question:

Calculate the total price of 12 products costing ₹249 each with 18% GST.

Verification:

Base amount:

12 × ₹249 = ₹2,988

GST amount:

₹2,988 × 18 ÷ 100 = ₹537.84

Final amount:

₹2,988 + ₹537.84 = ₹3,525.84

Independent check:

₹2,988 × 1.18 = ₹3,525.84

Both methods produce the same result.

Verification Prompt

Solve the calculation.
List all input values.
State the formula before using it.
Show the important intermediate results.
Preserve units in every step.
Recalculate the final result using a different method.
Compare both results.
Report any difference.
Return the verified result with the required rounding.

Percentage Change Verification

For percentage change:

New value minus old value divided by old value multiplied by 100.

Example:

Old value = 80 New value = 100

Difference:

100 − 80 = 20

Percentage increase:

20 ÷ 80 × 100 = 25%

A common error is dividing by the new value instead of the old value.

Verification prompt:

Check that percentage change uses the original value as the denominator.
Check whether the result represents an increase or decrease.
Check the sign.
Check the final percentage independently.

Unit Verification

Example:

Distance = 150 kilometres Time = 2.5 hours

Speed:

150 km ÷ 2.5 h = 60 km/h

The units must remain consistent. Mixing kilometres and seconds without conversion produces an invalid result.

Calculation Prompt Template

Calculate the requested value.
Extract every numeric input from the task.
Confirm the unit of each input.
State the formula.
Substitute the values.
Show the intermediate calculations.
Check the order of operations.
Check percentage bases and unit conversions.
Recalculate independently.
Return the final verified result.

Important Limitation

For important financial, engineering, statistical, or scientific calculations, use a calculator, spreadsheet, programming language, or domain-specific tool. Language-model self-review alone is not enough for high-impact decisions.

Checking Code Correctness

Code correctness verification checks whether generated code is syntactically valid, logically correct, safe, complete, and suitable for the requested environment.

Code may look correct while containing hidden problems such as:

• Syntax errors
• Incorrect conditions
• Null handling errors
• Wrong return values
• Infinite loops
• Resource leaks
• Invalid API usage
• Version incompatibility
• Security vulnerabilities
• Missing exception handling
• Incorrect data types
• Race conditions
• Performance problems
• Unhandled edge cases

Code Review Areas

A code verification prompt should check:

• Language and version
• Syntax
• Imports and dependencies
• Variable types
• Control flow
• Method return values
• Null and empty input handling
• Boundary conditions
• Exception handling
• Resource management
• Security
• Performance
• Thread safety
• Testability
• Expected output

Java Code Example

The following method contains a logical error:

public static int divide(int first, int second) {
    return second / first;
}

The method name and parameter order suggest that the expected operation is first divided by second, but the implementation performs second divided by first.

A corrected version is:

public static int divide(int first, int second) {
    if (second == 0) {
        throw new IllegalArgumentException("Second value must not be zero");
    }
    return first / second;
}

Code Verification Prompt

Review the Java code for correctness.
Check compatibility with Java 21.
Check syntax and required imports.
Check whether each method performs the behaviour described by its name.
Check null, empty, zero, negative, and boundary inputs.
Check exception handling.
Check resource management.
Check time and space complexity.
Identify security risks.
Provide corrected code.
Provide test cases for every corrected issue.

Test-Based Verification

A stronger code review asks the model to generate test cases.

For example:

Review the method.
Derive the expected behaviour from the requirement.
Create tests for normal input.
Create tests for empty input.
Create tests for null input.
Create tests for minimum and maximum values.
Create tests for invalid input.
Check whether the implementation passes each test.
Correct the implementation if a test fails.

Example: Java Validation Method

Requirement:

• Return true when the age is between 18 and 60, including both limits.

Incorrect implementation:

public static boolean isEligible(int age) {
    return age > 18 && age < 60;
}

The implementation excludes 18 and 60.

Corrected implementation:

public static boolean isEligible(int age) {
    return age >= 18 && age <= 60;
}

Test cases:

Security Verification Prompt

Review the code for security problems.
Check input validation.
Check SQL injection risks.
Check command injection risks.
Check cross-site scripting risks.
Check authentication and authorization logic.
Check hard-coded secrets.
Check sensitive data exposure.
Check unsafe file access.
Provide secure corrections.
Do not claim the code is fully secure without testing.

Runtime Verification

A language model may inspect code, but actual execution is stronger evidence.

Use:

• Compiler
• Unit tests
• Integration tests
• Static analysis
• Linter
• Type checker
• Security scanner
• Performance profiler
• Runtime logs

The strongest prompt combines review with executable testing:

Review the code statically.
Generate unit tests.
Run the tests when execution tools are available.
Report actual test results separately from predicted results.
Do not claim that unexecuted code was tested.

Checking Output Format

Output format verification checks whether the response follows the required structure.

Common formats include:

• Markdown
• JSON
• XML
• YAML
• CSV
• HTML
• Tables
• Numbered lists
• Fixed schemas
• Code-only output

A response may contain correct information but still be unusable when its format is invalid.

Common Format Errors

• Invalid JSON syntax
• Missing required fields
• Extra fields
• Wrong field types
• Incorrect nesting
• Invalid enum values
• Markdown headings at the wrong level
• Incorrect number of list items
• Additional explanation outside the required structure
• Invalid CSV quoting
• Unclosed HTML tags
• Incorrect column order

JSON Verification Example

Required schema:

• name must be a string
• age must be an integer
• skills must be an array of strings
• status must be either active or inactive

Verification prompt:

Return valid JSON only.
Include exactly the fields name, age, skills, and status.
Use a string for name.
Use an integer for age.
Use an array of strings for skills.
Use only active or inactive for status.
Do not include comments.
Do not include Markdown.
Validate the JSON structure before returning it.

Example output:

{
    "name": "Asha",
    "age": 29,
    "skills": [
        "Java",
        "Spring Boot"
    ],
    "status": "active"
}

Table Format Verification

Prompt:

Return a Markdown table.
Use exactly four columns.
Use the column order Topic, Difficulty, Status, Notes.
Include exactly five data rows.
Do not write text before or after the table.
Verify the number of columns and rows before returning it.

Format Checklist

• Is the required format used?
• Are all required fields present?
• Are prohibited fields absent?
• Are data types correct?
• Is nesting correct?
• Is the item count correct?
• Is the column order correct?
• Is additional text prohibited?
• Can the output be parsed?
• Does the output match the requested schema?

Format Verification Prompt

Validate the output format before returning it.
Check the required structure.
Check required and optional fields.
Check field names.
Check data types.
Check nesting.
Check allowed values.
Check item counts.
Remove any text outside the required format.
Return only the validated output.

Identifying Missing Information

Missing-information detection checks whether the available input contains enough information to complete the task reliably.

Models often fill gaps with assumptions. This can make an answer sound complete even when important facts were never provided.

For example:

Create a project cost estimate.

This request does not provide:

• Project scope
• Team size
• Duration
• Hourly rates
• Technology
• Infrastructure requirements
• Testing requirements
• Maintenance period

A reliable model should identify these gaps instead of inventing precise costs.

Types of Missing Information

Required information

The task cannot be completed reliably without it.

Optional information

The task can be completed, but the answer may be less precise.

Contextual information

Information that changes the recommended approach.

Verification information

Evidence needed to confirm a claim or result.

Missing-Information Prompt

Analyse whether the supplied information is sufficient.
Identify every missing detail that materially affects the answer.
Separate required information from optional information.
Do not invent missing facts.
Ask only the minimum necessary questions.
When reasonable assumptions are allowed, state them clearly.

Example: Software Architecture

Request:

Design a scalable architecture for my application.

Missing information may include:

• Expected users
• Peak requests per second
• Data volume
• Read and write ratio
• Availability target
• Budget
• Deployment environment
• Security requirements
• Geographic distribution
• Recovery requirements

Verification prompt:

Before designing the architecture, identify missing requirements.
Mark each missing requirement as critical or optional.
Explain briefly how each critical requirement affects the design.
Do not select a final architecture until the critical requirements are resolved.
When assumptions are necessary, list them explicitly.

Missing-Information Table

Best Practices

• Do not ask for information that is already available.
• Focus on details that materially affect the answer.
• Separate blockers from helpful details.
• Avoid inventing names, dates, prices, or requirements.
• Make assumptions visible.
• Provide a provisional answer only when the assumptions are acceptable.

Identifying Unsupported Claims

An unsupported claim is a statement presented as true without enough evidence.

Examples include:

• “This architecture will handle one million users.”
• “This strategy will increase sales by 40%.”
• “This code is completely secure.”
• “This is the best framework.”
• “Users always prefer shorter forms.”

These claims may be possible, but they require evidence, measurements, tests, or reliable sources.

Types of Unsupported Claims

• Unsupported factual claims
• Unsupported performance claims
• Unsupported causal claims
• Unsupported predictions
• Unsupported comparisons
• Unsupported safety claims
• Unsupported legal or medical claims
• Unsupported statements using words such as always, never, guaranteed, and best

Claim Verification Process

1. Extract each important claim.
2. Identify the evidence supporting it.
3. Check whether the evidence is relevant.
4. Check whether the evidence is sufficient.
5. Mark unsupported claims.
6. Remove, qualify, or verify those claims.
7. Separate fact, inference, opinion, and assumption.

Prompt Example

Review the answer for unsupported claims.
List every important factual, numerical, causal, comparative, and predictive claim.
Identify the evidence supporting each claim.
Mark claims that are not supported by the supplied information.
Replace absolute language with qualified language where appropriate.
Do not invent sources or evidence.
Return the revised answer.

Fact, Inference, and Assumption

Consider this statement:

“Website traffic increased after the new design was released, so the design caused the increase.”

Available data may show only that both events occurred near the same time. It does not prove causation.

A better version is:

“Website traffic increased after the new design was released. The timing suggests a possible relationship, but additional data is required to confirm whether the design caused the increase.”

Unsupported Claim Checklist

• Is evidence provided?
• Does the evidence directly support the claim?
• Is the claim stronger than the evidence?
• Is a prediction presented as certainty?
• Is correlation presented as causation?
• Is an opinion presented as fact?
• Is a single example generalized to all cases?
• Is a performance result claimed without testing?
• Is a source invented or unavailable?
• Should uncertainty be stated?

Closed-Source Verification Prompt

Use only the supplied reference material.
Support every factual claim with information from that material.
Do not add outside facts.
Remove claims that cannot be supported.
Clearly label reasonable inferences.
State when the source does not contain enough information.

Confidence Labels

Confidence labels communicate how certain the model is about an answer or claim.

Examples include:

• High confidence
• Medium confidence
• Low confidence
• Verified
• Partially verified
• Unverified
• Requires external confirmation

Confidence labels are useful when:

• Information is incomplete
• Multiple interpretations are possible
• The answer depends on assumptions
• Current information may have changed
• A calculation was not executed with a tool
• Code was reviewed but not compiled
• A claim depends on uncertain evidence

Simple Confidence Scale

Evidence-Based Confidence

Confidence should be linked to evidence rather than writing style.

Weak confidence instruction:

Give a confidence percentage.

The model may produce a precise-looking number without a reliable basis.

Stronger instruction:

Assign High, Medium, or Low confidence.
Base the label on evidence quality, completeness of information, number of assumptions, and verification method.
Explain the reason in one sentence.
Do not use a numerical percentage unless a defined statistical method supports it.

Claim-Level Confidence

Different statements in one answer may have different confidence levels.

Example:

Confidence Prompt

Review each major conclusion.
Assign High, Medium, or Low confidence.
Base confidence on available evidence.
State the main reason for the label.
Do not use confidence as a replacement for verification.
Mark claims requiring external testing.

Limitations of Confidence Labels

Confidence labels are estimates, not proof. A confidently written answer can still be wrong. Confidence should not replace:

• Tests
• Measurements
• Source verification
• Expert review
• Formal proof
• Current official documentation

Verification Checklists

A verification checklist converts broad quality goals into specific checks.

Instead of saying:

Make sure the answer is correct.

A checklist says:

Check whether all required topics are included.
Check whether definitions are accurate.
Check whether examples match the definitions.
Check whether any section contradicts another section.
Check whether unsupported claims are present.
Check whether the final format is valid.

Benefits of Verification Checklists

• Make review criteria visible
• Reduce forgotten requirements
• Improve consistency
• Support repeatable workflows
• Make failures easier to identify
• Help human reviewers audit the answer
• Improve multi-step task reliability

General Answer Verification Checklist

• The answer addresses the correct task.
• Every required topic is covered.
• No instruction is ignored.
• Facts are consistent.
• Reasoning is logically valid.
• Calculations are checked.
• Code is reviewed where applicable.
• The requested format is followed.
• Missing information is identified.
• Unsupported claims are removed or qualified.
• Assumptions are visible.
• Confidence is appropriate.
• The final answer is clear and complete.

Technical Article Checklist

• Correct topic and audience
• Accurate definitions
• Correct terminology
• Clear explanation order
• Practical examples
• No repeated sections
• No contradictory statements
• No unsupported performance claims
• Correct code examples
• Correct output examples
• Required headings included
• Required formatting followed

Code Verification Checklist

• Correct programming language
• Correct language version
• Valid syntax
• Required imports present
• Correct data types
• Correct conditions
• Correct loop boundaries
• Null handling
• Empty-input handling
• Exception handling
• Resource cleanup
• Security checks
• Performance checks
• Tests included
• Actual execution status stated

Calculation Verification Checklist

• Inputs copied correctly
• Formula selected correctly
• Units are consistent
• Substitution is correct
• Arithmetic is correct
• Percentage base is correct
• Sign is correct
• Rounding is applied correctly
• Independent recalculation matches
• Final unit is present

Structured Output Checklist

• Valid syntax
• Correct schema
• Required fields present
• Extra fields removed
• Correct data types
• Correct nesting
• Allowed values used
• Correct item count
• No unwanted explanation
• Output can be parsed

Checklist Prompt Template

Review the answer using the following checklist.
Mark each item as Pass, Fail, or Not Applicable.
Provide one short reason for every failed item.
Correct every failed item that can be corrected.
Repeat the checklist after revision.
Return the final answer and the final checklist.

Independent Verification Prompts

Independent verification means checking an answer using a method that is meaningfully different from the original generation method.

Simply asking the same model to “think again” may reproduce the same mistake. A stronger approach changes the method, perspective, evidence, or role used during verification.

Forms of Independent Verification

• Recalculate using a second formula
• Solve a problem from the result back to the inputs
• Generate test cases instead of rereading code
• Compare the answer with official documentation
• Use a different decomposition of the problem
• Ask a critic role to challenge the answer
• Check each claim against evidence
• Use a tool such as a compiler or calculator
• Compare multiple candidate solutions
• Verify edge cases separately

Independent Calculation Verification

Solve the problem using the direct formula.
Solve the same problem using an alternative method.
Compare the two results.
Investigate any difference before finalizing the answer.

Reverse Verification

Reverse verification works backward from the result.

Example:

If 12 items with 18% GST cost ₹3,525.84, remove GST:

₹3,525.84 ÷ 1.18 = ₹2,988

Then verify the item price:

₹2,988 ÷ 12 = ₹249

This confirms the original inputs.

Prompt:

Verify the final result by reversing the calculation.
Recover the original inputs from the final answer.
Compare the recovered inputs with the supplied values.
Correct the result if they do not match.

Independent Code Verification

Review the code without relying on the original explanation.
Derive expected behaviour directly from the requirements.
Create tests before examining the implementation details.
Run the implementation against the tests when tools are available.
Compare actual behaviour with required behaviour.
Correct every mismatch.

Critic Prompt

Act as an independent technical reviewer.
Assume the proposed answer may contain errors.
Challenge every major assumption.
Search for contradictions, missing cases, invalid conclusions, and unsupported claims.
Do not rewrite the answer until the review is complete.
Then provide a corrected version.

Competing Solutions

Produce two independent solutions to the problem.
Use a different approach for each solution.
Compare the assumptions, intermediate results, and final conclusions.
Resolve any disagreement.
Return the answer supported by the stronger verification.

Source-Based Verification

Compare the answer with the supplied official documentation.
Identify every statement that conflicts with the documentation.
Prefer the documentation when a conflict exists.
Do not invent documentation content.
Revise the answer using only verified information.

Important Difference

Self-review asks:

“Did I make a mistake?”

Independent verification asks:

“Can I test this answer through a separate method?”

The second approach normally provides stronger evidence.

Revision after Verification

Verification is useful only when detected problems are corrected.

Revision after verification means:

1. Record the identified issue.
2. Determine the cause.
3. Correct the affected part.
4. Check whether the correction affects other sections.
5. Re-run the verification.
6. Return the corrected answer.

Common Revision Types

• Correcting a factual error
• Replacing an unsupported claim
• Fixing a formula
• Correcting code
• Adding a missing requirement
• Removing prohibited content
• Repairing invalid JSON
• Clarifying an assumption
• Reducing excessive confidence
• Reorganizing unclear content

Revision Prompt

Review the draft.
List confirmed errors separately from optional improvements.
Correct all confirmed errors.
Apply optional improvements only when they support the original task.
Check whether each correction creates a new inconsistency.
Perform a final verification.
Return the revised answer.

Error Log Format

Minimal Revision Output

When the user does not need review details:

Generate the answer.
Review it against all requirements.
Correct all confirmed issues.
Do not show the draft or review notes.
Return only the verified final answer.

Transparent Revision Output

When an audit trail is needed:

Provide the initial conclusion.
Provide the verification findings.
Provide the corrected conclusion.
Explain which evidence or test caused each correction.
Clearly separate verified facts from remaining uncertainties.

Avoiding Endless Revision

Repeated review can continue without meaningful improvement. A prompt should define a stop condition.

Perform one complete review pass.
Revise all confirmed issues.
Perform one final verification pass.
Stop when no material errors remain.
Do not make stylistic changes that do not improve correctness or compliance.

Verification Prompt Templates

The following templates can be reused for different tasks.

General Self-Review Template

Complete the requested task.
Review the draft before returning it.
Check instruction compliance.
Check factual consistency.
Check logical consistency.
Check calculations and technical details where applicable.
Check the required output format.
Identify missing information.
Identify unsupported claims.
Correct all confirmed errors.
Return only the verified final answer.

Detailed Verification Template

Read the original request carefully.
Extract every requirement and constraint.
Produce a draft answer.
Check each requirement individually.
Check names, dates, values, versions, and definitions.
Check whether the reasoning supports the conclusion.
Recalculate all numeric results independently.
Review code through edge cases and tests.
Validate the output format.
Mark assumptions and uncertainty.
Remove unsupported claims.
Revise every failed part.
Perform a final verification pass.
Return the corrected answer.

Instruction Compliance Template

Compare the answer with the original instructions.
Create a checklist containing every explicit requirement.
Mark each requirement as Pass or Fail.
Identify any conflicting requirements.
Correct all failed requirements that can be corrected.
Do not claim compliance with an unmet requirement.
Return the revised answer and final checklist.

Factual Verification Template

Review every factual statement.
Compare each claim with the supplied reference information.
Check names, dates, numbers, versions, and definitions.
Identify contradictions.
Identify claims not supported by the reference.
Remove or qualify unsupported claims.
State when information is unavailable.
Return the verified answer.

Logical Consistency Template

Identify the main conclusion.
Identify the facts and assumptions used to support it.
Check whether the conclusion follows from the facts.
Check for contradictions.
Check for circular reasoning.
Check for missing steps.
Check for unsupported cause-and-effect claims.
Consider at least one alternative explanation.
Correct the reasoning.
Return the revised conclusion.

Calculation Verification Template

Extract all numeric inputs.
Confirm the unit of each value.
State the formula.
Substitute the values.
Show important intermediate results.
Check arithmetic and order of operations.
Check percentage bases.
Check unit conversions.
Recalculate using an independent method.
Compare both results.
Return the verified result with correct units and rounding.

Code Verification Template

Review the code against the stated requirements.
Check the programming language and version.
Check syntax and imports.
Check data types and return values.
Check conditions and loop boundaries.
Check null, empty, zero, negative, and maximum inputs.
Check exception handling.
Check resource management.
Check security risks.
Check performance risks.
Generate test cases.
Correct every confirmed issue.
State whether the corrected code was executed or only reviewed.
Return the corrected code and tests.

JSON Verification Template

Generate valid JSON only.
Follow the supplied schema exactly.
Include every required field.
Remove unrequested fields.
Use the correct data type for every value.
Use only allowed enum values.
Check nesting and array structure.
Escape special characters correctly.
Do not include comments.
Do not include Markdown.
Validate the structure before returning it.

Missing-Information Template

Determine whether the provided information is sufficient.
Identify details that materially affect the answer.
Separate critical missing information from optional information.
Do not invent facts.
Ask only the minimum required questions.
State any temporary assumptions clearly.
Do not present a provisional answer as fully verified.

Unsupported-Claim Template

Extract the major claims from the answer.
Classify each claim as fact, inference, opinion, assumption, or prediction.
Identify the evidence supporting each factual claim.
Mark claims that lack sufficient support.
Remove invented evidence.
Replace absolute claims with accurate qualified wording.
State what evidence would be needed for verification.
Return the revised answer.

Confidence-Label Template

Review each major conclusion.
Assign High, Medium, or Low confidence.
Base the label on evidence quality, information completeness, assumptions, and verification method.
Give one short reason for each label.
Do not use numerical confidence without a defined statistical basis.
Mark conclusions requiring external verification.

Independent Verification Template

Verify the answer using a method different from the original method.
Do not rely only on rereading the original explanation.
Recalculate numeric results independently.
Derive code tests directly from the requirements.
Check factual claims against the supplied reference.
Test conclusions against alternative explanations.
Compare the independent result with the original result.
Investigate every disagreement.
Return the corrected verified answer.

Revision Template

Review the draft and identify confirmed errors.
Separate errors from optional style improvements.
Correct every confirmed error.
Preserve correct parts of the original answer.
Check whether any correction creates a new contradiction.
Run the verification checklist again.
Stop when no material errors remain.
Return the final revised answer.

Verify-Then-Answer Template

Analyse the problem.
Produce a candidate answer.
Verify the candidate using the defined criteria.
Revise the candidate when verification fails.
Return only the answer that passes verification.

Answer-with-Audit Template

Provide the final answer.
Provide a short verification summary.
List the checks performed.
List any remaining assumptions.
List any points that require external confirmation.
Do not expose unnecessary hidden reasoning.

Practical Example: Technical Explanation Verification

Task

Explain the difference between concurrency and parallelism.

Verification Prompt

Explain the difference between concurrency and parallelism.
Use simple language.
Include one Java-related example for each concept.
Review the explanation before returning it.
Check that concurrency is not incorrectly described as always running tasks at the same instant.
Check that parallelism requires simultaneous execution.
Check whether the examples match the definitions.
Keep the answer below 400 words.
Return only the verified explanation.

Verification Criteria

• Concurrency means managing multiple tasks during overlapping periods.
• Parallelism means executing multiple tasks at the same time.
• Concurrency can occur on one processor core through task switching.
• Parallelism normally requires multiple processing units.
• The examples must reflect these differences.

Practical Example: SQL Verification

Task

Generate a query that returns the five customers with the highest total order value.

Verification Prompt

Write a MySQL 8 query.
Use customers and orders tables.
Calculate the total order value for each customer.
Include customers with at least one order.
Sort from highest total value to lowest.
Return only five customers.
Review join conditions.
Review grouping.
Review aggregate functions.
Check whether duplicate rows can change the total.
Return the corrected query.

Example Query

SELECT c.customer_id, c.customer_name, SUM(o.order_total) AS total_order_value
FROM customers c
INNER JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.customer_name
ORDER BY total_order_value DESC
LIMIT 5;

Verification Points

• The join connects orders to the correct customer.
• SUM calculates the total order value.
• GROUP BY produces one row per customer.
• ORDER BY uses descending order.
• LIMIT returns five rows.
• INNER JOIN excludes customers without orders.

Practical Example: Java Code Verification

Requirement

Return the largest value from an integer array.

Incorrect Code

public static int findLargest(int[] numbers) {
    int largest = 0;
    for (int number : numbers) {
        if (number > largest) {
            largest = number;
        }
    }
    return largest;
}

The method fails when all values are negative because zero is not part of the array but may still be returned.

Corrected Code

public static int findLargest(int[] numbers) {
    if (numbers == null || numbers.length == 0) {
        throw new IllegalArgumentException("Array must not be null or empty");
    }
    int largest = numbers[0];
    for (int index = 1; index < numbers.length; index++) {
        if (numbers[index] > largest) {
            largest = numbers[index];
        }
    }
    return largest;
}

Verification Tests

Verification Prompt

Verify the method against the requirement.
Check positive values.
Check negative values.
Check duplicate values.
Check a single-value array.
Check an empty array.
Check a null array.
Correct the implementation.
Provide the final method and expected test results.

Practical Example: Content Verification

Task

Write a 500-word beginner article about prompt chaining.

Verification Prompt

Write a beginner-friendly article about prompt chaining.
Keep the article between 450 and 550 words.
Explain sequential, branching, and parallel chains.
Include one practical example.
Avoid advanced mathematical language.
Review the article before returning it.
Check all required chain types.
Check the word range.
Check whether the example matches the explanation.
Remove repeated ideas.
Return only the revised article.

Verification Checklist

• Correct topic
• Beginner-friendly language
• Sequential chain explained
• Branching chain explained
• Parallel chain explained
• Practical example included
• Word range satisfied
• No unnecessary repetition

Practical Example: Structured Data Verification

Task

Return product information as JSON.

Prompt

Return valid JSON only.
Include productName as a string.
Include price as a number.
Include inStock as a Boolean.
Include categories as an array of strings.
Include rating as a number or null.
Do not include additional fields.
Validate every field before returning the JSON.

Expected Structure

{
    "productName": "Wireless Keyboard",
    "price": 1499,
    "inStock": true,
    "categories": [
        "Computer Accessories",
        "Keyboards"
    ],
    "rating": 4.3
}

Verification Checklist

• Valid JSON
• Exactly five fields
• Correct field names
• Correct data types
• Categories contains strings
• Rating is a number or null
• No Markdown around the output

Common Self-Review Mistakes

Using a Vague Review Instruction

Weak:

Check the response.

Better:

Check factual accuracy, logical consistency, required sections, examples, and output format.

Asking for Confidence Without Evidence

Weak:

Give a 99% confidence score.

Better:

Assign High, Medium, or Low confidence based on evidence quality and missing information.

Treating Self-Review as Proof

A model may approve its own incorrect answer. Important claims still require external verification.

Repeating the Same Method

Recalculating with the same steps may repeat the same error. Use a different method or reverse calculation.

Verifying Only Grammar

A grammatically polished answer may still contain false facts or invalid reasoning.

Ignoring the Original Prompt

The review must compare the answer with the original task, not only evaluate the answer by itself.

Correcting Without Rechecking

A correction may create a new contradiction. Perform a final review after revision.

Inventing Evidence

A model must not create fake sources, test results, benchmarks, or execution results to support an answer.

Claiming Code Was Tested When It Was Not Executed

Static review and actual execution are different.

Correct statement:

“The code was reviewed for syntax and logic but was not executed.”

Incorrect statement:

“All tests passed,” when no tests were run.

Overusing Self-Review

Too many review passes may add unnecessary text or change correct content. Define clear criteria and a stop condition.

Best Practices for Self-Review and Verification

• Define verification criteria before generating the answer.
• Convert broad requirements into testable checks.
• Review against the complete original prompt.
• Separate facts, assumptions, opinions, and predictions.
• Use independent verification where possible.
• Verify calculations with tools for important tasks.
• Compile and test generated code.
• Use official references for current technical facts.
• Validate structured data with a parser or schema validator.
• Make missing information visible.
• Avoid unsupported absolute claims.
• Use confidence labels only when they add value.
• Correct errors and then verify the corrections.
• State what was and was not externally verified.
• Stop after the answer passes the defined checks.

Recommended Verification Strategy by Task Type

Complete Verification Workflow Template

Read the complete task.
Extract all requirements.
Identify required facts, constraints, and output format.
Identify missing critical information.
Generate a candidate answer.
Check instruction compliance.
Check factual consistency.
Check logical consistency.
Check calculations.
Check code correctness where applicable.
Check the output structure.
Identify unsupported claims.
Label important uncertainty.
Verify the answer through an independent method.
Correct all confirmed problems.
Perform one final checklist review.
State any remaining limitations.
Return the verified final answer.

Final Verification Checklist

Before accepting an AI-generated answer, check the following:

• Does the answer solve the actual task?
• Does it follow every important instruction?
• Are the facts consistent with the available information?
• Are names, numbers, dates, and versions consistent?
• Does the conclusion follow from the evidence?
• Are assumptions clearly stated?
• Are calculations independently checked?
• Has code been tested or only reviewed?
• Does the output match the required format?
• Is any critical information missing?
• Are any claims unsupported?
• Is uncertainty communicated properly?
• Were detected errors corrected?
• Was the revised answer checked again?
• Is external verification required?

Conclusion

Self-review and answer verification add a quality-control stage to prompt-based work. Instead of accepting the first response, the model checks whether the answer follows instructions, uses consistent facts, applies valid logic, performs correct calculations, produces reliable code, and follows the required format.

The most effective verification prompts are specific. They define exactly what must be checked, what evidence should be used, what failures look like, and how the answer should be revised.

Self-review is helpful, but it is not a guarantee of truth. A model can repeat its own mistakes or approve an incorrect answer. Important calculations should be checked with calculation tools, generated code should be compiled and tested, structured output should be validated, and high-impact factual claims should be compared with trusted sources or reviewed by qualified professionals.

A strong verification process follows this pattern:

1. Generate.
2. Check.
3. Test independently.
4. Correct.
5. Verify again.
6. Return the final answer.

This approach makes AI-generated answers more accurate, transparent, consistent, and useful for real-world work.

Frequently Asked Questions