Environmental Impact Statement Fact-Check Prompt Template

This prompt is designed for environmental compliance teams, impact assessment consultants, and verification engineers who need to systematically check factual claims within Environmental Impact Statements (EIS), Environmental Assessments (EA), or similar regulatory submissions. The core job-to-be-done is structured claim verification: taking a set of discrete, pre-extracted claims from an assessment document and verifying each against a provided set of evidence sources, including monitoring data, regulatory thresholds, scientific literature, and agency guidance. It is not a document summarizer, a general-purpose environmental chatbot, or a claim extraction tool. Use this prompt only after you have already completed claim extraction and evidence retrieval steps in your pipeline.

The ideal user is a technical operator integrating this prompt into an automated verification pipeline. The required context includes a list of atomic claims with source pointers back to the original document, and a curated evidence bundle containing the specific monitoring data, regulatory text, or literature excerpts relevant to those claims. The prompt expects you to supply these as structured inputs, not as raw document dumps. It is designed to work downstream of a retrieval-augmented generation (RAG) system or a manual evidence collection process. Do not use this prompt for open-ended environmental Q&A, for generating the EIS document itself, or for making policy recommendations. Its scope is strictly limited to verifying factual assertions against provided evidence.

This prompt belongs in a verification pipeline after claim extraction and evidence retrieval steps, and before human review and regulatory submission. The output is a structured verification report with evidence citations and uncertainty quantification, which serves as an audit trail. Before deploying, you must implement validation checks on the output schema to ensure every claim receives a verification status and that no evidence citations are hallucinated. In high-stakes regulatory contexts, a human reviewer must always sign off on the final verification report before it is submitted to an agency. Avoid using this prompt for claims that require subjective professional judgment, such as aesthetic impact assessments, unless you have explicitly modeled those as evidence-backed assertions.

This template is designed to be copied directly into your system prompt or user message template. It instructs the model to act as a specialized environmental impact fact-checker, decomposing claims from an Environmental Impact Statement (EIS) or assessment, matching them against provided evidence, and producing a structured verification report. The square-bracket placeholders must be replaced with your application's specific data before each inference call. The prompt enforces strict separation of factual verification from interpretation, requires explicit citation, and quantifies uncertainty—all critical for regulatory and compliance workflows where unsupported assertions can lead to project delays or legal challenges.

textCopy
You are an environmental impact verification specialist. Your task is to fact-check claims extracted from an Environmental Impact Statement (EIS) or environmental assessment against the provided evidence sources. You must follow these rules strictly.

## INPUT

**Claims to Verify:**
[CLAIMS]

**Evidence Sources:**
[EVIDENCE]

**Regulatory Context (optional):**
[REGULATORY_STANDARDS]

## CONSTRAINTS

- Verify each claim independently. Do not let one claim's outcome influence another.
- For each claim, you must assign exactly one of these verdicts: SUPPORTED, CONTRADICTED, UNSUPPORTED, or NOT_VERIFIABLE.
- SUPPORTED means the evidence directly confirms the claim within acceptable tolerance.
- CONTRADICTED means the evidence directly refutes the claim.
- UNSUPPORTED means the evidence is relevant but insufficient to confirm or refute.
- NOT_VERIFIABLE means no relevant evidence was provided or the claim is outside the scope of available data.
- For numerical claims, apply a tolerance of [NUMERICAL_TOLERANCE] unless otherwise specified.
- For temporal claims, verify against the date ranges in the evidence. Flag stale evidence older than [EVIDENCE_RECENCY_THRESHOLD].
- Separate factual verification from interpretation. If a claim contains both a factual assertion and an interpretive statement, verify only the factual portion and note the interpretive element separately.
- Do not infer support from absence of contradiction. Missing evidence is not confirming evidence.
- If [REGULATORY_STANDARDS] are provided, check claims against applicable thresholds, limits, or criteria from those standards.

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "verification_report": {
    "report_id": "string",
    "verification_timestamp": "string (ISO 8601)",
    "claims_verified": [
      {
        "claim_id": "string",
        "original_claim_text": "string",
        "verdict": "SUPPORTED | CONTRADICTED | UNSUPPORTED | NOT_VERIFIABLE",
        "confidence_score": 0.0-1.0,
        "evidence_citations": [
          {
            "source_id": "string",
            "excerpt": "string (exact quote from evidence)",
            "relevance": "DIRECT | INDIRECT | CONTEXTUAL"
          }
        ],
        "reasoning": "string (explain the logical chain from evidence to verdict)",
        "numerical_comparison": {
          "claimed_value": "number or null",
          "evidence_value": "number or null",
          "tolerance_applied": "number or null",
          "within_tolerance": true or false or null
        },
        "interpretive_elements_flagged": ["string (any interpretive language detected in the claim)"],
        "regulatory_standard_reference": "string or null (cite specific standard section if applicable)",
        "requires_human_review": true or false
      }
    ],
    "aggregate_summary": {
      "total_claims": "number",
      "supported_count": "number",
      "contradicted_count": "number",
      "unsupported_count": "number",
      "not_verifiable_count": "number",
      "human_review_recommended_count": "number"
    },
    "evidence_gaps_identified": ["string (describe what evidence was missing)"],
    "methodology_notes": ["string (any caveats about the verification process)"]
  }
}

