Aviation SMS Software vs Aviation Safety Intelligence Platform: What Is the Difference?

SMS software is the system of record for ICAO Annex 19 artefacts. Its responsibilities are well-defined:

• Occurrence intake across mandatory, voluntary and confidential channels. Mobile-first reporting forms; investigation workflow; classification against the operator's taxonomy.
• Hazard register with each hazard linked to its operational area and current state.
• Risk matrix with severity × likelihood scoring tailored to the operation.
• CAPA pipeline with corrective and preventive actions, typed owners, due dates and effectiveness verification.
• Audit programmes for internal compliance monitoring with finding lifecycle.
• Document control for safety manuals, procedures and safety bulletins.
• SPI definitions with thresholds and ownership.

SMS software is necessary. Every regulated airline above a certain size needs one. The question is what comes on top.

Aviation safety intelligence renders the operational picture on top of the record. The picture is built from cross-module reasoning, reading one connected operation rather than several modules.

Occurrence → barrier → corrective action. A classified occurrence picks its risk family's bow-tie, the analyst rates each barrier the event tested, and a barrier rated short of effective holds the occurrence open until a corrective action or a recorded decision covers it.

SPI dashboards. Indicators re-evaluate every day, and at once when an occurrence's residual risk is set above the tolerable level. A breach notifies the indicator's owner with a due date. Trends are visible to the accountable manager weekly, not quarterly.

Computed Safety Risk Profile. The SRP fuses the assessed risk of the records, the indicator states and trend, the barrier ratings, the overdue corrective actions, data confidence and surveillance coverage into the operational picture the accountable manager reads, rolled up each month and reviewed by an analyst before it is published.

Cross-module weak-signal detection. A pattern no single module would catch on its own, the same barrier rated less than effective on approaches with one aircraft type at one airport, is found by a daily statistical scan across occurrences, hazards, findings and flight-data exceedances, and reaches a person as a candidate to acknowledge, act on or dismiss. For one regulatory requirement, an AI agent reads the occurrences, findings, hazards and training linked to it, on request, and advises whether the operation tells a different story than the paperwork.

Audit-grade traceability. Every artefact links to its evidence. A regulator can trace from policy to outcome in two clicks per step.

AI in aviation safety is not a feature; it is an operating-model change. Three workloads were historically constrained by human throughput:

Classification. Every occurrence has to be classified against the operator's taxonomy. Human classification is slow, inconsistent across reviewers, and the throughput bottleneck of every safety team. AI classification agents propose categories with confidence scoring; humans approve. The throughput change is significant; the consistency change is more significant.

CAPA drafting. Drafting a corrective action against an open finding is a 20-minute job per finding. AI drafting agents produce a starting draft against the finding, the relevant procedure section and the previous action history. The human edits and approves. The total time drops without weakening the outcome.

Weak-signal detection. Spotting a pattern no single report shows was historically the work of a senior safety analyst with time on their hands. In eAviora the search runs every day and is statistics rather than a language model: combinations of facts such as event type, aircraft, location, flight phase, risk family and degraded barrier are tested against chance, and the ones that recur more often than chance explains reach a person as candidates. AI agents narrate around it: one writes the scan's brief from its numbers, and one reads a requirement's linked records and training when asked.

On a record, the AI never decides alone. The pattern is human-in-the-loop; the AI proposes, the human approves. The one exception in eAviora is a bulk import you start, which can apply high-confidence classifications, marked unvalidated, and sends the rest and a sample to a person. This is what makes AI in aviation safety defensible to a regulator.

Human-in-the-loop (HITL) is the structural pattern that distinguishes defensible aviation AI from undefensible aviation AI. The pattern has four components:

1. The AI proposes. Classification, draft, summary, signal, the AI agent produces a candidate.
2. The system records. The audit trail captures the agent, the model, the prompt, the inputs, the proposed output and the confidence.
3. A qualified human reviews and decides. The named human, appropriate to the task (safety manager for a classification, head of safety for a CAPA closure, accountable manager for an SRP shift), approves, edits, or rejects.
4. The platform replays. Three years later, the regulator can replay the agent run, see the inputs, see the proposal, see the human approval, see the outcome.

The HITL pattern is what makes AI in aviation safety useful and defensible. Platforms that ship AI features without it are an audit risk.

Use this checklist to test whether a candidate platform is SMS software, an aviation safety intelligence platform, or something in between.

1. One connected operation. Are occurrences, hazards, barriers, SPIs, SRP, CAPA, audits, training and document control all linked records? Or modules stitched together by APIs?
2. Occurrence-to-SRP trace. Pick a real occurrence. Can you walk it from intake to SRP in two clicks per step?
3. SPI evaluation. How often do the indicators re-evaluate, and does an occurrence assessed above the tolerable risk re-evaluate them at once?
4. AI agents with HITL. Are AI outputs recorded with agent, model, prompt, confidence, and named human reviewer? Can a run be replayed three years later?
5. CAPA effectiveness verification. Is it a hard gate before closure, with a named verifier and an audit-grade trail?
6. ICAO + EASA + FAA + IOSA vocabulary. Native, or bolted-on?
7. Tenant isolation. Where the platform serves multiple AOCs, is isolation enforced at the database layer?
8. Data residency and export. Where is the data stored? What happens on termination? What export format?
9. Open machine surface. Is there a versioned REST API plus an MCP server, the open standard that lets an AI assistant query your live safety picture directly, with governance state locked against automation, so an assistant can read everything but set nothing?
10. Pre-built aviation risk model. Does a bow-tie, barrier and SPI library ship in the box, or is the platform an empty canvas you have to configure from scratch before it can reason about anything?

A platform that scores high on all ten is an aviation safety intelligence platform. A platform that scores high on items 1, 5, 6, 7 and 8 but lower on 2, 3, 4, 9 and 10 is SMS software. Both are valid; the choice depends on what the airline needs.