The Investigation Methods Most Tools Document, eAviora Computes

Ask most aviation safety tools whether they “support HFACS” and the honest answer is: they support a HFACS document. You get a blank PDF template, or a styled form with four headings, and you fill it in by hand. The method is on the page; the analysis is still entirely manual, and it lives off to the side of the occurrence record rather than inside it.

That is documenting a method. It is better than nothing, but it leaves the hardest parts, structuring the factors, keeping them consistent across investigations, connecting them to the controls that failed, on the investigator's shoulders, in a file the rest of the system never reads.

Computing a method is different. The platform draws the method as a working surface: the four HFACS tiers as a structured ladder, the SHELL components as interfaces you assess one by one, the Fishbone spine, the 5-Why chain, the bow-tie itself. You work inside the structure of the method instead of typing prose into a blank box, and the result is part of the record, not a document next to it.

The short version: a documented method is a template you fill in; a computed method is a surface the platform renders and keeps connected to the record it explains. eAviora ships the second kind.

The catalogue covers the methods aviation investigators actually use. Each one has its own dedicated on-screen renderer, not a shared free-text field with a different heading.

• HFACS, the Human Factors Analysis and Classification System, a four-tier human-factors model that sorts contributing factors into unsafe acts, preconditions for unsafe acts, unsafe supervision and organisational influences. It gets a dedicated renderer that draws the four tiers, so factors land in the right level instead of in a paragraph.
• SHELL, the model that examines the mismatches between people and the system around them: the interfaces between the human and the software, the hardware, the environment, and other people. Rendered as the components to assess, not a wall of text.
• Fishbone (Ishikawa), the cause-and-effect diagram that groups contributing factors along a spine, so categories of cause are visible at a glance.
• 5-Why analysis, the chain of questions that walks from the event to the cause underneath it, one answer per step.
• Bow-tie, the top event in the centre, threats on the left, consequences on the right, and barriers along the paths between. Rendered as the working diagram, with each barrier carried as a control you can rate, not a box you describe.

For maintenance and ramp work the catalogue adds MEDA, REDA, PEAR and the Dirty Dozen, each with its own renderer. Two well-known methods are not drawn today: Tripod Beta, which traces each event back through its immediate causes to the latent conditions that allowed it, and the Reason (Swiss-Cheese) model, which treats defences as layers whose gaps line up. Both remain sound ways to think about an event.

Because each method is rendered rather than documented, the platform can do something a PDF cannot: keep the analysis inside the investigation. The investigation is linked to its occurrence, the barriers rated against it and the corrective actions, so the method explains the record rather than describing it from the outside.

A blank method, computed or not, is still a blank method. The hardest part of any structured analysis is the first pass, turning the facts of the occurrence into a starting structure. eAviora handles that with an AI first pass: eAvy, the AI assistant, proposes the method that fits the occurrence and a preliminary root-cause narrative with its key factors and its confidence.

Then a human validates it. On a record, the AI proposes and the investigator decides. The draft is a starting point, never the finding. The investigator reads it, edits it, accepts the parts that hold and rejects the parts that do not. Nothing is accepted simply because the AI suggested it.

The value of the first pass is that it removes the blank-page problem without removing the investigator's judgement. An empty HFACS template makes you start cold; an AI-drafted root-cause narrative gives you a proposal to argue with, faster to a defensible result, and still owned by the person whose name is on the investigation.

It is tempting to treat investigation as a writing task: a good investigator writes a good narrative, so give them a big text box. The problem is that a text box records what one person thought to write on one day. The next investigation, by a different person, captures different things in a different order, and now the two cannot be compared.

A structured method asks the same questions in the same shape every time. The four HFACS tiers are always the four HFACS tiers. The SHELL interfaces are always the same interfaces. Fishbone always sorts causes into the same categories. That consistency is not bureaucracy, it is the only thing that lets an analyst look across a year of investigations and see a pattern: the same precondition recurring, the same supervisory gap, the same SHELL mismatch.

A dedicated renderer for each method is what enforces the shape. A free-text box cannot: it accepts anything, so it captures everything and compares nothing. Rendering the method means the contributing factors land where the method says they should, and they stay on the record the investigation belongs to, beside its barriers and its corrective actions.

And because the methods run inside the investigation stage of the occurrence workflow, on the same connected operation as the barriers and the corrective actions, the analysis links to the record it explains. A bow-tie that is a working surface rather than a spreadsheet, and an investigation that connects the occurrence to the actions that follow, are the same idea applied to the same record, one connected operation, not a folder of documents.

See the SMS module for where the investigation stage lives, the glossary entry for HFACS for the method definitions, or contact us to walk through your operation.