Audit-Ready Evidence Package Prompt

This prompt is for governance, risk, and compliance (GRC) teams who must prepare a self-contained evidence package for external audit submission. The job is to take a set of verified claims, their supporting evidence, and the verification methodology, and assemble them into a single, structured package that an external auditor can review without access to your internal systems. Use this prompt when the output must include a complete chain of custody, a clear methodology statement, and all evidence artifacts linked to their respective claims. The ideal user is a compliance engineer or audit lead who has already completed upstream fact-checking and now needs to produce a defensible, portable artifact.

Do not use this prompt for real-time fact-checking, initial claim extraction, or evidence retrieval. It assumes those upstream steps are complete and verified. The prompt is designed for high-stakes workflows where missing a single piece of evidence or failing to document provenance can cause an audit finding. It is not a replacement for a verification pipeline; it is the final assembly step that transforms verified structured data into a human-readable, auditor-ready document. If your inputs are still uncertain or your evidence is incomplete, resolve those gaps before invoking this prompt.

Before using this prompt, confirm that you have: (1) a complete list of verified claims with their final verdicts, (2) all supporting evidence artifacts with source identifiers and timestamps, (3) a documented verification methodology, and (4) a clear chain of custody showing who handled each piece of evidence and when. If any of these inputs are missing, the output package will be incomplete and may fail audit scrutiny. The prompt includes built-in validation for package completeness and export-format compliance, but it cannot fabricate missing evidence or guess at provenance. Always pair this prompt with a human review step before submission to an external auditor.

This prompt template is the core instruction set for generating an Audit-Ready Evidence Package. It is designed to be pasted into your orchestration layer, where each square-bracket placeholder is replaced with live data from your verification pipeline before the model call. The template forces the model to produce a structured, self-contained package that an external auditor can review without access to your internal systems. It requires explicit methodology disclosure, evidence-to-claim mapping, and a chain-of-custody summary, moving beyond a simple verdict list to a defensible artifact.

textCopy
You are an audit documentation specialist preparing an evidence package for external regulatory review. Your output must be self-contained, traceable, and suitable for submission without additional context.

Generate an Audit-Ready Evidence Package using the following inputs and constraints.

## INPUT DATA

### Claims and Verification Results
[CLAIMS_AND_VERDICTS]

### Evidence Sources
[EVIDENCE_SOURCES]

### Verification Methodology
[METHODOLOGY_DESCRIPTION]

### Pipeline Execution Metadata
[PIPELINE_METADATA]

## OUTPUT SCHEMA

Produce a single, valid JSON object conforming to this structure:
{
  "package_metadata": {
    "package_id": "string",
    "generation_timestamp": "ISO 8601",
    "pipeline_version": "string",
    "prepared_by": "string",
    "submission_status": "draft | final"
  },
  "methodology_statement": {
    "summary": "string (plain-language description of the verification process)",
    "claim_extraction_method": "string",
    "evidence_retrieval_method": "string",
    "matching_logic": "string",
    "confidence_scoring_approach": "string",
    "limitations": ["string, ..."]
  },
  "evidence_chain_of_custody": {
    "source_ingestion_records": [
      {
        "source_id": "string",
        "ingestion_timestamp": "ISO 8601",
        "source_uri": "string",
        "integrity_hash": "string",
        "accessed_by": "string"
      }
    ],
    "processing_log": [
      {
        "step": "string",
        "timestamp": "ISO 8601",
        "action": "string",
        "actor": "system | human"
      }
    ]
  },
  "verification_records": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verdict": "supported | contradicted | unsupported | not_verifiable",
      "confidence_score": 0.0-1.0,
      "evidence_mapping": [
        {
          "source_id": "string",
          "relevance": "direct | indirect | contextual",
          "relationship": "supports | contradicts | neutral",
          "excerpt": "string (exact quote from source)"
        }
      ],
      "verdict_rationale": "string (explain why the evidence leads to this verdict)",
      "reviewer_notes": "string or null (for human-reviewed claims)"
    }
  ],
  "unsupported_claims_disclosure": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "evidence_search_summary": "string",
      "gap_explanation": "string"
    }
  ],
  "completeness_self_assessment": {
    "total_claims": "integer",
    "verified_claims": "integer",
    "unsupported_claims": "integer",
    "missing_evidence_types": ["string, ..."],
    "compliance_gaps": ["string, ..."]
  }
}

