Here is a sequence that plays out in a lot of organisations. A hazard is reported. It is assessed, and the mitigation turns out to be a procedural change. The procedural change means a manual revision. The manual revision goes to the documentation team, gets drafted, reviewed, approved and published — and somewhere in that handover, the link back to the original hazard report is lost.
Six months later, someone asks whether that hazard was ever actually closed out. The answer exists, but it takes two systems and three people to reconstruct.
What the connection is actually for
Linking a manual system to an SMS is not primarily about convenience. It is about being able to answer two questions without an archaeology project:
- Forwards: this hazard led to a mitigation — did the mitigation reach the document, and which revision carries it?
- Backwards: this procedure was changed — what safety reasoning drove it, and is that reasoning still valid?
The second question is the one that gets neglected, and it is the more valuable of the two. Procedures accumulate. Very few organisations can explain why every paragraph in their manual is there. When you can, you can also tell which ones have outlived their reason.
Revision as a safety event
Treated administratively, a manual revision is a version number, a distribution list and a read confirmation. Treated as a safety event, the same revision raises different questions: who is affected by this change, do they need briefing rather than just notification, and does the change introduce any new hazard of its own?
Every procedural change is a change to the system that produces safety. That is worth a risk assessment, not just a version number.
That last question — does the change itself create a hazard — is routinely skipped. A procedure written to close one gap can easily open another, particularly when it adds a step to a workload that was already tight.
What we built
FlySafe connects to manual systems through their API, so a mitigation recorded against a hazard can reference the document section it changes, and a published revision can flow back as a closing event on the original report. The audit trail spans both systems instead of stopping at the boundary between them.
Nothing here removes the editorial work. Someone still has to write good procedure text, and that remains the hardest part. What it removes is the reconstruction — the part that was never anybody's job and always somebody's afternoon.
Worth checking in your own organisation
Take the last three procedural changes you made for safety reasons. Can you get from the published paragraph back to the report that caused it in under five minutes? If not, that gap is doing quiet damage to your ability to review your own decisions.
Curious how the integration would fit your document setup? Book a demo and we'll walk through it with your own setup.