Airworthiness Directive Compliance

Airworthiness Directive Compliance (systems-engineering-safety/continued-airworthiness/airworthiness-directive-compliance)

Use when issued airworthiness directives must be checked against the operator fleet: which aircraft fall inside the directive effectivity, how much compliance margin each one has left in the directive's own basis, and how the fleet rolls up against the grace band. This leaf implements the compliance-evaluation model in pure Python, stdlib only: applicability by affected model and serial range, margin as value minus elapsed usage (cycles, hours, or calendar days converted from months), per-aircraft status open / due / overdue, and the per-directive fleet report with counts and the strict compliance rate. It sits in the continued-airworthiness pack with in-service-safety-assessment, whose field-experience corrective-action route can issue a directive request when an operator has none to evaluate yet; it does not judge field rates, derive routine tasks, or touch design change control.

Domain quick reference

• AD record shape: {id, affected_models: [str], affected_serials: [(lo, hi), ...], basis: "cycles" | "hours" | "calendar", value: float > 0, grace: float >= 0, effective_date: "YYYY-MM-DD"}.
• Aircraft record shape: {model, serial, cycles_since_last_action, hours_since_last_action, last_action_date or None}.
• Applicability: an aircraft is applicable when its model is in affected_models (whole-model effectivity) or its serial falls inside any (lo, hi) serial range (serial-specific effectivity). Serials compare as strings, so they must be zero-padded to a common width.
• Compliance margin: remaining = value - elapsed. Elapsed for an event-basis AD is the cycles or hours since the last action on that aircraft; for calendar basis it is the whole days from the effective date to as_of, with DAYS_PER_MONTH = 30.4375 so value_days = value * 30.4375.
• Status rule: remaining > 0 -> open (margin remains); -grace <= remaining <= 0 -> due (past the compliance point, inside the grace band); remaining < -grace -> overdue. The grace band is in the same unit as the margin: raw cycles or hours for the event bases, days for calendar.
• Fleet report: {ad_id, basis, applicable, open, due, overdue, compliance_rate}, with compliance_rate = open / applicable exactly and None when no aircraft in the list is applicable. Identity: open + due + overdue = applicable; a non-applicable aircraft never appears in the counts.
• Regulatory frame: an AD amends the type design certified under FAR Part 25, and operator compliance sits in the 14 CFR 39 and 91 frame; this leaf evaluates the directive record against aircraft records and does not reproduce the directive text. Standards are reference-only.

Workflow

1. Assemble the AD record for the directive under review (id, affected_models, affected_serials, basis, value, grace, and effective_date for calendar basis) and the aircraft records with their since-last-action counters; fix as_of as a datetime.date.
2. Screen the fleet with ad_applies: model hit or serial-range hit is applicable; a serial outside every range and a model outside the effectivity list drops out of the review entirely.
3. Compute the margin for each applicable aircraft with remaining_units; positive means the compliance point is ahead.
4. Classify with compliance_status: open when margin remains, due when past the point but inside the grace band, overdue beyond it.
5. Roll up with fleet_ad_review for the per-directive report and check the identity open + due + overdue == applicable and the rate.
6. Confirm the deterministic checks with the contract test scripts/test_airworthiness-directive-compliance.py.

Worked example

AD-2024-001: models ["T-100"], basis cycles, value 4000, grace 200. Fleet: ac1 T-100/001 at 3500 cycles, ac2 T-100/002 at 4200, ac3 T-100/003 at 4550, ac4 T-200/009, and ac5 T-100/004 at 3500. Real module outputs:

• ad_applies: ac1, ac2, ac3, ac5 True; ac4 False (model T-200 not affected).
• remaining_units on 2026-02-01: ac1 500.0 (4000 - 3500), ac2 -200.0, ac3 -550.0, ac5 500.0. All four magnitude bounds from the spec hold.
• compliance_status: ac1 open, ac2 due (-200.0 inside [-200, 0]), ac3 overdue (-550.0 below -200), ac5 open.
• fleet_ad_review: applicable 4, open 2, due 1, overdue 1, compliance_rate 0.5 exactly; ac4 never appears in the counts.

