Raw NOTAM text, turned into filterable operational objects.
A0146/26 NOTAMR A0124/26 Q) HAAA/QFULT/IV/NBO/A/000/999/0858N03847E005 A) HAAB B) 2605050830 C) 2606060900 E) AERODROME FUEL SERVICE LIMITATION: 1.SCHEDULED OPERATORS:REFUELING SERVICE IS AVAILABLE WITH A MAXIMUM LIMIT OF 20,000 LITERS PER FLIGHT. 2.NON-SCHEDULED OPERATORS AND CHARTER FLIGHTS,JET FUEL IS NOT AVAILABLE DURING THIS PERIOD. ALL OPERATORS ARE ADVISED TO PLAN THEIR OPERATION CHECK TEXT NEW ENDING ADDED DRRRYFYX
One fuel NOTAM can mean different things for different operations. V2 keeps the scheduled-operator limit separate from the non-scheduled fuel outage so filters can evaluate each scope correctly.
- The scheduled-operator limit is represented as RESTRICTED, not as a total fuel outage.
- The non-scheduled and charter limitation becomes a separate UNSERVICEABLE fuel row.
- Traffic type conditions make profile filtering precise without hiding the operational nuance.
Built to identify critical issues. Affected Elements V2 is the structured layer underneath Notamify — the substrate that powers filtering, alerting, API responses, and flight-level intelligence.
Fuel service limited by operator type
Affected Elements V2 is the result of crossing 2.5 million processed NOTAMs.
That scale is what let us build comprehensive business logic grounded in real-world patterns — the schema reflects what actually shows up across millions of notices, not a handful of handpicked examples.
Three things V2 changes.
Filtering that reflects reality
Alerts, lists, and profile filters reason about actual operational applicability — aircraft type, permission state, operational use — instead of matching loose text.
One layer, not three partial tools
The same structure powers reading, filtering, alerting, API responses, and briefing logic. One substrate — so Notamify can be the only NOTAM solution you need.
Foundation for Skymerse
Flight-level intelligence needs structured applicability, not a prettier text summary. V2 is the operational substrate that makes Skymerse possible.
Stricter, cleaner, easier to consume.
The goal isn't prettier JSON. It's a stable operational layer that filtering, alerts, UI grouping, and Skymerse intelligence can rely on.
Identifiers come from context, not surface text
The model picks from the real object options present in the NOTAM context rather than echoing the noisiest token.
"identifier": "EPWA"
Conditions and exceptions are first-class
Who it applies to, who is exempted, and what is required all live in structured clauses instead of free prose.
"conditions": [...], "exceptions": [...]
Changes use from/to operand lists
One consistent change shape replaces the old split value fields — easier to consume downstream, easier to reason about.
"from": [],
"to": [{ "kind": "VALUE", ... }]No invented semantics
When a NOTAM implies a change but doesn't publish a concrete comparable payload, details stays — semantics stays null.
"semantics": null
Designed API-first. SDK speaks V2 natively.
The semantics payload isn't an afterthought — it's the primary contract. Our SDK exposes conditions, exceptions, and changes as typed objects, so filtering down to the NOTAMs that actually apply to your operation is a few lines of code.
import os from notamify_sdk import NotamifyClient client = NotamifyClient(token=os.environ["NOTAMIFY_API_KEY"]) for notam in client.notams.active({"location": ["KLGA"], "per_page": 30}): for el in (notam.interpretation.affected_elements if notam.interpretation else []): helicopter_only = any( c.dimension == "aircraft_type" and c.operator == "EQ" and isinstance(c.value, list) and c.value == ["HELICOPTER"] for c in (el.semantics.conditions if el.semantics else []) ) if el.type == "AERODROME" and el.effect == "CLOSED" and helicopter_only: print(notam.notam_number, el.identifier, el.effect)
Presets sit on top of affected elements.
Presets turn common operational roles into reusable filtering context. Start with an affected element from the V2 interpretation, then apply a profile such as Commercial Airline IFR, GA VFR, or Helicopter HEMS on top of it to evaluate operational applicability.
The preset is not inside the affected element and is not part of the interpreted object. It leaves type, subtype, identifier, effect, and semantics intact, then adds profile context for matching and review. The same layer is coming soon to NOTAM page filtering.
Profile-aware filtering, inside Notamify, and in...
Alerts and affected elements filterable by operational profile — not just by airport and category. Profiles live in Notamify Pro; the new alerting and filtering run inside the Notamify Operating System.
Configure multiple operational profiles matched to your fleet, role, and mission. Each profile reasons about applicability from the structured V2 payload — not loose text.
Profile-aware alerts and filters land in the operations dashboard — scoped by real applicability, not just airport and category.
Read about Notamify Operating System
Flight-level intelligence needs structured applicability — not a better text summary.