Verification Report Tampering Detection Prompt

This prompt is built for governance, audit, and verification pipeline operators who need to detect post-hoc modifications to verification reports, evidence chains, or confidence scores that would mask verification failures. The core job is to compare a verification report against its expected structure, evidence provenance, and metadata integrity to surface tamper-evidence indicators and audit-trail completeness gaps. You should use this prompt when you have a generated verification report and access to the original evidence, claim set, or pipeline logs that produced it—and you need to know whether the report was altered after generation, either accidentally through a broken update process or deliberately to hide a failed verification.

The prompt expects a verification report payload, the original claim-to-evidence mappings, and any available pipeline metadata such as timestamps, model versions, or processing logs. It produces structured tamper-evidence indicators: mismatched confidence scores, missing evidence citations that were present in the original output, altered verdict language, timestamp anomalies, and audit-trail gaps where intermediate decisions are unaccounted for. The output is designed to be machine-readable so you can wire it into automated report integrity checks before reports enter compliance dashboards, client deliverables, or regulatory submissions. Do not use this prompt for real-time claim verification, evidence retrieval, or initial report generation—it is a post-hoc integrity check, not a fact-checking engine.

This is a high-risk workflow. A false negative—missing a real tampering event—can propagate incorrect verification results into downstream decisions with legal, financial, or safety consequences. Always pair this prompt's output with human review for any tamper-evidence indicator above a low-severity threshold, and log every integrity check result with the report version, checker model, and timestamp for auditability. Before deploying, run this prompt against a golden dataset of known-clean and known-tampered reports to calibrate your severity thresholds and measure false-positive and false-negative rates. If your verification pipeline already produces cryptographic hashes or digital signatures for report outputs, prefer those over this prompt for integrity verification; use this prompt when you lack such infrastructure or need to detect semantic tampering that wouldn't change a hash, such as reworded verdicts or subtly shifted confidence language.

This prompt template is designed for governance and audit teams who need to programmatically check the integrity of verification outputs. It accepts a verification report, its associated evidence chain, and an audit trail, then produces a structured tamper-evidence assessment. The template uses square-bracket placeholders so you can wire it directly into an application harness, replacing each placeholder with data from your verification pipeline before sending the request to the model.

textCopy
You are an output-integrity auditor for an automated fact-checking system. Your task is to detect post-hoc modifications to a verification report that would mask verification failures, alter confidence scores, or break evidence-chain continuity.

## INPUT

### Verification Report
[VERIFICATION_REPORT]

### Evidence Chain
[EVIDENCE_CHAIN]

### Audit Trail
[AUDIT_TRAIL]

### Expected Verification Schema
[EXPECTED_SCHEMA]

## TASK

1. **Schema Compliance Check**: Compare the verification report against [EXPECTED_SCHEMA]. Flag any missing required fields, unexpected fields, or type mismatches that could indicate field deletion or injection.

2. **Evidence-Chain Continuity**: Trace every claim in the report back to its source in [EVIDENCE_CHAIN]. Flag any claim that lacks a traceable evidence link, any evidence item that was present in the audit trail but omitted from the final report, and any broken reference identifiers.

3. **Confidence Score Anomaly Detection**: Compare confidence scores in the report against the evidence quality indicators in [EVIDENCE_CHAIN]. Flag scores that are inconsistent with the underlying evidence strength, including upward adjustments on weak evidence and downward adjustments on strong evidence.

4. **Audit-Trail Completeness**: Compare the report's stated verification steps against [AUDIT_TRAIL]. Flag any step present in the audit trail but missing from the report, any step in the report with no corresponding audit-trail entry, and any timestamp or sequence anomalies.

5. **Content Modification Detection**: Identify any claim text, evidence summary, or conclusion that appears to have been altered relative to what the evidence chain supports. Look for softened language on failed verifications, removed contradictions, or added qualifiers not grounded in evidence.

## CONSTRAINTS

- Only flag modifications where you can point to specific evidence of tampering. Do not flag normal formatting differences or immaterial wording variations.
- For each flag, provide the specific location (field path, claim ID, or section) and the evidence that supports the tamper finding.
- If the report appears intact, explicitly state that no tamper indicators were found.
- Do not re-verify the underlying claims. Your scope is limited to detecting modifications to the report itself.

