Risk Metric and Model Output Verification Prompt

This prompt is designed for risk, compliance, and model validation teams who need to verify quantitative risk metrics and model outputs against source data, methodology documentation, and regulatory expectations. Use it when you have a specific risk claim—such as a reported VaR figure, an expected shortfall estimate, or a probability of default score—and the underlying data, model documentation, or backtesting results to check it against. The prompt forces structured reasoning about model assumptions, data quality, tail risk, and backtesting performance rather than producing a simple pass/fail answer. It is appropriate for second-line validation, audit evidence preparation, and pre-committee review of risk numbers.

This is not a prompt for generating risk metrics from raw data; it verifies claims that have already been produced by a model or analyst. You should avoid using this prompt when you lack access to the underlying methodology documentation, input data samples, or backtesting results—without these, the verification output will be speculative rather than evidence-based. The prompt assumes you can provide the claim itself, the model type and assumptions, a description of the input data, and any available validation or backtesting evidence. If you only have the final risk number with no supporting context, start by gathering that documentation before invoking this verification workflow.

Before using this prompt, confirm that the risk claim is stated precisely with its time horizon, confidence level, and methodology. Vague claims like 'the portfolio is low risk' cannot be verified with this prompt; you need specific, falsifiable assertions such as 'the 1-day 99% historical simulation VaR is $2.3M as of Q3 close.' The prompt works best when you can provide structured inputs including the claim statement, model documentation excerpts, data quality notes, and backtesting summary statistics. If your workflow involves multiple risk metrics or a full model validation report, run this prompt once per claim to maintain verification granularity and audit trail clarity. For production deployments, always route outputs through a human reviewer when the verification flags model assumption violations, data quality issues, or backtesting failures that could affect regulatory capital or risk limits.

This prompt template is designed to verify a single risk metric or model output claim against provided source data, model documentation, and specified constraints. It forces the model to act as a verification analyst, not a risk modeler. The prompt requires the model to check calculation methodology, input data quality, assumption validity, and backtesting alignment before returning a structured verification result. Use this template when you have a specific quantitative claim from a risk report, model output, or compliance filing that must be validated against evidence.

textCopy
You are a risk model verification analyst. Your task is to verify a single risk metric or model output claim against provided evidence. You must not generate new risk calculations or substitute missing data. If evidence is insufficient, you must flag the claim as unverified rather than guessing.

## CLAIM TO VERIFY
[CLAIM]

## SOURCE DATA
[DATA]

## MODEL DOCUMENTATION
[MODEL_DOCS]

## VERIFICATION CONSTRAINTS
- Tolerance window for numerical comparison: [TOLERANCE]
- Required confidence level for verification: [CONFIDENCE_LEVEL]
- Regulatory framework to check against: [REGULATORY_FRAMEWORK]
- Time period alignment requirement: [TIME_PERIOD]

## VERIFICATION STEPS
1. Extract the precise quantitative claim, including units, time period, and confidence level if stated.
2. Identify the calculation methodology implied by the claim (e.g., historical simulation VaR, parametric ES, through-the-cycle PD).
3. Check input data completeness, freshness, and alignment with the claim's time period.
4. Verify the calculation by reproducing it from the source data using the stated or implied methodology.
5. Compare the reproduced value against the claimed value using the specified tolerance window.
6. Check model assumptions stated in the documentation against the data characteristics (e.g., normality, stationarity, independence).
7. If backtesting results are provided, check whether the claim is consistent with backtesting outcomes.
8. Flag any assumption violations, data gaps, or methodology deviations.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "claim_summary": "string summarizing the claim",
  "verification_status": "VERIFIED | UNVERIFIED | CONTRADICTED | PARTIALLY_VERIFIED",
  "reproduced_value": number or null,
  "claimed_value": number or null,
  "deviation": number or null,
  "within_tolerance": boolean,
  "methodology_check": {
    "methodology_identified": "string",
    "methodology_applied_correctly": boolean or null,
    "methodology_notes": "string"
  },
  "data_quality_check": {
    "data_complete": boolean,
    "data_fresh": boolean,
    "data_aligned_with_period": boolean,
    "data_issues": ["string"]
  },
  "assumption_check": {
    "assumptions_stated": ["string"],
    "assumptions_violated": ["string"],
    "assumption_notes": "string"
  },
  "backtesting_alignment": {
    "backtesting_provided": boolean,
    "claim_consistent_with_backtest": boolean or null,
    "backtesting_notes": "string"
  },
  "regulatory_alignment": {
    "framework_checked": "string",
    "regulatory_concerns": ["string"]
  },
  "evidence_gaps": ["string"],
  "overall_confidence": "HIGH | MEDIUM | LOW",
  "recommendation": "string summarizing next steps or required remediation"
}