AD-2024-002: models ["T-100"], basis calendar, value 24, grace 3, effective_date 2024-01-15. Real module outputs on 2026-02-01 (748 elapsed days): value_days 730.5, remaining -17.5, status due (inside grace_days 91.3125). On 2027-06-01 (1233 elapsed days): remaining -502.5, status overdue.

Verification

• Confirm ad_applies(AD-2024-001, ac4) is False and True for the four T-100 aircraft; serial-range effectivity includes both bounds.
• Confirm remaining_units returns 500.0, -200.0, -550.0 for ac1, ac2, ac3 and -17.5 / -502.5 for the two calendar anchors.
• Confirm compliance_status boundaries: remaining exactly 0 is due; remaining exactly -grace is due; anything below -grace is overdue.
• Confirm the fleet report identity open + due + overdue == applicable, compliance_rate == open / applicable, and compliance_rate is None when nothing is applicable (never a misleading 0).
• Confirm ValueError rejection of an unknown basis, non-positive value, negative grace, an empty aircraft list, and records missing required keys; calendar basis without a valid effective_date also raises.
• Run the contract test offline: python3 scripts/test_airworthiness-directive-compliance.py (34 tests, deterministic).

Related leaves

• systems-engineering-safety/continued-airworthiness/in-service-safety- assessment: the field-experience route that can issue a directive request when field rates are safety-significant; this leaf evaluates compliance with a directive that is already issued.
• systems-engineering-safety/continued-airworthiness/ica-cmr-ali- classification: ALS/CMR items born with the type certificate, not post-cert directives.
• systems-engineering-safety/continued-airworthiness/msg3-maintenance- analysis: routine scheduled task derivation, distinct from mandatory directive action.
• systems-engineering-safety/certification/mmel-development: dispatch relief context when an aircraft is unairworthy.
• systems-engineering-safety/arp4754a/configuration-management: design change control for the type design that directives amend.

Pitfalls

• Comparing unpadded serials: "9" does not sort inside ("001", "050") under string compare, so aircraft serials and range bounds must share a zero-padded width before ad_applies is trusted.
• Measuring a calendar directive from the last action: the model's compliance clock runs from the AD effective date, (as_of - effective_date).days, so all aircraft in the fleet share the same calendar margin on a given as_of.
• Leaving grace in months for a calendar basis: the margin is in days (value_days - elapsed_days), so grace must be converted too, grace * 30.4375, or the band is 30 times too narrow.
• Reading a 0 compliance rate when nothing applies: compliance_rate is None for a zero-applicable review; a bare 0.0 would claim total non-compliance where no obligation exists.
• Calling a due aircraft compliant: due means the compliance point is already passed and action is required now, only the grace band keeps it out of the overdue class.
• Forgetting to reset the event counters: cycles_since_last_action and hours_since_last_action are since the last action, so they must be zeroed at the action before the next margin is computed.

Behavior contract (gate 3)

Run the deterministic contract test (stdlib unittest, offline):

python3 scripts/test_airworthiness-directive-compliance.py

The test covers the worked-example contract (remaining 500.0, -200.0, -550.0 and -17.5 / -502.5; fleet report applicable 4, open 2, due 1, overdue 1, rate 0.5), the applicability truth table including serial range bounds, the status boundaries (exactly 0 and exactly -grace are due), calendar day arithmetic anchored at 748 and 1233 elapsed days, the fleet identities, ValueError rejection of an unknown basis, non-positive value, negative grace, empty aircraft list and missing record keys, exact dict keys, and run-to-run determinism.

Compliance

• Standards referenced, not reproduced: FAR Part 25 frames the type design that directives amend; the compliance model above is standard engineering methodology, summary-only per standards-map.yaml. The directive text and the 14 CFR 39 / 91 rule text are never reproduced.
• compliance: STANDARDS-REF, gated: false.