HEYEJ

HeyEJ is a working prototype of an AI-assisted aircraft maintenance diagnostic platform built on retrieval-augmented generation (RAG). The goal: give technicians answers grounded in actual manufacturer maintenance manuals — not general AI knowledge that can hallucinate part numbers, procedures, or torque specifications — with every diagnostic response carrying a mandatory citation back to its source.

OneChair built the full platform — RAG pipeline, multi-tenant data model, asynchronous manual ingestion path, multi-turn diagnostic workflow, and admin controls — in approximately five hours. A traditional AI development agency would scope a comparable build at 3 to 4 months of senior engineering work. The engagement didn't proceed to full production due to client-side financial constraints, and no manufacturer manuals were ingested into the working system. What the build demonstrates is range: that a complete safety-critical AI architecture can be stood up in a single working day.

• ~5 hours total build time for a working RAG-powered prototype
• 11 screens delivered: full diagnostic workflow, case management, user administration, aircraft configuration
• Mandatory citation architecture — every AI response structurally required to cite source manual content
• Multi-tenant architecture built into the data model from day one
• pgvector semantic search pipeline standing up over a working ingestion path
• Architectural pattern for safety-critical AI, demonstrated end-to-end in a single working session

Aircraft maintenance teams don't spend most of their time wrenching. They spend it searching. Troubleshooting a complex avionics fault or a recurring mechanical issue means manually combing through thousands of pages of manufacturer maintenance manuals, cross-referencing service bulletins, and leaning on the institutional knowledge of senior engineers who may not be on shift when the aircraft is on the ramp.

The cost of that workflow is real:

• Extended aircraft downtime while the right manual section gets located
• Inconsistent diagnoses across shifts and across technicians
• Fragile tribal knowledge that walks out the door when experienced technicians retire

The obvious answer is AI-assisted diagnostics. The obvious problem is that a hallucinating AI in aviation is a non-starter — and almost every off-the-shelf AI tool hallucinates by default. An LLM that invents a part number, misremembers a procedure, or generates a plausible-but-wrong torque value isn't a productivity tool. It's a liability.

The requirements set a deliberately high bar for AI trustworthiness:

• Diagnostics grounded in actual manufacturer manuals, not the model's general training data
• Mandatory citations of source manual sections on every recommendation
• Case-based troubleshooting history that builds organizational knowledge over time
• Multi-turn conversational interface that guides technicians from symptom to diagnosis
• Multi-tenant architecture with isolated data and configuration per organization
• Role-based access control distinguishing technicians, supervisors, and administrators

The citation requirement was non-negotiable. In a safety-critical industry, an AI that cannot show its work is an AI that cannot be trusted. That principle drove the entire architecture.

OneChair built the complete prototype in approximately five hours. The architecture centers on a retrieval-augmented generation (RAG) system designed to ground every AI response in ingested manual content rather than general model knowledge.

Asynchronous manual ingestion

The platform is built to accept manufacturer maintenance manuals — often thousands of pages — and process them in the background through BullMQ job queues so large uploads don't block the interface or the technician's workflow. Documents move through a chunking and embedding pipeline using OpenAI's embedding models, with vectors stored in PostgreSQL via the pgvector extension for semantic similarity search.

Grounded retrieval

When a technician describes a fault, the system performs a semantic search across the available manual library and retrieves the most contextually similar sections. Those sections are passed as grounded context to the language model — meaning the AI's response is anchored to retrieved source material rather than generated from the model's general training data.

Citation enforcement at the architecture level

This is the part most AI implementations get wrong. Citations aren't a post-processing step layered on top of model output; they're a structural requirement of the response format. The prompt structure requires the model to reference specific manual sections, and the rendered response includes traceable links back to original document pages. A technician opens the cited section directly from the diagnostic result and verifies against the source before acting on the recommendation. An AI response without a verifiable citation is, by design, not a valid response in this system.

Guided multi-turn diagnostic workflow

The interface walks technicians through a structured intake: manufacturer selection → aircraft type → affected system → problem description → priority level. Each step narrows the retrieval scope, which improves both accuracy and response relevance. Multi-turn conversation then lets technicians refine the diagnosis — asking follow-up questions, ruling out causes, drilling into subsystems.

Compounding case history

As cases are resolved, their outcomes are logged and indexed. The system is designed to build an organizational case history that supplements manual-based retrieval with real-world precedent from the same fleet and operating environment. Years of accumulated diagnostic experience become an institutional asset rather than an attribute of specific technicians.

Multi-tenant isolation

Each organization's case data, user accounts, and manual library are completely separate at the data layer. Multi-tenant architecture is built in from the schema design, not bolted on after a successful pilot — which is the difference between a platform that scales and one that gets rewritten at the first enterprise contract.

The complete prototype was functional in approximately five hours. Every capability in the original specification was implemented at the architectural level — including the citation requirement that most AI solutions struggle to satisfy cleanly, and that is the single most common blocker for AI deployment in regulated industries.

• ~5 hour build time from specification to working multi-tenant prototype
• 11 screens delivered covering case management, the full diagnostic workflow, user management, aircraft configuration, and admin controls
• Citation enforcement built into the response architecture — the system is structurally incapable of returning a non-cited response
• RAG pipeline with pgvector semantic search ready to operate over ingested content
• Multi-tenant from day one — isolated data, users, and configuration per organization
• Asynchronous manual ingestion via BullMQ — large documents process in the background without blocking the interface

