Cost and Efficiency Metric Verification Prompt

This prompt is for finance, operations, and audit teams who need to verify a specific quantitative efficiency claim—such as cost-per-unit, resource utilization ratios, or allocation percentages—against source data before that claim reaches a board report, regulatory filing, or external stakeholder. The ideal user is an analyst or reviewer who already has a concrete claim in hand (e.g., 'cost per widget dropped 12% after the automation project') and needs a structured, reproducible verification step that flags denominator inconsistencies, period mismatches, hidden cost exclusions, and allocation methodology gaming. This is not a general data analysis prompt; it assumes a specific claim already exists and needs to be proven or disproven against evidence.

Use this prompt when the claim involves a ratio, a per-unit metric, or an efficiency percentage where the numerator and denominator can be independently verified. The prompt is designed to decompose the claim into its arithmetic components, check that the denominator is consistent and appropriate, verify that the time periods for numerator and denominator align, and surface any costs or resources that were excluded from the calculation. It works best when you can provide the original claim text, the source data used to support it, and any known methodology notes. The output is a structured verification result with pass/fail flags, specific discrepancies found, and a confidence assessment—not a freeform summary.

Do not use this prompt for general financial analysis, exploratory data investigation, or generating efficiency metrics from scratch. It is not designed to propose cost-saving measures, benchmark against industry standards, or evaluate strategic decisions. Avoid using it when the claim is purely qualitative (e.g., 'the team is more efficient now') without a specific numerical assertion. If the source data is incomplete, the prompt will flag missing evidence rather than fabricate numbers, but it cannot compensate for fundamentally absent data. For high-stakes external reporting or regulatory submissions, always route the verification output through human review and maintain an audit trail of the evidence used.

This template is designed to be copied directly into your verification harness. It accepts a cost or efficiency claim, supporting data, and optional constraints, then produces a structured verification result. The placeholders let you swap in different data sources, output schemas, and risk tolerances without rewriting the core verification logic. Use this prompt when you need to check whether a reported cost metric holds up against raw operational data, not when you need to generate new cost estimates or forecasts.

textCopy
You are a cost and efficiency metric verification specialist. Your job is to verify a single cost or efficiency claim against provided source data. You do not generate new estimates. You flag unsupported assertions, methodological inconsistencies, and hidden exclusions.

## CLAIM TO VERIFY
[CLAIM]

## SOURCE DATA
[DATA]

## VERIFICATION CONSTRAINTS
- Acceptable tolerance: [TOLERANCE_PERCENT]%
- Required period alignment: [PERIOD_GRANULARITY]
- Denominator definition: [DENOMINATOR_DEFINITION]
- Cost allocation method expected: [ALLOCATION_METHOD]
- Flag if any of these cost categories are missing: [REQUIRED_COST_CATEGORIES]

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "claim_id": "string",
  "verification_result": "supported" | "unsupported" | "partially_supported" | "unverifiable",
  "reported_value": "number or null",
  "calculated_value": "number or null",
  "deviation_percent": "number or null",
  "denominator_match": "consistent" | "inconsistent" | "unverifiable",
  "period_match": "aligned" | "misaligned" | "unverifiable",
  "missing_cost_categories": ["string"],
  "allocation_methodology_issues": ["string"],
  "gaming_indicators": ["string"],
  "evidence_chain": [{"source": "string", "field": "string", "value": "string"}],
  "confidence": "high" | "medium" | "low",
  "requires_human_review": true | false,
  "review_reason": "string or null"
}

## VERIFICATION STEPS
1. Extract the exact claim value, unit, time period, and denominator from [CLAIM].
2. Locate the corresponding raw data in [DATA] that matches the period and denominator definition.
3. Recalculate the metric using [ALLOCATION_METHOD] and [DENOMINATOR_DEFINITION].
4. Compare reported vs calculated values within [TOLERANCE_PERCENT]% tolerance.
5. Check whether [REQUIRED_COST_CATEGORIES] are present in the source data. Flag any missing categories.
6. Inspect for allocation methodology gaming: cost shifting between periods, denominator inflation, exclusion of material cost categories, or inconsistent treatment across comparison periods.
7. Assign confidence based on data completeness, period alignment quality, and methodology transparency.
8. Set requires_human_review to true if confidence is low, deviation exceeds tolerance, or gaming indicators are present.

## RULES
- If the denominator cannot be verified from [DATA], set denominator_match to "unverifiable" and confidence to "low".
- If the time period in the claim does not match available data granularity, set period_match to "misaligned" and explain the mismatch.
- Never assume missing cost categories are zero. Flag them as missing.
- If the claim uses a non-standard allocation method, note it in allocation_methodology_issues even if the numbers match.
- Do not hallucinate data. If [DATA] is insufficient, set verification_result to "unverifiable" and explain what is missing.

To adapt this template, replace each square-bracket placeholder with values from your verification pipeline. For [DATA], pass structured records with fields like cost_line_item, amount, period_start, period_end, allocation_key, and denominator_value. If your data is unstructured, pre-process it through a normalization step before feeding it here. For high-stakes financial verification, set [TOLERANCE_PERCENT] to 0 and route any deviation to human review. For operational efficiency metrics where small rounding differences are expected, a 1-2% tolerance is reasonable. The [REQUIRED_COST_CATEGORIES] list should be maintained as a configuration variable in your application, not hardcoded, so domain experts can update it without touching the prompt.

This prompt is designed to sit inside a verification pipeline, not as a standalone chat interface. The typical integration pattern is: (1) a user or upstream system submits a claim and a structured data payload containing cost records, allocation tables, or efficiency calculations; (2) the application layer normalizes the data into a consistent schema before injecting it into the prompt's [SOURCE_DATA] placeholder; (3) the model returns a structured verification result; (4) the application validates the output against the expected [OUTPUT_SCHEMA] before surfacing it to the user or writing it to an audit log. Because cost verification involves financial numbers, the harness must treat every model output as a draft that requires deterministic post-processing for formula recomputation, not as a final ruling.

The most critical harness component is denominator consistency checking. Before the prompt even runs, your application should extract the claimed cost-per-unit metric, identify the denominator (units produced, hours, transactions, etc.), and verify that the same denominator definition is used consistently across all rows in the provided source data. If the data contains mixed denominators, the harness should either reject the input with a clear error or split the verification into separate sub-requests. Post-response, implement a recalculation validator that independently computes the cost metric from the raw source data using a deterministic formula (e.g., total_cost / denominator) and compares it against both the original claim and the model's verification output. Flag any discrepancy greater than a configurable tolerance (default 0.1%) for human review. Log every verification attempt with: the claim text, the source data hash, the model's raw output, the recalculation result, and the final disposition (verified, flagged, or escalated).

For retry logic, implement a two-stage approach. If the model's output fails JSON schema validation or is missing required fields like denominator_consistency or allocation_methodology_assessment, retry once with the validation errors appended to the prompt as feedback. If the second attempt also fails, escalate to a human reviewer with the full context packet. Do not retry more than twice—cost verification prompts are deterministic enough that persistent format failures indicate a deeper input quality issue. For model choice, use a model with strong numerical reasoning and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that struggle with multi-step arithmetic embedded in natural language. If your pipeline processes high volumes, consider batching claims by cost category and running them through a queue with a dead-letter channel for verification failures. Never auto-approve a cost claim based solely on model output—always require the recalculation validator to pass before marking a claim as verified in any system of record.