Engineering Failure Analysis Claim Verification Prompt Template

This prompt is designed for reliability engineers, failure analysis teams, and incident investigators who need to verify causal claims in post-incident reports. Use it when you have an incident report containing assertions about what caused a failure and you need to check those claims against structured evidence such as telemetry logs, design specifications, material test data, and maintenance records. The prompt separates claims that are directly supported by evidence from those that remain hypotheses, assigns an evidence sufficiency score to each causal claim, and flags contradictions between the report narrative and the source data. This is not a root cause analysis generator. It verifies claims that have already been made, making it suitable for peer review of incident reports, regulatory submission checks, and internal engineering review workflows where traceability from claim to evidence is required.

The ideal user is someone who already has a written incident report and a collection of structured evidence sources. You should not use this prompt to generate root cause hypotheses from raw data, to replace a formal failure mode and effects analysis (FMEA), or to make final determinations about liability or regulatory compliance without human review. The prompt works best when evidence is well-organized and claims are stated explicitly. If the incident report uses vague language like 'the component likely failed due to fatigue,' the prompt will flag this as a hypothesis rather than a verified claim. For high-risk domains such as aerospace, medical devices, or structural engineering, always route outputs through a qualified engineer for final sign-off. The evidence sufficiency scores are decision-support tools, not certifications of correctness.

Before using this prompt, prepare your inputs carefully. Gather the incident report text, any supporting evidence documents, and a clear output schema that defines how you want claims, evidence matches, scores, and contradictions structured. The prompt template uses square-bracket placeholders for [INCIDENT_REPORT], [EVIDENCE_DOCUMENTS], [OUTPUT_SCHEMA], and [CONSTRAINTS]. You can adapt the constraints section to match your organization's evidence standards, such as requiring timestamp correlation within a specific tolerance window or mandating that material test data must come from certified labs. After running the prompt, validate the output against your schema, check for missing claims, and route any claims with low evidence sufficiency scores to a human reviewer. The next section provides the full prompt template you can copy and adapt.

This prompt template is designed for reliability and root cause analysis teams who need to verify causal claims in incident reports. It separates established causes from hypotheses and scores the sufficiency of evidence for each claim. The template uses square-bracket placeholders that you must replace with your specific incident report content, evidence sources, and output requirements before use.

codeCopy
You are an engineering failure analysis verifier. Your task is to examine causal claims in an incident report and verify them against provided evidence sources.

## INPUT

### INCIDENT REPORT
[INCIDENT_REPORT]

### EVIDENCE SOURCES
[EVIDENCE_SOURCES]

### OUTPUT SCHEMA
[OUTPUT_SCHEMA]

### CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS

1. Extract every distinct causal claim from the incident report. A causal claim asserts that a specific factor, event, or condition caused or contributed to the failure.

2. For each causal claim, determine its verification status using only the provided evidence sources:
   - **ESTABLISHED**: The claim is directly supported by evidence in the sources.
   - **HYPOTHESIS**: The claim is plausible but lacks sufficient evidence in the provided sources.
   - **CONTRADICTED**: The claim is contradicted by evidence in the sources.
   - **UNSUPPORTED**: The claim cannot be evaluated because relevant evidence is missing from the sources.

3. For each claim, provide:
   - The exact claim text from the report.
   - The verification status.
   - An evidence sufficiency score from 1 (no evidence) to 5 (conclusive evidence).
   - Specific citations to evidence sources that support or contradict the claim.
   - A brief explanation of the reasoning.

4. If multiple causes are presented as a chain, evaluate each link separately and note dependencies.

5. Flag any claims that rely on assumptions not present in the evidence sources.

6. Do not introduce causal theories not present in the incident report.

7. If [RISK_LEVEL] is "high", include a human-review recommendation for any claim scored below 3.

## OUTPUT FORMAT

Return a JSON object with the following structure:
{
  "claims": [
    {
      "claim_text": "string",
      "verification_status": "ESTABLISHED | HYPOTHESIS | CONTRADICTED | UNSUPPORTED",
      "evidence_sufficiency_score": 1-5,
      "evidence_citations": ["string"],
      "reasoning": "string",
      "dependencies": ["string"] | null,
      "human_review_recommended": true | false
    }
  ],
  "summary": {
    "total_claims": number,
    "established_count": number,
    "hypothesis_count": number,
    "contradicted_count": number,
    "unsupported_count": number,
    "overall_confidence": "HIGH | MEDIUM | LOW"
  }
}

