# Accident Investigation Prover MCP > The Accident Investigation Prover enforces NTSB/ICAO Annex 13 rigor to validate complex aviation incident reports. It moves beyond simple conclusions like 'pilot error' by correlating FDR parameters, CVR transcripts, maintenance logs, and organizational pressures to trace systemic root causes. ## Overview - **Category:** safety-compliance - **Price:** Free - **Tags:** aviation, accident-investigation, icao, ntsb, hfacs, reason-model, safety, cvr, fdr, root-cause, prover ## Description Writing an accident report used to mean assembling a bunch of data points—a transcript here, a log entry there—and hoping your final conclusion sounded authoritative enough. But most LLMs just write narrative; they don't force the mechanics of true investigation. This MCP changes that. It makes sure every single finding is backed by physical evidence and structured according to global safety standards (like HFACS taxonomy). You feed it messy data, and it demands a multi-causal analysis: what was the probable cause, and what were the contributing factors? We're talking about tracing issues back through organizational decisions—scheduling pressure or training budget cuts—not just blaming the person in the cockpit. Because of its deep focus on aviation forensics, this MCP is available within Vinkius, making it one of the most specialized safety compliance tools you’ll find. ## Tools ### validate_accident_investigation Processes raw investigation data (FDR/CVR/logs) to construct a multi-causal analysis, classifying errors using HFACS and identifying organizational systemic failures. ## Prompt Examples **Prompt:** ``` Investigate: A B737-800 crashed 2nm short of runway during ILS approach in IMC. FDR shows airspeed decreased from 145kt to 108kt over 22 seconds with no crew action until stick shaker. CVR shows no speed callout from PM. PIC had been on duty 11.5 hours. Autothrottle deferred (MEL C) for 5 days. No unreliable airspeed training in 24 months. National authority had not audited the operator in 28 months. ``` **Response:** ``` Multi-causal analysis: probable cause — loss of airspeed awareness (Level 1) due to autothrottle deferral (Level 2/maintenance), fatigue at 11.5h FDP (Level 2/precondition), inadequate CRM monitoring (Level 3/supervision), 24-month training gap (Level 4/organizational), 28-month audit gap (Level 4/regulatory). HFACS traversal reaches Level 4. 'Pilot error' rejected as root cause. ``` **Prompt:** ``` Investigate: ATR 42-500 impacted terrain at 4,800ft during non-precision approach to a mountain airport at night. MDA was 4,200ft. FDR shows descent below MDA without missed approach. CVR: PIC said 'I have the runway' at 4,500ft — airport was 8nm away. GPWS 'TERRAIN' warning 4 seconds before impact. FO on first flight to this airport. No special airport qualification program. ``` **Response:** ``` CFIT — Controlled Flight Into Terrain. Multi-causal: visual illusion below MDA (Level 1), inadequate crew pairing for high-risk airport (Level 3), absent special airport qualification program (Level 4). GPWS response time insufficient (4s). Investigation must reach Level 4 organizational factors. ``` **Prompt:** ``` Investigate: A320 uncontained engine failure on takeoff at V1+5. LP turbine disk separated. Replacement part from third-party supplier, installed 340 flight hours ago. Traceability gap between OEM and supplier. Operator used this supplier 18 months — 23% cheaper than OEM. National authority had approved the supplier. ``` **Response:** ``` Organizational factors dominant: cost-driven supplier selection (Level 4), traceability gap in part documentation (Level 3/supervision), inadequate authority oversight of third-party suppliers (Level 4/regulatory). Recommendations must address: supplier audit frequency, traceability chain verification, OEM vs third-party risk assessment framework. ``` ## Capabilities ### Correlate Physical Evidence It cross-references disparate data sources like FDR parameters, CVR transcripts, and maintenance logs to build a single factual evidence chain. ### Establish Causal Chain It structures the probable cause by identifying contributing factors using established models like Reason's Model and applying 5-Whys analysis for systemic root causes. ### Classify Human Factors It forces classification of all human errors into four distinct levels, ensuring no factor is dismissed as merely 'human error'. ### Analyze Systemic Failures It mandates the review of organizational pressures, including training budgets, regulatory gaps, and maintenance economics. ### Draft Actionable Recommendations It generates recommendations that are specific, measurable, addressed to a named authority, and tied directly to an identified finding. ## Use Cases ### Investigating a Flight Data Recorder Anomaly A safety analyst needs to know why a flight deviated unexpectedly. They feed the MCP the FDR parameters, ATC clearances, and weather reports. The agent responds by pinpointing if the cause was physical (e.g., component failure) or systemic (e.g., outdated radar mapping procedures). ### Reviewing a High-Fatigue Crew Incident The operations manager inputs crew duty logs, flight hours, and incident details. The MCP validates the report, rejecting simple blame and instead highlighting the combination of fatigue (Level 2 precondition) combined with inadequate operational supervision (Level 3 failure). ### Auditing Third-Party Parts Usage The maintenance chief feeds in records showing a component was sourced from an unapproved vendor. The MCP forces the analysis to look beyond just the part's failure, demanding that the report address regulatory oversight gaps (Level 4 organizational risk). ### Analyzing Adverse Weather Operations An accident happened during poor visibility approaches. Instead of stopping at 'pilot error,' the MCP correlates CVR statements with radar data and maintenance logs to determine if insufficient specialized training or outdated procedures contributed to the risk. ## Benefits - You move past vague conclusions. Instead of just saying 'pilot error,' the output forces a multi-causal analysis, showing how latent conditions and active failures interacted. - Every recommendation written is actionable. It demands specificity: who fixes it, what action they take, and by when—no more 'improve training' fluff. - It systematically maps errors across four levels (HFACS), ensuring you don't miss critical organizational factors like resource constraints or climate issues. - The MCP requires cross-referencing physical evidence. It demands that conclusions link back to specific FDR parameters, CVR timestamps, and maintenance records. - You can analyze the whole chain, not just the last step. The tool forces consideration of organizational decisions made months before an accident even happens. ## How It Works The bottom line is you get a structurally rigorous investigation report that withstands deep technical scrutiny. 1. Provide the agent with all available investigative data: CVR transcripts, FDR parameters, ATC recordings, maintenance logs, and wreckage analysis. 2. The MCP processes this evidence by building a multi-causal chain, applying HFACS taxonomy to classify errors across four levels, and identifying systemic organizational gaps. 3. You receive an analysis that rejects simple blame, presenting probable causes linked to latent conditions and actionable recommendations for prevention. ## Frequently Asked Questions **Does Accident Investigation Prover MCP require raw sensor data?** Yes, it must correlate evidence like FDR parameters and CVR transcripts to validate any conclusion. Without these raw inputs, the tool won't proceed past initial checks. **How does validate_accident_investigation differ from a standard LLM analysis?** A standard model writes narratives; this MCP forces adherence to NTSB/ICAO methodology. It demands classification via HFACS and requires mapping contributions back through organizational factors. **Can the Accident Investigation Prover handle non-aviation equipment failures?** While designed for aviation, its framework—analyzing evidence chains, causal links, and systemic failure across four levels—can be adapted to other high-stakes technical fields. **What is the output structure of validate_accident_investigation?** The output provides a structured analysis that includes probable causes, contributing factors (NTSB format), and actionable recommendations linked directly back to specific evidence sources. **How do I connect my AI client for the validate_accident_investigation tool?** You simply connect via your preferred MCP-compatible client through Vinkius. The platform manages all authentication and authorization, so you don't need to worry about API keys or complex setup steps. **What happens if I provide incomplete data when calling validate_accident_investigation?** The tool is built to handle gaps. If the input lacks key evidence, it won't give a conclusion; instead, it generates a report detailing the structural deficiencies and missing links in your investigation. **Does calling validate_accident_investigation impact my data privacy or store incident reports?** No. We don't store your proprietary incident data. The MCP processes the information solely for generating the analysis, and all inputs remain confidential to you. **Are there any rate limits when running validate_accident_investigation on multiple cases?** Vinkius handles scaling for high volume usage. While standard use is robust, extremely high-frequency requests can be managed through our enterprise tier options. **How does this prevent 'pilot error' as a root cause conclusion?** The engine maintains a semantic trap list of blame-language signals: 'pilot error,' 'crew error,' 'human error,' 'judgment error,' 'failed to,' 'negligence.' If the LLM uses any of these in the HFACS taxonomy field, the classification is rejected. Instead, the LLM must classify each factor at the correct HFACS level: Level 1 (what the pilot did — skill error, decision error, perceptual error, or violation), Level 2 (what conditions enabled it — fatigue, CRM failure, environment), Level 3 (what supervision allowed it — scheduling, training gaps), Level 4 (what organizational decisions created it — budget cuts, staffing, regulatory gaps). 'Pilot error' is Level 1 only — the investigation must reach Level 4. **What evidence sources must be cross-referenced?** Five mandatory sources: (1) Flight Data Recorder — minimum 88 parameters per ICAO Annex 6, with timestamps. (2) Cockpit Voice Recorder — last 2 hours of audio, transcribed with timestamps, correlated with FDR parameter changes. (3) ATC recordings — radar track, clearances, handoffs, weather advisories. (4) Maintenance logs — last A/B/C/D checks, MEL items, deferred defects, AD compliance, component life (TSN/TSO/CSN/CSO). (5) Wreckage analysis — impact signatures, fire patterns, fracture analysis (fatigue vs overload), metallurgical examination. The engine rejects speculative language like 'it appears that' or 'evidence suggests' when hard data from these sources exists. **Why does this require recommendations to be addressed to specific authorities?** Because 'improve training' with no addressee has zero accountability. The NTSB model requires each recommendation to name the authority responsible for implementation — the FAA, the operator, the manufacturer, or an international body. Each recommendation must include: what specific action to take, measurable success criteria, a response deadline (typically 90 days), a verification mechanism (audit, inspection, data review), and a direct link to a specific investigation finding. This is how aviation achieved its extraordinary safety record — not through vague wishes, but through tracked, accountable, evidence-linked changes.