Managing AOC manuals in Confluence for audit readiness: structure, governance, and a “current version” at the push of a button
- Oliver Groht
- Jun 1
- 6 min read
An AOC stands or falls not only with good procedures, but with manuals that are controlled, up to date, and easy to find at any time. For managing directors and accountable leaders, this is not a “documentation topic” but risk management: Who is allowed to change what? What is actually valid? And how quickly can you present a consistent set of documents in an audit?
This article provides a proven, practical thread to follow—without tool ideology and without promises you cannot keep later.
The guiding thread: three decisions that simplify everything
For manuals to work in day-to-day operations (and not only during an audit), you need three things—in this order:
Clarify the manual map: Which manual parts and supplementary documents do you really have?
Define the Confluence structure + templates: consistent, traceable, exportable.
Define governance: roles, review/approval, change evidence, communication.
If these three points are set up cleanly, Confluence moves from a “wiki” to a controlled manual platform.
1) Manual map: OM-A to OM-D and MEL as the core
For CAT-AOC operators, the basic structure of the Operations Manual (OM) is described in ORO.MLR.101. In practice, this outline is often used as the structure to be submitted:
OM-A (General/Basic): organisation, responsibilities, management system, and fundamental procedures.
OM-B (Aircraft Operating Matters): type-specific operating procedures and information per aircraft type/variant.
OM-C (Route/Area/Aerodrome/Operating Site Instructions): route, area, and aerodrome/operating site information.
OM-D (Training): training and checking programmes.
In addition to the OM, the MEL (Minimum Equipment List) is a separate document that requires approval. ORO.MLR.105 requires the operator to establish an MEL based on the applicable MMEL; the MEL and any changes to it must be approved.
The management point behind it
Regardless of the exact outline, one principle applies: changes must be controlled—with traceable approval and a clearly identifiable “current/valid version”.
2) Management system, safety and compliance: integrated or separate—always controlled
Management system, compliance and safety content must be documented, even if it is not necessarily labelled as separate “manuals”. In practice, two variants are audit-ready:
Integration into OM-A, when content is closely linked to organisation, responsibilities and standard procedures.
Separate manuals or appendices, e.g. a Management System Manual/Organisation Management Manual, a Safety Management Manual (SMM), a Compliance Monitoring Manual (CMM), or an Emergency Response Plan (ERP).
What matters for audit readiness: separated parts are acceptable—the decisive factors are currency, accessibility and controlled change status.
Decision logic: “integrate vs. separate”
A pragmatic trade-off that works well for decision-makers:
Frequency of change: what changes often (better modular), what changes rarely (can remain integrated)?
Accountability: is the functional owner clearly named?
Audit view: can we quickly provide a consistent, valid set—without searching?
Practical note: everything referenced in the OM is, in an audit, effectively “in scope”. References should therefore meet the same change-control standard.
3) Special approvals & supplementary documents: classify cleanly instead of building a “misc folder”
Depending on approvals/special approvals, additional documents are added—for example EFB documentation, LVO documentation, procedures/evidence for PBN, RVSM, ETOPS or Dangerous Goods.
In some organisations, additional labels (e.g. “OM-M”) appear as a container. This can be helpful, but often leads to misunderstandings. A practical rule:
OM-A to OM-D remain the core structure.
Supplementary documents are managed as their own clearly named area.
Do not “hide” anything that later must be evidenced, approved, or updated independently.
Short internal checklist (prevents years of side tracks)
Which special approvals/authorisations do we currently hold?
Which documents/appendices are affected?
Who is the owner (functional) and who reviews (compliance/safety)?
How are changes communicated (crew/training/stations)?
Confluence as a manual system: controlled, searchable, exportable
Atlassian Confluence is suitable as a manual platform because content can be structured, collaboratively maintained, and managed with traceable history and permissions. The key is the mindset: not “wiki”, but controlled manual management.
What leaders typically value:
A “current version” is not created by informal agreement, but by process.
Content is easy to find (also for deputies and stand-ins).
If needed, a consistent package can be provided as a PDF (e.g. per OM part or as a full set).
Important: PDF export is not a substitute for governance. It is the result of a clean structure and clear approvals.
Blueprint: a Confluence structure that works in operations
A robust target setup is a dedicated Confluence space, e.g. “AOC Manuals”, with a clear page tree:
OM-A
OM-B
OM-C
OM-D
MEL
Management system (e.g. Management Manual/SMM/CMM/ERP)
Special approvals & supplementary documents (e.g. EFB, LVO, further evidence)
Templates that speed up audits and daily work
Consistent page templates reduce back-and-forth and make reviews faster. Proven building blocks:
Purpose & scope
Owner (functional) + deputy
References/dependencies (links to impacted chapters)
Change note (what/why)
Attachments (if needed) with clear “controlled” labelling
Linking guideline: only link to external documents if their change control is clarified. Otherwise, manage them as controlled attachments or integrate the content consistently.
Collaboration without chaos: roles and approvals that are actually lived
Tools do not resolve unclear responsibilities. That is why a lean role model that fits mid-sized organisations is worth it:
Content owner (business function): responsible for content
Reviewer (compliance/safety): checks requirements and consistency
Approver (e.g. Accountable Manager / Nominated Person): provides binding approval
Editorial/editor: ensures structure, language, templates and consistency
A workable flow is typically:
Draft → Review → Approval → Publication → Communication
A compact example: change to MEL or an OM chapter
The business function creates/updates the content.
Compliance/safety checks consistency and evidence.
Approval is given by the defined authority.
Publication includes clear revision information; PDF package if required.
Affected teams receive a short change notice with a link to the relevant section.
Result: reliability does not come from more documents, but from less room for interpretation.
Jira as an add-on: steering changes and findings with traceability
Atlassian Jira complements Confluence where changes, findings and improvements should be managed as tasks—with owners, statuses and a documented decision trail.
Typical use cases:
Audit findings and corrective actions
Changes to MEL or OM chapters
Updates to SOPs and training content
To-dos around special approvals
Business value: decisions and implementation are findable, prioritised, and do not disappear in email threads.
Operational systems (e.g. Leon Flight Management): one data basis instead of shadow lists
Manuals must match operational reality. Operational systems such as Leon Flight Management help ensure that current facts are not maintained multiple times in side lists.
Proven, low-risk patterns:
Confluence points to current overviews from the operational context instead of duplicating static tables.
Jira changes keep a clear reference (e.g. event/flight/fleet) so decisions remain traceable later.
How far integration goes is an organisational and architecture decision. The management point remains: one consistent data basis instead of parallel shadow worlds.
A staged approach: from target picture to a lived routine
Instead of rigid time promises, a staged model works better—depending on team size, existing documentation, audit pressure and complexity:
Stage 1: Create clarity – map, responsibilities, dependencies, priorities.
Stage 2: Build the structure – space, page tree, templates, export logic, pilot areas.
Stage 3: Anchor governance – roles, review/approval, Jira workflows, training for owners.
The goal is not “perfect documentation”, but a system that is reliable in daily operations and can provide a consistent status in an audit without last-minute stress.
Conclusion: audit readiness is a leadership and process topic
Confluence can represent AOC manuals very well—if structure, roles and approvals are clearly defined. This creates a resilient single source of truth that reduces risk, speeds up audits and makes changes controllable.
Next step: from concept to a stable routine
If you want, we can review in a compact blueprint workshop whether your current manual map, Confluence structure and governance are already audit-ready—and which 3–5 measures deliver the biggest leverage for a stable “current version”.
To make that workshop actionable for management, it helps to align on three concrete outcomes upfront:
A clear “what’s in scope” list (OM parts, MEL, management system content, special approvals) with named owners.
A target Confluence page tree + templates that your team can actually maintain—without creating parallel documents.
A lightweight governance model (review/approval cadence, change communication, and a simple way to prove what was valid when).
That way, you don’t just become “audit-ready on paper”—you build a manual system that remains stable when operations get busy, people change roles, or the next audit comes sooner than expected.
About Arkcanis Consulting
Arkcanis Consulting GmbH is the specialized advisory unit of the Arkcanis Group. We design scalable process and data architectures for airlines, AOCs, operators, and technology-driven organizations — with a clear focus on aviation engineering, Leon integrations, Atlassian architectures, ETL pipelines, and real-time dashboards.
As the founder of catworkx GmbH — one of the largest Atlassian partners in the DACH region — Oliver Groht brings more than 25 years of experience in Jira and Confluence architecture, process consulting, and enterprise-wide scaling. He combines this background with deep technical expertise in Leon GraphQL, data engineering, Grafana, and Flight Ops workflows.
The result: measurable, transparent, and resilient structures that enable operational excellence and strengthen strategic decision-making at the management and C-level.
