Operations & Scheduling Systems
A disruption starts with a flight: cancelled, diverted, or delayed beyond what your policy tolerates. Nexa learns about it from two kinds of source at once, and treats them as a single stream of evidence:
- Nexa's own flight-data platform — always on, for every tenant. It follows live flight status from multiple commercial feeds and adds a predictive layer that flags flights at risk hours before the call is made. See Flight data.
- Your operations and scheduling systems — your OCC, flight-operations, or scheduling suite. This is where the decision to cancel or divert is actually taken, often before any public feed shows it, together with the reason and the operational context.
Connecting your operations system is optional — Nexa works from day one on its own flight data — but it makes Nexa act on your decision, at the moment you take it, with your reason codes.
How multiple sources become one disruption
Every source is a pluggable signal adapter that normalizes its own format into one canonical flight signal. Nexa runs many adapters concurrently and reconciles them:
- One flight, one disruption. Signals are deduplicated on flight + kind of event, not on which system sent them. Your OCC's cancellation and the public feed's cancellation for the same flight collapse into a single disruption.
- Confirmed beats predicted. A predicted cancellation opens the disruption in a predicted state (inventory can be pre-staged); a confirmation from your system promotes it.
- Retractions are first-class. If your OCC reverses a cancellation, the retraction flows through the same path and the disruption is stood down.
- Fail-soft per source. One source going quiet never blocks the others. Source health is visible to your administrators.
- Stale events are rejected. An event older than your configured staleness window is ignored rather than acted on late.
You decide what counts as a disruption
Classification is policy, configured per airline, not code:
| Setting | Default | Example |
|---|---|---|
| Cancellation opens a disruption | Always | — |
| Diversion opens a disruption | Always | The diversion airport becomes the airport of care. |
| Delay threshold | Off until you set it | 180 minutes. |
| Delay threshold per flight phase | — | Stricter before departure than once airborne. |
| Delay threshold per airport | — | A lower threshold at a hub with scarce late-night hotel inventory. |
| Ignored sources | None | Mute a source during a planned migration. |
| Signal staleness window | 24 hours | Ignore events older than 2 hours. |
What Nexa reads from an operations system
| Data | Why |
|---|---|
| Flight status changes: cancellations, diversions, delays, retractions | The disruption trigger itself. |
| Estimated and actual times (off-block, take-off, landing) | Flight phase; delay magnitude. |
| Disruption reason codes | Entitlements (e.g. extraordinary circumstances under EU261) and scope. |
| Aircraft / tail changes | Context for operators; swap-driven delays. |
| The day's schedule | Pre-loading the flights your operators will see on the board. |
The full field list is in Data requirements § Disruption event.
Channels
An operations connector uses whatever your system offers, per the connector delivery model:
- Pull — Nexa polls the system's API for flight and schedule changes, within the rate limits it publishes.
- Push — the system (or your integration layer) calls the Partner API on each status change.
- Stream — Nexa subscribes to an operational event stream if one exists.
Onboarding checklist
- Share the operations / scheduling system's API documentation and a test account.
- Agree the reason-code mapping onto Nexa's canonical reasons.
- Set delay thresholds (global, per phase, per airport) in your tenant policy.
- Run a sandbox day: a replayed operational day with cancellations, a diversion, a delay crossing threshold, and a retraction.
- Switch the connector from mock to live.
Where to next
- Flight data — Nexa's own flight-status and prediction platform.
- Data requirements — the canonical fields.
- Airline systems (PSS / DCS) — manifests and PNRs.