Step-by-Step Reasoning Verification Against Reference Prompt Template

This prompt is designed for evaluation engineers and AI platform teams who need to verify that a model's reasoning process is logically sound, not just that the final answer matches a reference. It is built for reasoning-heavy tasks such as mathematical problem solving, multi-step code debugging, legal analysis, and scientific inference where a correct final answer can mask flawed intermediate logic. Use this prompt when you have a reference solution with explicit reasoning steps and you need an LLM judge to perform step-level alignment, flag logical gaps, and produce a structured verification report.

The prompt is not appropriate for grading creative writing, summarization quality, or tasks where multiple valid reasoning paths exist without a single authoritative reference. If your evaluation only needs to check whether the final answer matches a golden answer, use a simpler reference-guided comparison prompt instead. This prompt adds overhead—step alignment, gap detection, and justification generation—that is wasted when the reasoning path is irrelevant to the quality judgment. Reserve it for domains where incorrect intermediate logic is a failure even if the conclusion happens to be correct, such as regulatory compliance analysis, medical differential diagnosis, or safety-critical engineering calculations.

Before deploying this prompt, ensure you have a reference solution that includes explicit, enumerated reasoning steps. The prompt performs best when the reference breaks the problem into discrete logical units that can be aligned one-to-one with the model's output. If your reference is a single paragraph of prose without clear step boundaries, the alignment quality will degrade. Consider preprocessing your reference into numbered steps or using a separate decomposition prompt to extract steps before running this verification. For production pipelines, pair this prompt with a regression test harness that tracks step-level agreement rates over time and flags sudden drops that may indicate model behavior drift.

This prompt template is designed for evaluating reasoning-heavy model outputs where the path to the answer matters as much as the final result. Unlike simple answer-comparison prompts, this template instructs the judge model to decompose both the candidate output and the reference solution into discrete reasoning steps, then perform a step-level alignment and verification. Use this when you need to catch logical errors, skipped steps, or flawed intermediate conclusions that happen to land on the correct final answer. The template is model-agnostic and works with any LLM capable of structured, multi-step analysis.

Below is the copy-ready prompt template. Replace every square-bracket placeholder with your actual data before sending it to the model. The placeholders are designed to be self-contained: you should be able to fill them in without reading the rest of this playbook, though the surrounding sections explain how to wire this into a production evaluation harness.

textCopy
You are an expert reasoning evaluator. Your job is to compare a candidate model's step-by-step reasoning against a reference solution and determine whether the reasoning is logically valid, complete, and aligned with the reference.

## INPUT

**Question or Problem Statement:**
[QUESTION]

**Candidate Reasoning and Answer:**
[CANDIDATE_OUTPUT]

**Reference Solution:**
[REFERENCE_SOLUTION]

## INSTRUCTIONS

1. Decompose the reference solution into a numbered sequence of discrete reasoning steps. Each step should represent one logical inference, calculation, or conclusion.

2. Decompose the candidate's reasoning into a numbered sequence of discrete reasoning steps using the same granularity.

3. For each reference step, identify the corresponding candidate step(s) that address the same logical move. Note if any reference step has no corresponding candidate step.

4. For each aligned pair, evaluate whether the candidate step is:
   - **CORRECT**: Logically equivalent to the reference step and free of errors.
   - **EQUIVALENT**: Different wording or approach but reaches the same intermediate conclusion.
   - **PARTIALLY_CORRECT**: Right direction but missing nuance, precision, or completeness.
   - **INCORRECT**: Contains a logical error, false statement, or invalid inference.
   - **MISSING**: The candidate does not address this step at all.

5. Identify any candidate steps that do not correspond to any reference step. Classify each as:
   - **EXTRA_VALID**: Additional valid reasoning not in the reference.
   - **EXTRA_IRRELEVANT**: Unrelated or unnecessary reasoning.
   - **EXTRA_ERRONEOUS**: Additional reasoning that contains errors.

6. Check whether the candidate's final answer matches the reference's final answer.

## OUTPUT FORMAT

Return a JSON object with this exact structure:

