EASA Airworthiness Directive Delta

Durable monitor for the official EASA Safety Publications portal (ad.easa.europa.eu) — Airworthiness Directives (AD), Emergency ADs (EAD), Proposed ADs (PAD) and Safety Information Bulletins (SIB). You give it a fleet watch list — a manufacturer, a type designation, a specific AD number, an ATA chapter or a keyword — and it reports only what genuinely changed since your last run: a new publication matching your fleet, or a revision of one you already track. No API key, no login, no captcha.

Built for airlines and operators, CAMOs, MRO and part-145 organisations, lessors and asset managers, aviation insurers and airworthiness engineers — anyone who needs to know today that an AD touching their type has appeared or that the effective date of one they are planning around has moved.

This is an informational monitor of EASA publications. It is not an airworthiness management system, it does not confirm that a directive applies to a particular aircraft or serial number, and it does not replace the operator's or CAMO's own AD compliance process — reading the full publication, assessing applicability and meeting the deadlines remains entirely yours. A delay, a miss or an error of this monitor removes no regulatory obligation.

Cadence — read this before you buy

EASA publishes for the whole world, and the volume is modest. Measured live on 13.09.2026 against the portal itself, not estimated:

That is roughly 1–2 publications a day worldwide, and a watch list scoped to one fleet will see single-digit events per month — often zero in a quiet week. This product is deliberately built for a watch list, not for a firehose: if you want "every EASA publication", a plain scraper is cheaper. If you want "tell me when something touches an A320 or moves the date on AD 2026-0144", this is the right tool, and its value is precisely that most runs cost you nothing.

Revisions are a real, recurring signal, not a theoretical one: 313 of the 2290 publications in 2022–2026 carry a revision suffix (2026-0144R1), and effective dates and subjects of already-published items do get edited.

Source

https://ad.easa.europa.eu/search/ — the public search of the EASA Safety Publications portal. Verified live on 13.09.2026 from a plain HTTP client, no credentials of any kind:

• POST /search/ (form-urlencoded, fi_action=advanced, fi_date_start, fi_date_end) returns HTML containing Displaying records 1 to 20 out of a total of N publications. An empty window returns an explicit Sorry, no results found for your query instead.
• GET /search/?format=csv&r=<N>&sep=c returns text/csv; charset=utf-8 with a stable 7-column header:

  AD class, Class number, Issue Date, Subject, Approval Holder / Type Designation, Effective date, ATA Chapter
  . The export returns the N most recent publications of all classes, ordered by issue date descending; the portal caps a single export at 4000 records.
• Stable identifier: Class number (2026-0176, CF-2026-45, US-2026-17-08, SAIB-2026-16). Checked over the window 2022-01-01…2026-09-13: 2290 rows, 2290 unique numbers, no blanks. Each publication has a detail page at https://ad.easa.europa.eu/ad/<Class number>.
• Empty Effective date (231 of 2290) and empty ATA Chapter (218 of 2290) are normal data, not damage — the run only fails when a column disappears from the whole export.

How it works

1. The publication window is fetched once per run — two HTTP requests (the count, then the export) — and every watch filters that same in-memory snapshot instead of hitting the EASA portal 30 times for identical bytes.
2. The snapshot passes a fail-closed integrity gate before anything is classified: content type, strict UTF-8 decoding, exact header match, every row exactly 7 fields, the number of parsed rows must equal the number of publications the search page announced, every issue date must fall inside the requested window, the order must be non-increasing, and every publication number must be non-empty and unique. It also enforces an absolute floor proportional to the window and a drop threshold against the last accepted snapshot of the same window width. Any failure turns the whole run into source_access_limited: no baseline, no index update, no charge. A truncated but syntactically valid export must never be read as "these publications no longer exist".
3. Each watch names one target: approval_holder (substring of the manufacturer/type-designation column), ad_number (a number and all of its revisions), ata_chapter, or subject_keyword, with an optional adClasses filter. Whether a row matches is decided twice, independently — once from the normalised fields and once recomputed from the raw CSV cells — and a disagreement fails the watch closed rather than delivering (and charging for) a row that may not match your target.
4. The first check of a new watch establishes a baseline (no charge). Every later check compares the current match set against the durable record of what it was last time.
5. Billing material is the full publication row: class, number, issue date, subject, approval holder / type designations, effective date, ATA chapter — hashed as canonical JSON with a full SHA-256. For an airworthiness directive there are no "cosmetic" columns: a moved effective date, an - Amendment appended to the subject, a changed ATA chapter and a PAD becoming an AD are all real operational signals.
6. A value that changes and later reverts bills every genuine transition (A → B → A → B), never silently deduplicated against an earlier occurrence of the same state.
7. A publication leaving the window is never an event. The window slides, so a row ageing out is normal, not a withdrawal — the monitor emits no "removed" signal at all and leaves the index untouched.

Input