To adapt this template, replace [INCIDENT_REPORT] with the full text of the failure analysis or post-incident review. Replace [EVIDENCE_SOURCES] with clearly labeled source documents such as failure data logs, design specifications, operational records, maintenance histories, and test results. Define [OUTPUT_SCHEMA] if you need additional fields beyond the default structure, such as severity classifications or subsystem tags. Set [CONSTRAINTS] to specify domain-specific rules, such as acceptable tolerance windows for numerical claims or required evidence types for particular failure modes. Set [RISK_LEVEL] to "high" for safety-critical systems where unverified claims require mandatory human review before any downstream action. Always validate the output JSON against your schema before ingesting it into incident management or reliability workflows.

The Engineering Failure Analysis Claim Verification prompt is designed to operate as a structured evidence processor within a larger incident review pipeline, not as a standalone chat interface. The prompt expects a specific set of inputs—an incident report, design specifications, operational logs, and a list of extracted causal claims—and returns a structured JSON output with evidence sufficiency scoring for each claim. To integrate this into an application, you should build a harness that pre-processes these inputs, calls the model, validates the output against a strict schema, and routes low-confidence or contradictory results to a human reliability engineer for final adjudication. The model is acting as an analytical assistant, not an authority; its output is a recommendation for review, not a published root cause determination.

Input Assembly and Pre-processing: Before calling the prompt, your application must assemble the [INCIDENT_REPORT], [DESIGN_SPECS], [OPERATIONAL_LOGS], and [CAUSAL_CLAIMS] placeholders. The [CAUSAL_CLAIMS] list should be pre-extracted from the incident report using a separate claim extraction prompt or a deterministic parser. Each claim must be a single, atomic causal assertion (e.g., 'The O-ring failed due to low-temperature embrittlement'). The [OPERATIONAL_LOGS] should be trimmed to a relevant time window around the incident to stay within context limits. For long design specs, use a retrieval step (RAG) to pull only the sections relevant to the failed component or system. Model choice: Use a model with strong reasoning and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 for deterministic, repeatable analysis. Tool use: If your logs or specs are in a database, provide a tool for the model to query specific parameters (e.g., get_sensor_data(device_id, time_range)) rather than dumping raw logs into the context window. This reduces noise and hallucination risk.

Output Validation and Retry Logic: The prompt template requests a specific JSON output schema with fields like claim_id, evidence_items, sufficiency_score, and established_cause. Your application must validate this output against a strict schema immediately after the model responds. If validation fails (missing fields, wrong types, scores out of range), implement a retry recovery loop: feed the validation error message back to the model along with the original prompt and ask it to correct the output. Limit retries to 2-3 attempts before escalating to a human. Critical validation checks: (1) Every evidence_item must include a source_reference that points to a specific section of the provided documents or a specific log entry timestamp. Reject any evidence that lacks a traceable source. (2) sufficiency_score must be an integer between 1 and 5. (3) The established_cause boolean must be consistent with the score—a score of 4 or 5 should generally map to true, while 1-3 should map to false. Flag inconsistencies for human review. Logging: Log every model input, output, validation result, and retry attempt for auditability. This is critical for safety-sensitive failure analysis where decisions may be reviewed by regulators or in post-incident inquiries.

Human Review Routing and Escalation: Not all claims can or should be auto-verified. Your harness should implement a triage threshold: claims with a sufficiency_score of 3 or below, or claims where the model flags contradictory evidence, must be routed to a human reliability engineer. Package the model's analysis, the relevant source excerpts, and the original claim into a review queue. The human reviewer should be able to confirm, override, or request additional evidence. Their final determination should be logged as the authoritative result. What to avoid: Do not treat the model's output as the final root cause determination in any safety-critical system. Do not skip the evidence-source validation step—models can hallucinate plausible-sounding but non-existent log entries or spec details. Do not run this prompt without a human-in-the-loop gate for high-severity incidents (e.g., incidents involving safety, regulatory impact, or significant financial loss). The prompt is a force multiplier for experienced engineers, not a replacement for engineering judgment.