```json
{
  "reference_step_count": <integer>,
  "candidate_step_count": <integer>,
  "step_alignments": [
    {
      "reference_step_index": <integer>,
      "reference_step_summary": "<brief description of the reference step>",
      "candidate_step_indices": [<integers>],
      "alignment_judgment": "CORRECT" | "EQUIVALENT" | "PARTIALLY_CORRECT" | "INCORRECT" | "MISSING",
      "explanation": "<detailed explanation of the judgment>"
    }
  ],
  "unaligned_candidate_steps": [
    {
      "candidate_step_index": <integer>,
      "candidate_step_summary": "<brief description>",
      "classification": "EXTRA_VALID" | "EXTRA_IRRELEVANT" | "EXTRA_ERRONEOUS",
      "explanation": "<detailed explanation>"
    }
  ],
  "final_answer_match": true | false,
  "overall_assessment": {
    "reasoning_score": <float between 0.0 and 1.0>,
    "critical_errors": ["<description of any critical logical errors>"],
    "summary": "<narrative summary of reasoning quality>"
  }
}

CONSTRAINTS

• Do not judge the reference solution itself. Assume it is correct.
• Focus on logical validity, not writing style or verbosity.
• If the candidate reaches the correct final answer through flawed reasoning, the reasoning score must reflect the errors.
• If the candidate uses a different but valid approach, classify steps as EQUIVALENT rather than INCORRECT.
• Be precise in your explanations. Vague judgments are not useful.
• [ADDITIONAL_CONSTRAINTS]

To adapt this template for your own use, start by replacing [QUESTION] with the original problem or prompt that both the candidate model and the reference solution were responding to. Replace [CANDIDATE_OUTPUT] with the full text of the model output you're evaluating—include both the reasoning trace and the final answer. Replace [REFERENCE_SOLUTION] with your known-correct solution, which should include step-by-step reasoning, not just the final answer. The [ADDITIONAL_CONSTRAINTS] placeholder lets you add domain-specific rules, such as tolerance thresholds for numerical answers, required intermediate outputs, or forbidden reasoning patterns. If you don't need additional constraints, remove that line entirely rather than leaving the placeholder. The output schema is designed to be parseable by downstream evaluation infrastructure; do not modify the JSON structure unless you also update your parsing and aggregation code. For high-stakes domains where reasoning errors carry significant risk, always route outputs scoring below 0.8 to human review before accepting the evaluation.

This prompt is designed to be called programmatically as part of an automated evaluation pipeline, not as a one-off manual check. The typical harness wraps the prompt in an API call that sends both the model's reasoning trace and the reference solution, then parses the structured JSON output for downstream scoring. Because the prompt performs a step-level comparison, the harness must ensure that the reasoning trace is already extracted and formatted before this prompt runs—this is not the prompt that generates the reasoning; it is the prompt that verifies it against a known-correct reference. The harness should treat this as a synchronous evaluation step that runs after the primary model generates its answer and chain-of-thought, but before the final score is recorded in your evaluation database.

The implementation should include a validation layer that checks the JSON output against the expected schema before accepting the result. The prompt's output schema includes fields like step_comparisons (an array of objects with step_number, reference_step, model_step, match_type, and explanation), overall_alignment_score, and critical_errors (a list of step numbers where the model's logic diverges fatally from the reference). Your harness should validate that match_type is one of the allowed enum values (exact_match, logical_equivalent, missing_step, extra_step, contradiction, order_mismatch), that overall_alignment_score is a float between 0.0 and 1.0, and that critical_errors contains valid step references. If validation fails, implement a retry loop with a maximum of two additional attempts, appending the validation error message to the prompt context so the model can self-correct. Log every validation failure and retry attempt for observability. For high-stakes domains like healthcare or finance, add a human review gate that triggers when overall_alignment_score falls below 0.7 or when critical_errors is non-empty, routing the case to a review queue before the evaluation result is committed.

Model choice matters for this prompt. Use a model with strong reasoning capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate defaults. Avoid smaller or faster models that may struggle with the fine-grained step comparison task, as false negatives in match_type classification can undermine trust in your evaluation pipeline. Set temperature=0 to maximize determinism, and use a sufficiently high max_tokens value (at least 4096) to accommodate detailed step-by-step comparisons. The harness should also track latency and token usage per evaluation call, as this prompt can become expensive when run across large test suites. Consider batching evaluations where possible, but avoid parallel calls that exceed your rate limits—step verification is a sequential dependency in most evaluation DAGs. Finally, store the full prompt input, raw model output, validated JSON, and any human review decisions in your evaluation database so that every score is auditable and reproducible.