What a Part 135 SMS actually
needs from its software.

See the highlighted block above the contents list. The rest of this page walks through what the 2027 deadline actually asks of a charter operator, the four jobs your software has to do, the features you can ignore for a small fleet, a plain evaluation checklist, and how eAviora is built for the 2-to-20-aircraft operator that has no dedicated safety department.

The FAA SMS final rule was published on April 26, 2024 and took effect on May 28, 2024. It revised 14 CFR Part 5 and extended Safety Management System requirements beyond the Part 121 airlines to a much broader set of operators: all Part 135 certificate holders, commercial air tour operators flying under a 91.147 letter of authorization, and certain Part 21 certificate holders. If you hold a Part 135 certificate, you are in scope, and the revised Part 5 rule is now your baseline.

The timeline has two dates that matter for a charter operator. Implementation plans were due to the FAA on November 28, 2024. The SMS must then be fully implemented, with a declaration of compliance submitted to the FAA, no later than May 28, 2027. There is one line that changes how a small operator should read all of this: the requirement applies regardless of operator size, explicitly including single-aircraft and single-pilot certificate holders. There is no small-operator exemption. A two-plane charter faces the same deadline as a regional carrier.

What Part 5 asks for is structured into four components: Safety Policy, Safety Risk Management, Safety Assurance and Safety Promotion. The 2024 revisions also require a confidential employee reporting system and the declaration of compliance itself. Those four components are the same words an airline uses, and that similarity is exactly where small operators get into trouble: they assume the four components mean the same volume of paperwork. They do not. The components are mandatory; the depth scales to your operation.

Strip the buzzwords away and a Part 135 SMS asks its software to do four connected jobs. Miss any one and the declaration gets shaky, because each maps to a Part 5 component you have to evidence.

• Confidential reporting intake. Any pilot, dispatcher or mechanic must be able to report a hazard or occurrence without fear of it landing on them. That means a de-identified channel, not an email to the chief pilot. A proper confidential reporting system is a named requirement of the revised rule, not a nice-to-have.
• Risk assessment. Every report needs a structured severity-and-likelihood assessment so you triage the two things that actually matter this week instead of treating a bird strike and a coffee spill the same. This is the Safety Risk Management component in practice.
• Corrective-action tracking. A hazard is not closed when someone nods in a meeting. It is closed when the fix is assigned, done, and proven effective. The software has to carry each action to closure and refuse to let the record pretend otherwise.
• Evidence trail. When an FAA reviewer or your principal inspector asks, you have to show the chain: report, risk assessment, action, closure, all linked, all timestamped, without a weekend of screenshotting. That trail is the difference between an accepted declaration and an open finding.

Sitting across all four is the flight risk assessment tool (FRAT). A FRAT is pre-flight numeric risk scoring, widely used across Part 135, business aviation and helicopter operations, and the FAA and industry associations publish reference models. The point of putting the FRAT inside the same system is that a crew's daily go/no-go score is not a throwaway form: a pattern of high FRAT scores on a particular route or a particular tail is a leading indicator that belongs in the same risk picture as your reported occurrences.

Just as important as the must-haves is permission to ignore the rest. A small charter buying for the 2027 declaration does not need, and should actively avoid, several things that enterprise catalogs push:

• A blank library you have to populate. Many legacy tools ship an empty hazard catalog and an empty risk register and expect your team to build the content from scratch. For an operator without a safety department, that is months of unpaid data entry before any safety value appears.
• An airline-scale configuration project. If the tool needs a paid implementation consultant and a three-month rollout to switch on, it is the wrong size. A two-to-twenty-aircraft operation should be running real reports within days, not quarters.
• Modules you will not touch for years. Fleet reliability engineering suites, cabin-safety analytics, and heavyweight audit-planning tooling are real, but they are not what gets you to a Part 5 declaration. Pay for the loop that closes, not the catalog that impresses.
• Disconnected point tools. A reporting app here, a spreadsheet risk register there, and a separate action tracker is three places for the evidence chain to break. The value of an SMS is the links between records, not the records themselves.

The instinct to over-buy usually comes from a fear of failing the audit. The cure is not more features. It is a system that makes the four jobs above impossible to skip, and stays out of your way on everything else.

Here is a plain checklist to run any candidate tool against. You are a charter operator, not a procurement department, so score each on whether it helps you produce evidence by May 28, 2027 with the staff you actually have.

• Time to first real report. Can a pilot file a confidential report on day one, or does the system need weeks of setup first?
• Does the risk model come in the box? Are hazards, scenarios and barriers pre-loaded and aviation-specific, or is the register blank?
• Can a record close over open risk? A good tool refuses to close a hazard while its corrective action is still open. Ask the vendor to try to break that rule in a demo.
• Is the evidence trail exportable? Can you hand a reviewer a linked chain from report to closure without re-keying it into a separate report?
• Is confidential reporting truly de-identified? Does the reporter get feedback without ever being exposed?
• Is the FRAT part of the same system? Does pre-flight scoring feed your risk picture, or live in a separate app?
• What does AI cost and who is in control? Is AI consumption predictable and capped, and does a human accept or reject every AI proposal?
• Where does your data live? Is tenant isolation enforced by the database, and is your reporting data kept out of any model training?

If a tool clears that list, it will get you to the declaration without a safety department. Our buyer's guide expands each of these into procurement questions you can send verbatim.

eAviora is built to pass that checklist for exactly the operator that has no safety office. The starting point is the risk model in the box: a pre-built aviation risk library of 101 bow-tie models, 804 named barriers, 210 scenarios and a 610-indicator safety performance indicator library. You do not build the hazard catalog. It is there on day one, and you scope it to your operation instead of authoring it.

Everything runs on one operational graph. Occurrences, hazards, investigations, corrective actions, audits, findings, documents, training, compliance, indicators, your Safety Risk Profile, and the Safety Action Group and Safety Review Board governance are connected records, not separate spreadsheets. That is what makes the evidence trail a byproduct of doing the work rather than a reporting project of its own. The SMS module is the front door, and the same links carry a report all the way to a closed action.

The rule that most protects a small operator is the enforced closure gate: a record cannot close over open risk. A degraded barrier requires a linked corrective action, proven effective, before anything reads as closed. That is not a policy in a manual that a busy chief pilot might forget under deadline pressure; it is enforced by the system, and it is proven by a live scenario suite. Your Safety Risk Profile is computed from eight components fused into one score aligned to ICAO Doc 9859, and indicators run real statistical process control, not colored trend arrows, so a genuine signal is separated from ordinary variation.

The workload question is where the AI matters. eAviora runs 36 or more specialist AI agents bound to workflow stages, and every AI proposal is human-gated: a person accepts, modifies or rejects it, and the decision is audit-logged. The assistant drafts the classification and the first-pass risk assessment; a named human owns the call. AI consumption is metered in plain credits with hard caps, so there is no surprise cost, and your operational data never trains any model. Tenant isolation is enforced by the database, not only by app code, which is the answer an insurer or a client's security review actually wants to hear. To see it against your own operation, you can book a walkthrough.