Inspiration
AeroProof started with a simple but uncomfortable observation: aviation does not lack data, it lacks trusted, traceable evidence at the moment a decision has to be made. A technician on a ramp, an operations controller during a turnaround, or an engineer reviewing a recurring fault often has telemetry, maintenance manuals, past work orders, and inspection photos spread across systems that do not speak to each other. The result is slower diagnosis, repeated troubleshooting, and unnecessary aircraft-on-ground time.
The PROOF Aviation Futures challenge phrase — “DON’T PITCH THE FUTURE. PROVE IT.” — reframed the problem for us. Instead of building another “AI assistant” that only generates plausible text, we asked: what would it take for an AI maintenance copilot to show its work? That question became the design principle behind AeroProof: every recommendation must be backed by evidence, a confidence estimate, and an audit trail a human can inspect.
We were also inspired by the people who keep aircraft flying: technicians working with fragmented documentation, maintenance organizations under turnaround pressure, and operators who need defensible decisions rather than black-box predictions. The goal was not to replace aviation expertise. It was to make expertise faster to apply and easier to verify.
What it does
AeroProof is an evidence-first AI copilot for aviation maintenance and operations. It helps technicians and engineers move from a symptom to a defensible next action.
Given an aircraft tail number, a fault code, telemetry anomaly, or inspection image, AeroProof:
Builds a maintenance case around the aircraft and symptom.
Retrieves relevant evidence from maintenance manuals, service bulletins, prior work orders, and inspection records.
Generates a diagnosis and recommended inspection steps with citations attached to each material claim.
Shows a calibrated confidence score and flags when evidence is weak or missing.
Creates an audit trail linking the recommendation to the source evidence, model version, and human approval.
Exports a work-order-ready summary or escalates the case to an engineer.
In the prototype, the core screen is a maintenance case dashboard: aircraft status on the left, a diagnosis with recommended steps in the center, and evidence cards with citations and confidence on the right. A technician can accept, reject, or escalate a recommendation, and that decision is logged. The point is not “the AI is always right.” The point is “here is what the AI relied on, how confident it is, and who approved it.”
How we built it
We built AeroProof as a working prototype with a modular architecture: data ingestion, evidence retrieval, anomaly detection, computer vision, an evidence engine, and a technician-facing dashboard.
The data layer ingests maintenance manuals, work orders, fault codes, and telemetry. We normalized documents, chunked them, and stored embeddings in a vector database for retrieval-augmented generation. For telemetry, we used a simple reconstruction-based anomaly score. The prototype stack included Python and FastAPI for the backend, React/Next.js for the dashboard, PostgreSQL with pgvector for evidence storage, OCR for scanned documents, and containerized services for local demo deployment. We used a vision model to extract text and component context from inspection images, and an LLM layer for diagnosis drafting and evidence-grounded summaries. Crucially, the LLM was constrained to produce claims that the evidence engine could validate against retrieved sources.
We also built an audit-trail service that records the case, retrieved evidence, model version, confidence, and human action. That audit trail is the “proof” layer: it makes the recommendation inspectable after the fact.
Challenges we ran into
The hardest challenge was grounding. It is easy to generate a fluent maintenance recommendation; it is much harder to ensure every material claim is supported by a real manual section or work order. We had to separate “drafting” from “evidence validation” and treat unsupported claims as a failure mode, not a formatting issue.
A second challenge was confidence calibration. Early confidence scores were overconfident when retrieval looked semantically similar but was operationally irrelevant. We added authority and recency weighting, evidence coverage checks, and a rule that weak evidence forces escalation. The calibration problem is not just mathematical; it is a product-trust problem.
A third challenge was data fragmentation and sparsity. Aviation maintenance data is often incomplete, inconsistently labeled, and sensitive. We could not assume a clean dataset. We built the prototype to work with a small curated demo corpus and made the evidence chain explicit so reviewers could see what was real and what was simulated.
We also faced latency and usability constraints. Technicians need answers quickly, but evidence retrieval and validation take time. We optimized the retrieval path, cached document embeddings, and designed the UI to show progressive results: a fast summary first, then evidence cards as validation completes.
Finally, we faced the real-world validation gap. A demo is not a pilot. We had to be honest about what we had proven: the software worked, the evidence chain was inspectable, and the workflow was demonstrable. What we had not proven was performance on a live fleet, integration with an MRO system, or regulatory acceptance. That honesty shaped the next-step plan.
Accomplishments that we're proud of
We are proud that AeroProof is evidence-first by design, not as an afterthought. The prototype does not just answer a maintenance question; it shows the evidence cards, citations, confidence, and audit trail behind the answer.
We are also proud of the end-to-end workflow: a fault or symptom enters the system, evidence is retrieved, a recommendation is drafted and validated, a technician can accept or escalate, and the decision is logged. That workflow is demonstrable, which matters for a challenge built around proof.
On the technical side, we are proud of the evidence coverage check and the calibrated confidence display. These are small features with large trust implications. They turn the AI from an oracle into an inspectable assistant.
Most importantly, we are proud that we can answer the PROOF questions directly: what problem we are solving, who experiences it, what we built, how it works, who could use it, and what a real-world test would look like.
What we learned
We learned that in aviation, trust is the product. A technically impressive model is not enough if a technician cannot see why it made a recommendation. Evidence, provenance, and human approval are not compliance decorations; they are core UX.
We learned that retrieval quality is a safety issue. A semantically similar manual section can still be the wrong section for a specific aircraft configuration. Authority, applicability, and recency matter as much as embedding similarity.
We learned that calibration is hard and humbling. Confidence scores are only useful if they are honest. A system that says “low confidence, escalate” is more valuable than one that says “high confidence” without evidence.
We also learned that the demo is not the deployment. Building a prototype forced us to separate what we could prove from what we hoped. That separation made the project stronger and the next steps clearer.
What's next for AeroProof
The next step is to move from demo-ready toward pilot-ready with a real maintenance or operations partner.
Specifically, we want to:
Run a structured pilot with an MRO, airline maintenance team, or aircraft operator using a bounded use case such as recurring fault diagnosis or inspection-evidence retrieval.
Validate against real work orders and measure time-to-diagnosis, evidence coverage, escalation accuracy, and technician trust.
Integrate with an existing maintenance system through a work-order API rather than replacing the system of record.
Strengthen the evidence engine with aircraft configuration applicability, service-bulletin tracking, and document version control.
Harden cybersecurity and access control for sensitive maintenance and operational data.
Recruit aviation expertise — maintenance engineers, quality reviewers, and pilot partners — to challenge the recommendations and calibrate the confidence model.
The long-term pathway is HACK → INCUBATE → DEPLOY
Log in or sign up for Devpost to join the conversation.