[PROJECT] NOTAM Intelligence Platform
A pilot-first NOTAM briefing platform that cuts through the noise. AI-powered classification on a SOLID architecture — built for professional aviation.
Executive Overview
[PROJECT] is a NOTAM intelligence platform built for professional aviation — airline pilots, dispatchers, AOC operations teams, and OCC staff. It solves the single most complained-about problem in aviation briefing: critical information buried in 100+ pages of raw NOTAM text.
The platform ingests all NOTAMs relevant to a flight through a deterministic processing pipeline — structured parsing, rule-based time validity checking, and Q-code lookup — with no AI involved in any safety-critical decision. AI is used only to generate human-readable summaries and 7-word headlines for display. Impact ratings, time validity verdicts, and the Primary vs Dark NOTAM split are all produced by auditable, testable code.
The architecture follows SOLID design principles — ensuring every component has a single responsibility, extension points are built in without modification, data sources and models are substitutable, different consumers get different views, and high-level pilot needs are decoupled from low-level NOTAM format details.
The results are presented in a dashboard of airport health cards — a visual, scannable, colour-coded interface. Raw ICAO text remains always accessible. A map layer plots NOTAMs geographically. Push alerts fire when new NOTAMs arrive for saved routes.
Volume & signal/noise
Critical NOTAMs invisible in walls of text. Existing tools index — they don't triage.
AI has no role in safety decisions
Time validity, impact rating, and Primary vs Dark split are determined by a rule engine. AI translates for display only.
SOLID middleware
Modular, extensible, substitutable components. Fix it in the middle — no changes to 193 countries' NOTAM systems.
Problem Statement
The Big Problem
A long-haul international flight can generate 100–200 pages of NOTAM text in a standard OFP briefing package. The format — unchanged since the teletype era — presents all NOTAMs in flat, uppercase, heavily abbreviated text with no visual hierarchy, no prioritisation, and no differentiation between a runway closure and a telephone number change.
Annual NOTAM issuance has grown from approximately 500,000 in 2007 to over 2 million by 2022. The Q-code system designed to categorize NOTAMs has 13,783 possible combinations, with 20–47% of NOTAMs using the catch-all code XX/XXXX. Approximately 20% of the ~35,000 active global NOTAMs at any time violate existing rules by persisting beyond the 3-month maximum.
Why existing tools fail
| Tool | What it does | What it doesn't do |
|---|---|---|
| Jeppesen FliteDeck | Curated, validated global NOTAM database. Reliable data. | No AI triage. Flat text dump. No visual hierarchy. Enterprise pricing. |
| Lido (Lufthansa Systems) | Industry-standard OFP with integrated NOTAM section. | NOTAMs appended as plain text. No sorting. No filtering. Unchanged for decades. |
| ForeFlight | Excellent GA/corporate app. Good map layer. Clean iOS UI. | Raw text NOTAMs. Not targeted at airline ops. No AI interpretation. |
| FAA NOTAM Search | Authoritative US government source. Free. | Web only. Zero visual design. No filtering intelligence. US-centric. |
No existing tool combines: (1) global NOTAM coverage, (2) AI-powered triage and plain-English decoding, (3) a beautiful dashboard-style interface, and (4) real-time push alerts — in a single product built for professional aviation. That gap is the product.
SOLID Architecture Principles
The system architecture is designed around SOLID principles to ensure modularity, extensibility, and adoptability. Each principle maps directly to a design decision.
| Principle | Definition | Application |
|---|---|---|
| S | Single Responsibility — Each component has one reason to change. | Parser only parses. Rule engine only classifies. AI only summarizes. Renderer only formats output. Each independently testable and replaceable. |
| O | Open/Closed — Open for extension, closed for modification. | New tags added without code changes. Matrix configurable per airline. LLM swappable (Claude, GPT-4o, open-source). Output format pluggable (cards, PDF, EFB-native). |
| L | Liskov Substitution — Subtypes substitutable for base types. | Any NOTAM source (EAD, FAA, DINS, Notamify) produces compatible input. Any LLM conforming to the tag+summary contract can substitute. Notam Store and Notam App share the same interface. |
| I | Interface Segregation — No client depends on methods it doesn't use. | Primary briefing shows only critical NOTAMs. Dark appendix holds the rest. Different airport types (Dep/Dest vs Alternate vs FIR) get different filtered views. Pilots never consume interfaces they don't need. |
| D | Dependency Inversion — Depend on abstractions, not concretions. | Pilot needs (51 tags) define the abstraction. AI + rule engine translates from any low-level NOTAM format. 193 countries don't need to change anything. The middleware inverts the dependency from source-format to pilot-need. |
Dependency Inversion is the crown jewel. Previous industry attempts to fix NOTAMs at the source level failed because they required cooperation from 193 countries. The middleware approach inverts this dependency entirely — the AI abstraction layer absorbs source variation so pilots depend on the tag taxonomy, not on how any individual country writes their NOTAMs.
Processing Pipeline
The system uses a deterministic-first, four-step pipeline. Safety-critical decisions (time validity, impact level, Primary vs Dark classification) are made by auditable rule engine code. AI is called only at the final step for display-layer summarization.
Fetch & Parse (Deterministic)
Pull NOTAMs for all relevant ICAO locations (departure, destination, alternates, FIRs). Parse every field into strongly-typed structs. B/C dates are Date objects, never strings. Hard error on parse failure — never silent partial data.
Rule Engine Classification (Deterministic)
Time validity using role-specific reference times. Q-code lookup table assigns impact level. Cross-NOTAM synthesis for combined verdicts. Keyword index on E) field for upgrade-only overrides. Zero AI involvement.
Matrix Sort (Configurable)
Rules Matrix matches airport types (4 tiers) with NOTAM tags (51 tags across 9 categories). Each intersection determines Primary vs Dark. Fully customizable per airline. The "Dark NOTAMs" concept — briefing split into Primary section and Dark appendix.
AI Summary (Display Only)
LLM generates a 7-word headline and plain-English paragraph for each NOTAM. This is translation, not classification. A wrong summary is visible and recoverable — the pilot reads the raw text. A wrong classification is not recoverable. Different risk category entirely.
51-Tag Taxonomy
The tag taxonomy is derived from extensive pilot and dispatcher input on what operational categories matter most during pre-flight briefing. 51 tags across 9 categories, each designed to be self-evident and group NOTAMs of roughly equal criticality. In this product, tags are derived deterministically from Q-code patterns — not assigned by an LLM.
| Category | Tags | Covers |
|---|---|---|
| Airport | Closed/Hours, Restriction, Fire, Fuel, Apron, Facilities, Procedure, VIP | Airport-level closures, operational restrictions, fire services, fuel, apron, procedures |
| Approach | Not available, Degraded, Change, Arrival, Departure | ILS/VOR/DME/RNP status, STAR/SID changes, minima, circling |
| Runway | Closed, Length, Strength, Lights, Condition, Note | Closures, TODA/TORA/ASDA, PCN, lighting, surface conditions |
| Taxiway | Closed, Restricted, Lights, Condition, Note | Closures, weight restrictions, lighting, surface, markings |
| ATC | Hours, Procedure, Flow/Delay, Radio, Radar, Met | Operating hours, procedure changes, flow control, frequencies, radar/ADS |
| Airspace | Route closed, Route restricted, Route change, SUA, Special route, Structure, Navaid | Route availability, restricted areas, military airspace, navigation aids |
| Hazards | Activity, Explosives, Firing, New obstacle, Obstacle light, Wildlife, GPS | Nearby activity, ordnance, obstacles, bird activity, GNSS interference |
| Library | Trigger, Checklist, AIP change, Chart change, FPL, State rule, Security | AIP amendments, chart changes, flight plan requirements, regulations |
| Navigation | VOR, NDB, DME, ILS component | Individual navaid serviceability outside Approach tags |
Rules Matrix & Dark NOTAMs
Four-tier airport classification
| Tier | Airports | Default filter level |
|---|---|---|
| Tier 1 — Dep/Dest | Departure and destination | Most permissive. Nearly all categories in Primary. Only Hazards/Library may go Dark. |
| Tier 2 — Dep/Dest Alt | Departure and destination alternates | Moderate. Taxiway closures, obstacle lights, Library items go Dark. |
| Tier 3 — Enroute Alt | Enroute alternate airports | Aggressive. Only Approach, Runway, and critical Airport tags in Primary. |
| Tier 4 — FIR | FIR/enroute NOTAMs | Most aggressive. Only Route restrictions, GPS, ATC Comms in Primary. |
Dark NOTAMs philosophy
Borrowed from aircraft design where warning lights only illuminate when attention is needed. NOTAMs filtered to the Dark appendix are not hidden or deleted. They remain available with their tag and a one-line summary. Crews focus on Primary and reference the appendix only if needed. This preserves regulatory compliance while solving the information overload problem.
Correctness Guarantee
During real-world OFP analysis, an LLM incorrectly flagged an alternate airport as critical by comparing a runway closure end time against the destination ETA rather than the alternate-specific ETA. The error was confident, plausible, and wrong. This section defines the architecture that prevents that class of error entirely by removing AI from all safety decisions.
Where AI is and is not permitted
| Decision | Made by | Rationale |
|---|---|---|
| Is this NOTAM active at the relevant time? | Rule engine | Wrong answer is a safety failure. Date comparison is deterministic. |
| What is this NOTAM's impact level? | Q-code table + keywords | Wrong answer is a safety failure. Table is finite and auditable. |
| Primary or Dark? | Rule engine + Matrix | Wrong answer loses a critical NOTAM. Deterministic rules only. |
| What colour is the health indicator? | Aggregated rule output | LLM never sets a colour. Derives from Layer 1/2 verdicts. |
| What does this NOTAM mean in plain English? | AI — display only | Wrong answer is visible. Pilot reads raw text. Disclaimer shown. |
| What is the 7-word headline? | AI — display only | Wrong headline is inconvenient. Wrong impact rating is dangerous. |
Every safety-critical decision is fully unit-testable with no mocks. Real OFP data becomes the regression test suite. This runs in CI on every commit. An LLM cannot make that guarantee.
V1 Feature Specifications
Flight Route Input
Route string, ATC FPL, or manual airport selection. Auto-determines full ICAO location set across 4 tiers. Saved routes with one-tap refresh.
AI Plain-English Summary
7-word headline + full decode for every NOTAM. Tag from 51-tag taxonomy. Batched API calls, ~20s for full briefing. Raw text always accessible.
Airport Health Dashboard
Colour-coded cards per airport. Category icons. NOTAM counts by severity. Primary/Dark split. The signature UX — scan 6–8 airports in seconds.
Push Alerts
Post-briefing monitoring. New/changed/cancelled NOTAMs trigger push with AI summary + impact level. Configurable per route and category.
Map View
Route line with geolocated NOTAM markers. Polygon overlays for TFRs and restricted areas. Colour-coded by impact. Synced with list view.
Raw ICAO Text Access
Non-negotiable. Raw text reachable in ≤2 taps from any view. Full Q/A/B/C/D/E/F/G structure. Monospace, unmodified. Copy & share via iOS sheet.
Design Principles
Scannability over completeness
A pilot on a crew bus needs to understand the picture in under 60 seconds. Every design decision is measured against this.
Trust through transparency
AI summaries clearly labelled. Raw ICAO text never more than 2 taps away. We earn trust by never hiding the source data.
Dark by default
Aviation cockpit. Night operations. iPad in low-light. Dark-mode first — not an afterthought. At home next to a PFD.
Colour means something
Red = critical. Amber = important. Green = clear. Grey = no NOTAM. Consistent everywhere. Never decorative.
Professional, not clinical
Built to the standard of the best consumer iOS apps, not enterprise software from 2005. The interface is the competitive moat.
Progressive disclosure
Dashboard card → expanded list → AI decode → raw text. Users go as deep as they need. Never forced to start at raw text.
Platform Strategy
| Platform | Priority | Target | Rationale |
|---|---|---|---|
| iPad (iPadOS) | Primary | V1.0 | Primary EFB device. Largest screen. Best dashboard showcase. |
| iPhone (iOS) | High | V1.0 | Same SwiftUI binary. Essential for push alerts and quick checks. |
| Web App | Medium | V1.5 | Dispatcher/OCC desktop use. Same backend API. React/Next.js. |
| API / B2B Middleware | B2B | V2.0 | Expose tagging pipeline for AOCs and flight planning providers. |
Success Metrics
"Did the pilot find what mattered before it mattered?" — measured as the percentage of users who report the critical NOTAM for their flight was visible at the top of the briefing without searching. Target: ≥90%.
Risks & Mitigations
| Risk | Severity | Mitigation |
|---|---|---|
| Rule engine error in Q-code table or keyword list | High | Every entry reviewed by a pilot. Real OFP regression test suite. Table version-controlled and change-reviewed. |
| NOTAM data source latency or outage | Medium | Multi-source strategy. Clear staleness indicators. Degrade gracefully with cached data. |
| AI summary produces misleading decode | Medium | AI is display-only. Does not affect impact rating, Primary/Dark, or health card colour. Labelled "AI summary." Raw text one tap away. |
| LLM API costs unsustainable at scale | Medium | AI called only for E) field summarization. Cache by NOTAM ID hash. Fallback to Q-code-derived plain text on cost spike. |
| Regulatory or liability concern | Low | Deterministic architecture is auditable and reproducible. Clear disclaimer. Raw text always accessible. Legal review before launch. |
Roadmap
Timeline is indicative — assumes solo development by one pilot-developer, part-time alongside flying duties.
Foundation
Finalize tag taxonomy through expert review. Build deterministic parser + rule engine with full unit test suite. Q-code lookup table (~1,000 entries). AI summary layer comparison (Claude vs GPT-4o). Dashboard card component (SwiftUI). Backend skeleton.
Validation
Circulate PRD to industry experts. Run accuracy benchmarks against diverse international NOTAMs. Pilot testing with volunteer flight crew. Iterate on Matrix defaults and tag definitions. Internal TestFlight.
Integration & Beta
Push notifications (APNs). Map view (MapKit). Multi-source fallback. Public TestFlight beta. Accuracy audit (100 NOTAMs manual). Privacy policy + App Store listing. Monetization decision.
Launch & Expansion
App Store submission. Web app for dispatcher/OCC. B2B pilot programme. API/middleware offering. Flight planning provider integration trials. ICAO engagement for formal recognition.
Open Questions
- What is the project name? Should convey precision and clarity. Must not imply "AI-powered" since the safety layer is explicitly not AI. Available as App Store title and domain.
- Who authors the Q-code impact table? The ~1,000-entry table is the primary safety artefact. Must be authored by a qualified pilot and reviewed before each release.
- Which LLM for E) field summarization? Lower-stakes decision now that AI only translates, not classifies. Run 100-NOTAM comparison for quality and cost.
- What is the monetization model? Deterministic architecture reduces LLM costs significantly. Free/freemium more viable than originally assessed.
- Which NOTAM data source for production? Notamify V2 for development. Understand rate limits before committing. Raw text always takes precedence over pre-parsed fields.
- How should "cleared by ETA" NOTAMs be presented? Time-expired NOTAMs are a distinct category. Should not appear in Primary, but also should not silently disappear.
- Standalone backend or serverless? Rule engine runs server-side to keep Q-code table current without app updates. FastAPI on Railway (~$7/mo) vs AWS Lambda.