When the operation works — but the manuals do not

In many flight operations, day-to-day performance looks solid.
Flights are conducted professionally, crews know what to do, and decisions make sense in practice.

Yet, during audits or oversight, the same operation may suddenly appear weak.

Not because the flying is unsafe — but because the documentation does not carry the operation.

What often keeps the system running is experience, local knowledge and informal understanding.
What is missing is documentation that clearly explains what is done, how it is done, and why — in a way that stands on its own.

A simple stress test

A practical test I often use is this:

Take a pilot unfamiliar with the operation, place them in the cockpit with your manuals, and pair them with a relatively new colleague.
Can they conduct the flight without uncertainty about procedures, responsibilities or regulatory intent?

If the answer is "it would work, but only because people already know how the operation functions from prior experience", then the operation is being carried by experience rather than by documentation.

Where the weaknesses usually appear

When an operation lives primarily in people's heads, the same patterns tend to emerge:

Procedures are unclear, incomplete or spread across multiple manuals.
Regulatory requirements exist, but are not translated into operationally usable text.
Different manuals describe similar topics — but not in a consistent way (OM-A, OM-B, OM-D, MSM).

Individually, these issues may seem manageable. Together, they undermine confidence in the system.

How I work: from requirement to usable manual text

Instead of delivering reports that say "this should be added", I deliver finished insert text that can be implemented directly in the correct manual section.

The approach is straightforward:

Start from the regulatory requirement (IR / AMC / GM).
Identify what is missing, unclear or misaligned in the current manual text.
Draft short, precise and operationally usable wording — in the correct OM tone.
Deliver copy-paste-ready insert text for OM-A, OM-D or the SMS manual.
Where needed, align terminology and responsibility across manuals so they actually support each other.

The result is documentation that begins to carry the operation — not just describe it in general terms.

Principles I follow when drafting insert text

I stay deliberately close to regulatory intent. The objective is alignment, not embellishment.

No expansion of requirements.
No additional obligations or self-imposed processes.
Short format — typically one to three sentences or bullets.
Clear, directive OM language where appropriate.
Text that is ready for publication, not commentary.
Stable wording that remains valid over time and across manuals.

What the delivery looks like in practice

To make implementation straightforward, the output follows a consistent structure:

Regulatory quote — the relevant IR/AMC/GM extract showing intent.
Manual quote (as-is) — the current wording.
Gap — a concise description of what is missing or unclear.
Suggested — a high-level corrective approach, aligned with the requirement.
Insert text — finished manual text ready to be implemented.

Where necessary, cross-references are included to ensure OM-A, OM-B, OM-D and MSM remain consistent in both wording and responsibility.

That last part is often what makes the difference: the text ends up in the manuals, not on a to-do list.

Next step

If you recognise an operation that works well in practice but is poorly supported by its documentation, a focused review of a single priority area is often enough to reveal where the system starts to rely on explanation rather than control.

That is usually the right place to start.

If you would like to discuss a potential engagement, feel free to get in touch.