## CRITICAL RULES
- If source data is missing fields needed for verification, set verification_status to UNVERIFIED and list missing fields in evidence_gaps.
- If the claim involves tail risk (VaR, ES), explicitly check for tail risk underestimation due to assumption violations.
- If model assumptions are violated, downgrade overall_confidence and explain why in assumption_notes.
- Do not invent data, assumptions, or methodology details not present in the provided inputs.
- If the tolerance window is not specified, default to ±5% for value comparisons and flag this default in your output.

After pasting this template, replace each square-bracket placeholder with concrete values before execution. The [CLAIM] should be a single, atomic quantitative assertion (e.g., 'One-day 99% VaR is $2.3M as of 2024-12-31'). The [DATA] placeholder should contain the raw data needed to reproduce the calculation, not summaries. For [MODEL_DOCS], include the relevant sections of model documentation that describe methodology, assumptions, and limitations. Set [TOLERANCE] based on your organization's materiality thresholds—tighter for regulatory reporting, wider for exploratory analysis. If backtesting results are not available, the prompt will handle this gracefully by marking backtesting_provided as false. Always route HIGH or MEDIUM confidence results with regulatory concerns to human review before using them in compliance filings.

This prompt is not a standalone chat interaction. It is a verification node inside a risk governance pipeline. The harness must enforce that every model output claim—VaR, expected shortfall, probability of default, stress test coverage—is checked against a known source of truth before it reaches a report, dashboard, or regulator. Wire the prompt so that it receives structured inputs (model metadata, backtesting results, stress test scenarios, input data quality flags) and returns a structured verification record, never free text alone. The application layer owns data retrieval, unit normalization, and tolerance window configuration; the prompt owns the reasoning about whether the claim holds within those tolerances.

Validation and retry logic. Parse the model's JSON output immediately. Validate that every required field is present, that claim_verdict is one of the allowed enum values (SUPPORTED, UNSUPPORTED, PARTIALLY_SUPPORTED, INCONCLUSIVE), and that any tolerance_violation entries include both the expected and actual values with units. If validation fails, retry once with the validation error injected into the prompt as additional [CONSTRAINTS] context. If the second attempt also fails, escalate to a human review queue with the raw output and validation errors attached. Do not silently accept malformed verification records.

Human review gates. For any claim where claim_verdict is UNSUPPORTED or INCONCLUSIVE, or where risk_level is HIGH, route the verification record to a human reviewer before the claim is used downstream. Package the review packet with: the original claim, the model's verification output, the source evidence snippets, and a pre-filled review form that asks the reviewer to confirm or override the verdict. Log every review decision for audit. For tail risk claims (VaR at 99%+, expected shortfall, stress test breach flags), consider requiring human review regardless of the model's confidence, given the asymmetric cost of underestimation.

Model choice and temperature. Use a model with strong reasoning capabilities and low temperature (0.0–0.1) for this verification task. The prompt requires precise numerical comparison, assumption checking, and methodological reasoning—not creative generation. If your deployment supports it, run the same verification with two different model families and compare verdicts; disagreement on high-severity claims should trigger human review. Cache verification results keyed by claim hash plus evidence version to avoid re-verifying identical claims across pipeline runs.

Logging and observability. Log every verification attempt with: prompt version, model identifier, input claim, evidence sources, raw output, parsed verdict, validation status, retry count, and reviewer decision if escalated. These logs become your audit trail when a risk metric claim is later challenged. Include the full prompt payload in logs so you can reproduce any verification result. Set up monitoring alerts on verification failure rate spikes, which often indicate upstream data quality issues or model behavior drift rather than prompt problems.

What to avoid. Do not use this prompt as a real-time risk calculator. It verifies claims that have already been computed by a risk engine; it does not compute VaR or expected shortfall itself. Do not skip the tolerance window configuration—numerical verification without explicit tolerances produces false negatives from floating-point differences. Do not treat the model's verdict as a final risk decision; the harness must enforce that verification outputs inform human judgment or downstream system gates, not replace them.