SMS software, without the overclaim
The FAA's SMS mandate is pulling every Part 135 operator toward a compliant safety management system. Navlyt's SMS module is planned, not shipped — here is what the mandate asks, what Navlyt covers today, and what's coming.
Status first, as always: Navlyt's clause-level manual mapping is live for FAA 14 CFR Part 135 and Part 91. A dedicated SMS module is planned and not yet shipped. If you are evaluating SMS tooling against a mandate deadline, you deserve that answer in the first sentence.
The FAA's SMS rule extends Part 5 safety management system requirements to Part 135 operators — a structural shift from prescriptive compliance to managed safety. An SMS is built on four components: safety policy, safety risk management, safety assurance, and safety promotion. It is audited less like a checklist and more like a management review: does the system exist, does it run, and can you prove both?
That difference is exactly why we have not bolted an 'SMS module' onto the Part 135 pipeline overnight. SMS documentation doesn't map to prescriptive clauses the way a GOM maps to §135.293 — the model has to represent policies, risk registers, and assurance loops. We are building that model deliberately, with operators facing real mandate deadlines.
What the mandate actually requires
Under the extended Part 5 framework, a Part 135 operator's SMS must demonstrate the four components in a form scaled to the size and complexity of the operation:
- Safety policy — accountable executive, safety objectives, and documented commitment
- Safety risk management — hazard identification and risk assessment with controls
- Safety assurance — audits, evaluations, and performance monitoring that actually run
- Safety promotion — training and communication that reach the line
What Navlyt covers today
Much of what an SMS auditor examines is already the regulation-agnostic core of Navlyt — and operators use it for exactly that while the dedicated module is built:
- Document control with draft → review → approved lifecycle for SMS manuals and policies
- Corrective-action tracking with owners, target dates, and server-owned audit trail
- Findings with cited evidence and human disposition — the assurance loop's paper trail
- Crew records and medical expiry tracking
What the SMS module will add
The planned module extends the mapping approach to SMS structures: your safety policy and SMS manual analysed against the Part 5 component requirements, gaps proposed with cited evidence, and the risk-register and assurance workflows connected to the corrective-action system that already runs.
The deadline is real — so is our status
Mandate deadlines create pressure to buy something labelled 'SMS software' quickly. Our advice, which costs us sales: what matters to an auditor is a functioning system with evidence, not a logo on a login page. Start with the document control and corrective-action discipline you can run today; join the early-access group and the SMS mapping arrives against your real program, not a template.
Frequently asked questions
Is Navlyt's SMS module available now?
No — it is planned. What ships today is Part 135 / Part 91 clause mapping plus the regulation-agnostic core: document lifecycle, corrective actions, findings with cited evidence, and crew records. Many operators run their SMS paperwork discipline on that core now.
When does the FAA SMS mandate take effect for Part 135?
The FAA published the SMS final rule in 2024 with phased compliance dates for existing certificate holders — most Part 135 operators face implementation deadlines around 2027. Confirm your specific date against the final rule and your certificate status; our blog guide walks through the timeline.
Can Navlyt analyse our SMS manual today?
You can upload and control it like any document, and the analysis will run — but SMS-specific requirement mapping is the part still in development, so treat any SMS-related findings as generic rather than Part 5-mapped until the module ships.
What makes SMS harder to map than Part 135?
Part 135 is largely prescriptive — a requirement either has a matching procedure or it doesn't. SMS is a management system: the 'requirement' is that processes exist, run, and improve. Representing that honestly needs a different model than clause-matching, which is why we're building it rather than renaming what we have.
How do early-access partners work?
Operators with real mandate deadlines bring their SMS documentation and shape the mapping model against it. They see the module first and set the delivery sequence. Tell us your compliance date.
Related reading
Facing an SMS deadline?
Tell us your compliance date. We'll show you what runs today, and early access puts your program at the front of the SMS build.