{
  "monitorId": "my-fleet-watch",
  "lookbackDays": 30,
  "watches": [
    { "watchId": "a320-fleet",  "targetType": "approval_holder", "targetValue": "A320" },
    { "watchId": "airbus-all",  "targetType": "approval_holder", "targetValue": "AIRBUS", "adClasses": ["AD", "EAD"] },
    { "watchId": "ad-2026-0144","targetType": "ad_number",       "targetValue": "2026-0144" },
    { "watchId": "ice-protect", "targetType": "ata_chapter",     "targetValue": "30" },
    { "watchId": "fuel-pumps",  "targetType": "subject_keyword", "targetValue": "fuel pump" }
  ],
  "notifyOn": "new_alerts",
  "webhookUrl": "https://example.com/hook"
}

• monitorId — the name of this monitor's durable history. Reuse the same value on every scheduled run; a new value starts a new, empty history and re-baselines everything.
• watchId is permanently bound to the target it was first used with (target type, value and class filter). Reusing a watchId for a different target fails the run with watch_config_mismatch instead of quietly hiding one target's history under another's.
• lookbackDays (1–365, default 30) — how far back the run looks. A wider window costs nothing extra but must stay under the portal's 4000-record export limit, and the run fails honestly if it would not.
• Up to 30 watches per run. Substring targets must be at least 3 characters — a shorter one would match nearly the whole export and turn the monitor into a firehose.

Output

Every delivered change is one dataset row: watchId, watchTargetType, watchTargetValue, adNumber, adFamily, adClass, changeType (new | revised), issueDate, effectiveDate, subject, approvalHolder, ataChapter, previousIssueDate, previousAdClass, previousContentHash, changeSequence, publicationUrl, contentHash, eventId. (Whether a row was actually charged is reported in coverage.recordsBilled and in the digest, not on the row itself: the row is written to the dataset before the charge is attempted, so a row can exist for an event that ended as charge_unknown — see the delivery guarantee below.)

Rows are written to two datasets: the run's default dataset, and a named durable dataset (easa-ad-<monitorId>) that survives across runs and is the source of truth for everything ever delivered. The key-value store record coverage reconciles every charge against every row — per-watch status and reason, the observation window, the accepted snapshot size, new vs revised numbers, records delivered and billed, and the claim journal size — and digest is a short human-readable summary written every run.

Pricing

Pay-per-event: you are charged only for a delivered change — a publication newly matching your watch list, or a revision of one you already track. Baseline runs, runs with no changes, and runs where the source could not be verified cost you nothing beyond platform compute.

Delivery guarantee — honest wording

The right to write a row and to charge for it is taken from a single atomic primitive (RequestQueue.addRequest(uniqueKey)) before any dataset write or PPE call, in a separate named claim journal (easa-ad-<monitorId>-claims) that is never consumed or cleaned. The guarantee this gives is at-most-once, not exactly-once: if a run dies after taking the right but before delivering, the event is closed as dataset_unknown / charge_unknown and is not retried — it can be lost, but it can never be delivered or charged twice. Losing an event was chosen deliberately over charging you twice.

Boundary of the guarantee: it holds per monitorId, for as long as that monitor's named storages exist. Boundary of migration: renaming monitorId, deleting its storages, or a change of the actor's storage prefix creates a new, empty claim journal — everything previously delivered becomes deliverable and chargeable again. Treat monitorId as permanent.

Only one run per monitorId may work at a time; a second concurrent run fails fast with lease_busy rather than racing it.

Limits and honest caveats

• Cadence is low (see the table above). Expect single-digit events per month on a fleet-scoped watch.
• Publication-level, not text-level. The monitor reads the publication list, not the PDF body of a directive. A correction inside the document that does not touch any of the seven published columns is invisible to it.
• No "withdrawn" signal. The monitor never claims a publication was removed or superseded; ageing out of the window is not an event, and we have not observed EASA deleting published items.
• Applicability is not determined. approval_holder matching is a text match on the published "Approval Holder / Type Designation" column — it is a filter, not an airworthiness applicability assessment against your serial numbers, modifications and STCs.
• A separately published revision arrives as new, because EASA gives it a new publication number (2026-0144R1). An ad_number watch follows the whole family, so you still get it under the same watch.
• Non-EASA states' publications that EASA republishes (CF-, US-, BR- prefixes and similar) are included exactly as the portal publishes them; the primary source for those remains the issuing authority.
• Up to 50 changes are delivered per watch per run; the rest are picked up by the next run, so a one-off spike cannot drain your budget.
• If the source is unreachable or its structure changed, the run fails as source_access_limited and charges nothing — silence from this actor is never proof that nothing happened. Check coverage.

Legal

EASA Safety Publications are official public documents of the European Union Aviation Safety Agency. This actor reads the public portal, does not bypass any access control, and adds no data of its own. It is an independent tool, not affiliated with or endorsed by EASA.