How AD compliance actually works.
A missed airworthiness directive is not a paperwork gap. It is an audit finding, or an aircraft that doesn't fly. The hard part isn't tracking directives — it's knowing which one applies, when it's next due, and proving you closed it.
Tracking the directive is easy. Closing it is the work.
A list of directives is the starting point, not the answer. The real questions are harder: does this AD apply to this serial? Which revision is current? How is its next-due computed? And when the auditor asks, can you show the compliance with its evidence — for the effectivity that actually applies?
A directive is only closed when the applicable effectivity is complied with andthe evidence is attached. And a repetitive AD is never "done" — once you comply, it isn't closed, it's due again.
Fetch — and keep the chain, not just the latest.
Directives are pulled from EASA and FAA, and revisions and supersessions are tracked over time. A superseded AD isn't deleted — it's replaced, and the chain matters. When an auditor asks why an older directive shows no recent compliance, the answer is the supersession record pointing at the AD that took its place.
Applicability — scope to the actual aircraft.
A directive applies to a configuration, not a fleet. Applicability is resolved against the real aircraft — by MSN, by effectivity range, by serial. A directive that doesn't apply isn't ignored and isn't silently dropped: it's recorded as not_applicable with a reason. The reason is what defends the call at audit.
Applicability is an effectivity decision, not a judgment call. "Doesn't apply" is a recorded status with a reason — not a gap in the list.
Compliance method — four, each computing next-due its own way.
A directive's compliance type drives everything downstream. one_time is satisfied once. repetitive recurs on an interval and re-arms after each compliance. hard_time is a calendar or cycle limit. on_condition closes on an inspection result. The method is not a label — it's the rule that computes when the directive is next due.
The set is fixed: one_time · repetitive · hard_time · on_condition. Each one computes its next-due differently — getting the method wrong gets the deadline wrong.
Status lifecycle — and what a repetitive AD does next.
A directive moves through a fixed set of states: open, repeat, closed, superseded, cancelled, not_applicable. The state that trips most systems is repeat. When you comply with a repetitive AD it does not go to closed and it does not go back to open — it returns to repeat. It's due again. And 'accomplished' is not a state — it has never been a valid status.
A repetitive AD returns to repeat after compliance — not open, not closed. It's due again. Overdue is strict: a directive due today is due-today, not overdue.
Evidence to close — the record won't commit without it.
A compliance record won't commit unless its evidence is attached and valid — the Evidence Doctrine. The linked record must be OCR-complete, AI-summarized, on an allowed event type, and resolve to the right aircraft. Fail any one and the commit is refused with a structured 422, not saved with a hole in it. The data room is the audit trail you kept all along.
Closing isn't a checkbox — it's a record with valid evidence behind it. If the evidence doesn't resolve, the close is rejected, not silently accepted.
Four ways a directive slips through.
- A repetitive AD treated as one-time — complied once, marked done, and it never recurs until an auditor finds the gap.
- A superseded AD left open — the chain was broken, so a closed directive reads as overdue, or a live one reads as handled.
- An applicability call made by gut, not by effectivity — and a directive that did apply was waved off without a reason on record.
- Overdue computed with <= — so a directive due today reads as already late (or the reverse, and a real overdue hides).
A directive you can close is a finding you don't get.
The right revision, the applicable effectivity, the correct method, the honest status, and the evidence attached — that's the difference between a directive you tracked and a directive you can prove you handled.
Bring the directive you're not sure about.
We'll resolve its applicability against your aircraft, show its next-due by method, and prove how it closes.