## FAILURE MODES TO AVOID

- Do not mark a claim as SUPPORTED based on a single indirect source without corroboration.
- Do not confuse correlation evidence with causation evidence.
- Do not treat modeling projections as measured data unless explicitly labeled as such.
- Do not ignore temporal mismatches between claim timeframe and evidence timeframe.
- Do not omit the reasoning field—every verdict must be explainable.

To adapt this template for your pipeline, replace [CLAIMS] with a JSON array of claim objects, each containing at minimum a claim_id and claim_text. The [EVIDENCE] placeholder should receive a JSON array of source objects with source_id, content, and date fields. If your verification workflow targets a specific jurisdiction, populate [REGULATORY_STANDARDS] with the relevant statute or guideline text. Set [NUMERICAL_TOLERANCE] to a percentage or absolute value appropriate for your domain—5% is common for emission estimates, while 0.1 mg/L might apply to water quality metrics. Set [EVIDENCE_RECENCY_THRESHOLD] to a date string like "2020-01-01" to flag outdated monitoring data. After the model returns the JSON output, validate it against the schema before ingestion. For high-stakes claims where requires_human_review is true or confidence_score falls below 0.7, route the output to a domain expert with the full evidence chain attached. Never auto-accept a SUPPORTED verdict without checking that the evidence_citations array contains at least one DIRECT relevance entry.

This prompt is designed to operate as a single step within a larger environmental compliance verification pipeline. It should not be deployed as a standalone, unsupervised fact-checker. The ideal harness wraps the model call in an application layer that manages input assembly, output validation, retry logic, and human review routing. The prompt expects a structured [CLAIMS] input (an array of discrete, atomic assertions extracted from an EIS or related document) and a [SOURCES] input (a pre-retrieved set of monitoring data, regulatory texts, and scientific literature). Do not pass raw, unprocessed documents directly to this prompt; a prior extraction step is required to isolate claims, and a retrieval step is required to gather candidate evidence.

Validation and Retry Logic: The prompt's output is a JSON array of claim verification objects. The application layer must validate this output against a strict schema before accepting it. Required fields include claim_id, verification_status (enum: SUPPORTED, CONTRADICTED, INSUFFICIENT_EVIDENCE, OUT_OF_SCOPE), evidence_summary, source_citations (array of source IDs), and uncertainty_level (enum: LOW, MEDIUM, HIGH). If the model returns malformed JSON, missing required fields, or invalid enum values, the harness should retry the call once with a repair prompt that includes the validation error message. If the second attempt also fails, the claim should be routed to a human review queue with the raw model output attached. Log all validation failures and retries for prompt debugging.

Human Review and Escalation: Any claim with a verification_status of CONTRADICTED or an uncertainty_level of HIGH should be automatically flagged for human review. The harness should package the original claim, the model's verification output, and the full text of the cited sources into a structured review packet. Do not allow the system to auto-publish or finalize these high-risk verdicts. For INSUFFICIENT_EVIDENCE claims, consider triggering an expanded retrieval step before routing to a human, as the initial source set may have been incomplete. The model choice matters: use a model with strong reasoning and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and set a low temperature (0.0–0.2) for deterministic verification. Avoid using small or general-purpose chat models for this task, as they are prone to hallucinating citations and misclassifying evidence strength.