## CONSTRAINTS

- Every claim in [CLAIMS_AND_VERDICTS] must appear in `verification_records` or `unsupported_claims_disclosure`.
- Every evidence source in [EVIDENCE_SOURCES] must appear in `evidence_chain_of_custody.source_ingestion_records`.
- All `source_id` references must match exactly between records.
- The `integrity_hash` field must be populated from [PIPELINE_METADATA]; do not invent hashes.
- If a claim has a verdict of "unsupported," it must also appear in `unsupported_claims_disclosure`.
- Do not include claims or evidence not present in the input data.
- Use the exact methodology text from [METHODOLOGY_DESCRIPTION] in the methodology statement; do not paraphrase or embellish.
- If any required field cannot be populated from the inputs, use `null` and note the gap in `completeness_self_assessment.compliance_gaps`.

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high," add a `legal_review_required` boolean field to `package_metadata` set to `true` and include a `reviewer_signoff` object with `reviewer_name`, `review_timestamp`, and `signoff_status` fields set to `null`.

To adapt this template, start by mapping your pipeline's internal data structures to the [CLAIMS_AND_VERDICTS], [EVIDENCE_SOURCES], [METHODOLOGY_DESCRIPTION], and [PIPELINE_METADATA] placeholders. The [CLAIMS_AND_VERDICTS] input should be a pre-formatted JSON array of claim objects with their AI-generated verdicts and confidence scores. The [EVIDENCE_SOURCES] input must include the integrity hash generated at ingestion time—this is critical for the chain-of-custody section and cannot be fabricated by the model. The [RISK_LEVEL] placeholder accepts "low," "medium," or "high" and controls whether the output includes a legal review flag. Before deploying, validate that the assembled prompt does not exceed your model's context window, especially when processing large batches of claims. For production use, implement a post-generation validation step that checks JSON schema compliance, source_id consistency, and completeness of the unsupported claims disclosure against the input claim set.

The Audit-Ready Evidence Package Prompt is designed to be the final assembly step in a verification pipeline, not a standalone prompt. It expects structured inputs—pre-verified claims, matched evidence records, methodology metadata, and chain-of-custody logs—that upstream prompts or retrieval systems have already produced. Wiring this prompt into an application means building a harness that validates those inputs before the prompt runs, validates the output package after generation, and routes incomplete or low-confidence packages to human review before submission. The harness should treat the prompt as a package assembler, not a fact-checker: it formats, cross-references, and exports, but it does not re-verify claims or re-evaluate evidence.

Start by defining a strict input schema that the harness enforces before calling the model. Required fields include a list of verified claims (each with a unique ID, verdict, confidence score, and evidence references), a methodology record (extraction method, retrieval sources, matching logic, confidence thresholds), and a chain-of-custody log (timestamps, model versions, operator identities for each pipeline step). The harness should reject incomplete inputs with a clear error message rather than letting the model hallucinate missing sections. After the model generates the evidence package, run structural validation first: check that all required sections exist, that claim IDs in the package match the input claim IDs, and that every evidence reference resolves to an input source. Then run content validation: verify that no new claims were introduced, that verdicts were not altered, and that confidence scores match the input values. A checksum or hash of the input claim set stored before generation can detect tampering. For high-assurance audit submissions, implement a dual-generation pattern: run the prompt twice with different model temperatures or across two model providers, compare the structural outputs, and flag discrepancies for human review.

Log every generation attempt with the input hash, model version, output package hash, validation results, and any human review decisions. Store these logs alongside the final package so auditors can trace exactly how the package was produced. If the package fails validation, implement a retry with repair loop: feed the validation errors back into a repair prompt that fixes specific structural issues without regenerating the entire package. Cap retries at three attempts, then escalate to a human operator with the partial package and error log. For export, support both structured JSON (for downstream systems) and a rendered PDF or DOCX format (for human auditors). The prompt's [OUTPUT_SCHEMA] and [EXPORT_FORMAT] placeholders should be populated from configuration, not hardcoded, so the same harness can serve different audit standards. Finally, never run this prompt on unverified claims—the harness should refuse to assemble a package if any input claim has a verification_status of unverified or pending, preventing the illusion of audit-readiness from incomplete work.