## OUTPUT FORMAT

Return a JSON object with this exact structure:

```json
{
  "tamper_detected": boolean,
  "overall_confidence": "high" | "medium" | "low",
  "findings": [
    {
      "finding_id": "string",
      "category": "schema_violation" | "evidence_chain_break" | "confidence_anomaly" | "audit_trail_gap" | "content_modification",
      "severity": "critical" | "high" | "medium" | "low",
      "location": "string (field path, claim ID, or section reference)",
      "description": "string (what was detected)",
      "evidence": "string (specific evidence supporting the finding)",
      "recommended_action": "string (what an auditor should investigate next)"
    }
  ],
  "audit_trail_completeness": {
    "total_expected_steps": number,
    "steps_with_report_coverage": number,
    "steps_missing_from_report": number,
    "report_steps_without_audit_entry": number
  },
  "evidence_chain_summary": {
    "total_claims_in_report": number,
    "claims_with_traceable_evidence": number,
    "claims_with_broken_evidence_link": number,
    "evidence_items_in_chain_but_not_in_report": number
  }
}

RISK LEVEL

[RISK_LEVEL]

If [RISK_LEVEL] is "high", apply stricter detection thresholds: flag even minor schema deviations, require full bidirectional evidence traceability, and treat any confidence score adjustment as critical. If [RISK_LEVEL] is "standard", focus on material modifications that would change verification outcomes.

To adapt this template, replace each placeholder with data from your verification pipeline. [VERIFICATION_REPORT] should contain the full report output from your fact-checking system. [EVIDENCE_CHAIN] must include the structured evidence items with their identifiers, source references, and quality indicators. [AUDIT_TRAIL] should be the step-by-step log of verification actions taken. [EXPECTED_SCHEMA] is your system's canonical output schema—provide it as a JSON Schema or a field-by-field description. [RISK_LEVEL] accepts either "high" or "standard" and controls detection sensitivity. If your system doesn't produce a separate audit trail, remove that section from the prompt and set audit_trail_completeness fields to null in post-processing.

Before deploying this prompt, validate that your evidence chain includes stable identifiers that survive serialization and deserialization. The most common failure mode is broken reference links caused by ID regeneration between pipeline stages. Test with known-good reports first to establish a baseline false-positive rate, then introduce synthetic tampering—removed evidence links, adjusted scores, deleted fields—to confirm detection sensitivity. For high-stakes governance workflows, route all critical severity findings to human review and log every tamper assessment with the full input context for auditability.

This prompt is designed to operate as a post-hoc integrity check within a verification pipeline, not as a real-time guard. It should be invoked after a verification report is generated and before it is archived, published, or submitted to a review board. The harness must treat the prompt's output as a structured audit artifact, not as a final binary pass/fail signal. The primary integration points are: (1) a report storage system that can provide the original report and its current state, (2) an evidence log or chain-of-custody record, and (3) a downstream review queue for flagged reports.

To wire this into an application, build a dedicated tamper-check service that accepts a report_id and retrieves the original report, its version history, and associated evidence metadata. Construct the prompt input by populating [REPORT_CONTENT] with the full report text, [REPORT_METADATA] with timestamps, author IDs, and version numbers, and [EVIDENCE_CHAIN_LOG] with the sequence of evidence operations. After receiving the model response, validate the output schema strictly: confirm that tamper_indicators is an array, each indicator has a non-empty type and severity field, and audit_trail_completeness is a float between 0.0 and 1.0. Reject and retry any response that fails schema validation, logging the failure for prompt debugging. Use a model with strong JSON mode and low temperature (0.0–0.1) to maximize output consistency.

For high-stakes governance workflows, never auto-remediate based on this prompt's output. Route any report with tamper_indicators containing a severity of high or critical directly to a human review queue, attaching the full tamper analysis as context. For medium severity indicators, flag the report for secondary automated checks—such as checksum verification, timestamp consistency validation, or evidence hash comparison—before deciding on human escalation. Log every invocation, including the prompt version, model, input hashes, raw output, and reviewer disposition, to maintain an audit trail of the tamper-detection process itself. Avoid running this prompt on reports that have not yet been finalized, as legitimate in-progress edits will generate false-positive tamper signals and erode trust in the detection workflow.