Airworthiness Documents

The Airworthiness module centralises the regulatory and technical documents that define the requirements for maintaining aircraft in an airworthy condition: service bulletins (SB), airworthiness directives (AD), modifications (MOD) and supplementary maintenance directives (DES).

Document types

Key fields

Effect-driven links

A link between two documents — or between a document and a maintenance task — is not a mere label: it carries an effect. When the source document becomes compliant on an individual (aircraft or item), the system acts automatically on the target, for that same individual: it can open it, close it, void it, exclude it, require a prerequisite, or reshape a task’s periodicity. A link with no effect (“references”) stays purely documentary.

The full catalogue of the nine effects, links to a maintenance task, and the prerequisite guard are detailed on

Supplementary Maintenance Directives — the mechanic is shared by all airworthiness documents (SB, AD, MOD, DES).

Versioning aside. The Supersedes link (a revision replacing the previous one) remains driven by the revision mechanism (see “Revision management” below), independently of effects. Links created before this mechanic are classified as “references” — no retroactive effect.

Sections

An airworthiness document can be structured into hierarchical sections (tree). Each section carries a code, a title, an optional description and a sequence number. Sections reflect the internal structure of the original technical document (chapters, sub-parts, tasks…).

Rich text (markdown)

Two fields accept unlimited long text formatted in markdown: the document header Notes and each section’s Description.