On Scope and Status

The engagement reached prototype completion and did not proceed to full production deployment due to client-side financial constraints. No manufacturer maintenance manuals were ingested into the live system, and the citation enforcement architecture — while structurally guaranteed — has not been validated against a populated content library at scale.

That framing matters, and the case study leads with it deliberately. What the build demonstrates is range, not deployment. A complete safety-critical AI architecture — RAG pipeline, citation enforcement, multi-tenant isolation, async ingestion, role-based access — stood up end-to-end in a single working day, ready to be extended with real content libraries when an engagement supports it. The five-hour figure is striking on its own. It's more important as evidence of a different point: the architectural patterns that make AI safe in regulated contexts can be built into the foundation of a product, not retrofitted as compliance theatre after the fact.

Three ways to put AI in front of a technician — and why only one is deployable in a safety-critical context.

HeyEJ is an aviation case study, but the architectural pattern generalizes directly to every industry where AI adoption has stalled on hallucination risk:

• Pharmaceutical and medical device companies needing AI that cites peer-reviewed sources and regulatory documents — see also our OutcomeRx regulated-industry build
• Legal-tech platforms where AI-generated analysis must cite case law and statute text
• Financial services where compliance and audit teams require every AI recommendation to trace back to a source document
• Defense and aerospace contractors with similar safety-critical and audit requirements to commercial aviation
• Energy and infrastructure operators managing complex equipment fleets with manufacturer-specific documentation

In each of these categories, the obstacle to AI adoption is the same: buyers cannot trust an AI that cannot show its work. The architectural pattern proven in HeyEJ — grounded retrieval, mandatory citations, multi-tenant isolation, asynchronous ingestion — is the answer to that problem, and it ships in days rather than quarters. For a compliance-grade healthcare example of the same principles applied, see WellChild.

For aviation and safety-critical industries. AI diagnostics are only trustworthy when grounded in verified source material. RAG with mandatory citations solves the hallucination problem that blocks AI adoption in safety-critical industries — not by filtering outputs after the fact, but by constraining the model's inputs from the start. The architectural decision is the trust decision.

For regulated industries broadly. The pattern HeyEJ uses isn't aviation-specific. Any industry where AI outputs must be traceable to source documents — pharma, legal, financial services, defense — needs the same architecture. The five-hour build proves the pattern is mature enough to ship at startup speed.

For enterprise teams. Multi-tenant architecture is not an afterthought to bolt on after launch. Building tenant isolation into the data layer from day one means the platform is enterprise-ready immediately, not after a costly mid-life rewrite when the first enterprise contract demands it.

For knowledge management. When experienced technicians, attorneys, clinicians, or engineers retire, their diagnostic patterns no longer have to leave with them. A case history system turns years of troubleshooting experience into an institutional asset that improves every future decision the organization makes.

What is RAG, and why does it matter for safety-critical AI?

RAG stands for retrieval-augmented generation. Instead of asking a language model to answer a question from its general training data, a RAG system first retrieves relevant source documents — in HeyEJ's case, manufacturer maintenance manuals — and passes them as context to the model. The model's response is constrained to that source material, which dramatically reduces hallucination risk. In safety-critical industries, RAG is the architectural pattern that makes AI deployable at all.

How does HeyEJ prevent AI hallucination?

Through three layered controls: (1) semantic retrieval ensures only relevant manual content is passed to the model when a content library is in place, (2) the prompt structure requires the model to ground every response in retrieved content, and (3) the response format requires citations back to source manual sections. The architecture is designed so a response without a verifiable citation is not a valid response. With a populated content library, a technician can verify any recommendation against the original document before acting on it.

Can a real RAG platform be built in 5 hours?

A working RAG prototype with a complete architectural pipeline, yes. The five-hour HeyEJ build delivered the RAG pipeline (chunking, embedding, pgvector semantic search), citation enforcement, multi-turn diagnostic workflow, multi-tenant data isolation, role-based access control, and asynchronous manual ingestion as an end-to-end system. The engagement didn't proceed to content ingestion or production deployment due to client-side financial constraints, but the architecture stood up in a single working session. The constraint isn't the technology — pgvector, OpenAI embeddings, and BullMQ are mature, well-understood components. The constraint is the architectural clarity going in.

Does this pattern work outside aviation?

Yes. The same architectural pattern applies directly to pharmaceuticals, legal-tech, financial services compliance, defense and aerospace contractors, and any industry where AI outputs must be traceable to authoritative source documents. The aviation context is the proof of concept; the pattern is general.

What tech stack powers HeyEJ?

Next.js 15 on the frontend, NestJS on the API layer, PostgreSQL with the pgvector extension for semantic search, OpenAI for embeddings and language generation, and BullMQ for asynchronous job processing. Modern, production-proven components — the speed came from the architectural pattern, not from exotic tooling.

Is OneChair available to build a RAG-powered platform for a regulated industry?

Yes. OneChair partners with teams in aviation, pharmaceuticals, legal-tech, financial services, and other regulated industries where AI adoption requires source-grounded outputs and audit-ready architecture. Book a scope call.