• Formatting buttons (bold, italic, heading, lists, link, blockquote, code, table): no need to know the syntax — the button wraps the selected text or inserts the template.
• Formatting also via keyboard markdown: **bold**, lists, headings (#), tables, blockquotes.
• Edited with an Edit / Preview toggle to see the rendering before saving.
• Line breaks: pressing Enter creates a line break (natural behaviour, no special syntax needed).
• Rendering is safe: raw HTML is not interpreted.

Lifecycle

Only one Active revision at a time. For a given reference (across all revisions), the system guarantees at most one Active revision. Activating a revision automatically switches all other active revisions of that reference to Superseded (and voids their compliances) — see “Managing revisions”.

Managing revisions

When a new revision of a document is issued (rev. B of an AD, say), there’s no need to re-enter everything: the “New revision” button on the document sheet creates a full copy — sections, applicability, due conditions — under the new revision, and automatically sets the Supersedes link to the original. The copy starts as a Draft: adjust what changed (dates, modified sections, official PDF) before putting it in force.

Automatic re-evaluation on activation. When the new revision becomes Active, all other active revisions of the same reference switch to Superseded and their compliance records become void (the “single active revision” invariant). Since the new revision has no compliance records yet, its targets (affected aircraft / components) automatically reappear as “to do” in the Compliance dashboard — i.e. to be re-verified against the new revision. Records explicitly marked “not applicable” are preserved.

Changing due dates = create a revision. On an Active document that already has compliance records, editing the due conditions or the due policy in place is rejected: the due dates already computed on existing records would not be recalculated, skewing the tracking. Use “New revision” to change due dates. (As long as no compliance record exists, fixing them is unrestricted.)

Applicability

Each document can be supplemented with applicability rules that precisely define the affected population (aircraft or components). Rules accumulate:

• Include: population included in the document’s scope.
• Exclude: population removed from the scope (exception).

Available selectors

For modification (MOD) documents, applicability rules on components can also record the resulting PN and MOD level after embodiment.

Conditions (modification state)

An aircraft rule can be conditioned on the modification state of another document. A common case is an airworthiness directive targeting two populations: “applicable to aircraft embodying MOD-XXX” on one side, “to non-embodied aircraft” on the other.

The Conditions button under each aircraft rule opens the editor:

• Groups joined by OR, conditions stacked with AND within a group, the NOT carried by the state (“applied” / “not applied”).
• A rule then applies to an aircraft only if its selector matches and its conditions are satisfied. Conditions also apply to Exclude rules.
• With no condition, the rule applies without restriction (default behaviour).
• Section operand: a condition can target a specific section of a document (instead of the whole document). It is then satisfied by the compliance of that section, tracked independently (a document compliant at the global level does not imply a compliant section).

The “affected fleet” and compliance resolution account for these conditions automatically. (Component rules are not yet conditionable.)

Affected fleet

The Calculate button in the “Affected fleet” panel resolves in real-time, from the applicability rules, the aircraft and components in stock or in service that are affected by the document.

• Direct: the aircraft matches directly an aircraft-type rule.
• Component: the aircraft carries a part targeted by a component-type rule.

Climatic zones

STANAG 4370 / AECTP-230 climatic zones are managed in

Administration › Climatic zones. They can be associated with a site or directly with an aircraft (override), and used as a selection criterion in applicability rules.

Compliance

Once a document applies to an aircraft (or a component), Envergure tracks its compliance status. An aircraft does not have one modification level but a set of embodied SB / AD / MOD documents: each compliance is tracked individually (when, by whom, via which work order, with which evidence), forming the aircraft’s modification-status report.

Compliance statuses

As long as no record exists, an applicable document is considered To do: applicability is the source of truth, there is no need to pre-create the compliance record.

On the aircraft detail page

The Airworthiness documents section of an aircraft’s detail page lists every document that concerns it — directly, or via an installed component (the part is identified as PN:NCAGE / SN). By default the view is filtered on actions to do (to do, in progress, deferred, overdue), like maintenance dues. The Mark complied button opens the compliance entry (status, method of compliance, date, work order, evidence document). A Mandatory filter isolates the mandatory documents still to be handled.

Fit for service & blocking obligations (CRS)

At the top of the panel, an airworthiness verdict summarises whether the aircraft is fit for return to service (signing the CRS — Certificate of Release to Service):

• Not fit for service (red) — at least one blocking obligation exists. An obligation is blocking when the document is mandatory, open or in progress, and either overdue or without any due window (no target date/counter = “before next flight”). These rows carry a Blocking tag. They must be cleared (or covered by a deviation) before signing the CRS.
• Mandatory obligation(s) to do, non-blocking (amber) — mandatory items remain but are still within their due window: to be planned, without grounding the aircraft today.
• No blocking obligation (green) — nothing on the airworthiness side prevents return to service.

The verdict relies on the due engine: a mandatory item still within its window (future deadline, remaining hours) is not blocking. Only overdue ones and mandatory items with no due window at all block by default.

Generate a work order

On an action-to-do row targeting the aircraft, the Generate work order button directly creates the work order (WO) that will carry out the compliance. The document’s sections become the WO checklist (one operation per section, in order); with no section, a single operation stands in for the document. The WO is filed under an airworthiness work package (DT) for the aircraft (NAV-<registration>), auto-created if missing and reused afterwards. The compliance then moves to in progress and stays linked to the WO (an OT-… badge).

Automatic proof closure. When the WO is completed (all its operations done), the compliance automatically flips to complied — with the completion date and actor, and the WO as attached evidence. No double entry: you execute the WO, the compliance settles itself. For a recurring document, the next due date is recomputed from that compliance date; for a MOD on a component, any RA:CE re-identification is applied.

For a component target (a part removed to the workshop), the WO must be attached to an existing work package — auto-creation of the DT is reserved to aircraft targets.

Unified view in the schedule. Airworthiness obligations to be carried out on an aircraft (open or in-progress AD / SB / MOD) also appear in the aircraft sheet’s “Maintenance schedule” panel, next to maintenance-programme tasks — the planner sees everything in one place. The compliance engine remains the source of truth (no double tracking, no recomputation): it is purely a display, each row linking back to the document sheet where the WO is generated.

Due dates (recurrence)

A recurring or mixed document carries one or several due conditions, calendar-based (days / months / years) or meter-based (flight hours, cycles…) — for example “500 h or 24 months”. When several conditions coexist, the document’s trigger policy arbitrates:

• First threshold reached (aeronautical standard “whichever occurs first”): due as soon as one condition is met.
• All thresholds reached: due only when every condition is met.

When a compliance is recorded, Envergure automatically computes the next due of each condition (the aircraft’s current meter reading is the baseline) and flags overdue items (overdue in red). A section can carry its own conditions — the multi-part AD case (“100 h inspection until terminating modification”).

Each condition has a basis:

• Recurrence (default): the due is computed from the last compliance (the repeating cycle).
• Initial: the due is computed from the document’s effective date — this is the first compliance window (“within 50 flight hours of issuance”). It shows while the item is still to do, even before any compliance has been recorded.

A condition can also be an absolute deadline (“no later than 1 May 1991”), independent of any interval. Combined with the first threshold reached policy, an AD such as “within 50 h and no later than 01/05/91” becomes the earlier of the two.

Conditional periodicity

A calendar or meter condition with basis recurrence can carry one or more conditional rules: “after the triggering document Y is applied → new period”. As long as Y has not been applied, the condition follows its normal interval; as soon as Y is marked complied, the rule’s new period replaces the normal interval going forward.

The computation stays anchored on this document’s own last compliance (not on Y’s compliance date): the next due becomes this document’s last compliance + new period. Concrete example:

An AD “inspection every 12 months” carries a rule “after SB-XXX (structural reinforcement) is applied → new period 24 months”. The AD’s last compliance: 01/01/2025. SB-XXX is applied before the AD’s normal next due: the rule triggers, and the AD’s next due becomes 01/01/2027 (01/01/2025 + 24 months) — instead of 01/01/2026 (+12 months, the normal interval).

Several rules can coexist on the same condition (different triggering documents); each carries an optional free-text comment to record context (section reference, bulletin wording…). With no applicable conditional rule, the condition follows its normal interval, unchanged.

Event-driven due

Some obligations are measured neither in time nor in counter but re-trigger on every occurrence of an event — typically “redo on every removal of the winch”. Pick the On event type, then the triggering event:

• On every removal and on every installation / refit are automatic: when you uninstall or install the component in Envergure, the compliance reverts to to do on its own.
• On every inspection and generic event are signalled manually from the document page (the event has no automatic source).

An event-driven condition projects no target date or counter: until an event occurs, the last compliance stays valid; as soon as it occurs, the obligation reappears in the aircraft compliance and in its deadlines.

Dashboard

Maintenance › Compliance gives a fleet-wide view: number of active documents, applicable items, complied, to do, overdue and mandatory-open counts, with an attention queue sorted by criticality (overdue, then mandatory, then nearest due date).

Component life story

For a serialized component, compliances recorded against it appear in its life story (M.A.305 audit deliverable). For an embodied modification, the RA:CE re-identification (PN change after incorporation) is tracked there.

Per-individual derogations

Applicability rules define an entire population (a fleet, an aircraft type, a batch of components…). The document sheet’s “Derogations” panel instead lets you target one specific aircraft (registration/MSN) or one specific unit (part number + serial number) and attach it a disposition that overrides the overall compliance of the document for that single individual — without touching the rest of the affected population. The model is generic: the panel is available on any airworthiness document (SB, AD, MOD, DES).

A derogation is created by picking the target (aircraft or unit — never both through the same panel — via the usual searchable pickers, never a raw technical identifier), the disposition, and an optional justification note. It can be deleted at any time from the same panel; the individual’s compliance then reverts to the normal regime (applicability rules + compliance records).

On the aircraft sheet, the active disposition and an optional Attention badge display directly on the row of the affected document, next to the usual compliance status.

See also

• Airworthiness compliance — fleet-wide compliance dashboard.
• Maintenance programs (PRE) — maintenance tasks may reference airworthiness documents.
• Work packages — execution of airworthiness actions.
• Climatic zones — STANAG 4370 referential.