Network & executive operations
Dispatchers manage flights. Leadership manages a network — usually from a report about yesterday.
Where Nexus Dispatch serves the desk, Airline Operations Intelligence serves the floor above it. It answers the questions a director of operations actually asks — what is about to constrain the network, what did this morning cost us, what did we decide and why — from the same records, so the number on the executive screen and the number on the dispatcher’s screen mean the same thing.
Status Prototype surface built to industry-standard operational reporting schemas, running as a labelled simulation. No live data feed, no partner relationship.
The problem
Operational reporting is retrospective by construction. Leadership gets a deviation report after the deviation, a cost figure after the cost, and a decision history assembled from memory. The questions that matter — what is about to constrain us, and what will each option cost — arrive too late to be decisions.
The answer
The product sits on the operational record set and answers questions from it directly, naming the sources and stating a confidence. When a traffic-management programme lands, the predicted impact is computed and sequenced recovery options are scored against the do-nothing baseline. Approving one appends to the same chained record the dispatcher’s desk writes to — which is why the two altitudes never disagree about what happened.
What it does · 5 capabilities
Each capability below exists in the build described on this page. Anything planned rather than present appears under status, not here.
Ask why arrivals held this morning, or what it cost in additional track miles, and get an answer built from arrival records, route-conformance data, metering configuration and traffic-management advisories — each source named, with a confidence figure attached.
An advisory arrives, the predicted impact is computed — flights affected, misconnection exposure, delay distribution — and sequenced recovery options are scored against doing nothing. Approving one appends a chained advisory record.
A two-hour forward view of deviation risk per airport — holding, missed approach, diversion — scored by explicit rules with the drivers listed. It is the forward-looking inverse of a retrospective deviation report, and it is arithmetic, not prophecy.
Flight-object records and a chained decision trail that verify in the interface. Verify the chain, then run the tamper test and watch verification fail. For a procurement reviewer, that contrast is the whole argument.
Self-contained with relative paths and no mandatory external service, so it deploys to a subpath, its own host, or an environment where cloud services are not an option and inspection comes before trust.
Boundaries
Three questions any operator should ask before an evaluation, answered before you have to ask them.
Every recovery option, advisory response and traffic-management action in this product is advisory. Approval is a human act, recorded as one. The system’s job is to make the choice legible and the reasoning durable — not to make the choice.
The product reads operational reporting records — arrivals, route conformance, metering configuration, advisories. It holds no passenger data and no personnel records. Today every record is a labelled simulation seeded from published schemas; no live feed is connected. In a controlled deployment the record set and the decision chain stay inside the operator’s boundary, and nothing is sent outward for scoring or retained for model training.
With no reporting credential the adapter runs in simulation mode and the surface says so with a tier badge — that badge is the only interface difference between simulation and live, and it is deliberately not subtle. With no model credential the copilot answers from records deterministically. Ingestion is request-and-response, so a source that is unavailable produces a named gap rather than an interpolated answer.
The same questions answered across the whole portfolio, with dates: trust & safety
Honest status · Prototype
Prototype surface built to industry-standard operational reporting schemas, running as a labelled simulation. No live data feed, no partner relationship.
Claims and evidence
If a claim below is worded more strongly than its basis justifies, it is a defect and we want to hear about it.
| Claim | Tier | Basis |
|---|---|---|
| Operational questions are answered from named source records with a stated confidence, not generated prose. | Evidence tier:Demonstrated | Copilot surface over simulated reporting records; every answer carries its sources. |
| The adapter’s field names match a published operational-reporting schema, so switching to live services is a configuration change rather than a rewrite. | Evidence tier:Demonstrated | Schema-faithful adapter with a documented mode switch. Live parity is unverified until credentials exist. |
| The decision trail is tamper-evident and can be verified by a reviewer in the interface. | Evidence tier:Demonstrated | Hash-chained records; verification and tamper test both exercisable. |
| Deviation risk is scored deterministically — the same inputs produce the same score, every time. | Evidence tier:Demonstrated | Rule-based lookahead scoring over the record set. |
| Impact figures — flights affected, misconnection exposure, cost — are computed from simulated advisories and describe the simulation only. | Evidence tier:Modeled | Seeded traffic-management scenarios. |
Fair questions
These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.
It is a deterministic score over current conditions and published constraints, with the drivers listed — not a model output and not a probability. If conditions change, the score changes; if they do not, it does not. We would rather describe it as arithmetic you can re-run than as foresight you have to believe.
No, and we say so on the page. The adapter is written against a published specification, which anyone may read. There is no relationship with any reporting platform, airline system or air navigation service provider, and nothing on this site should be read as implying one.
Yes, and it is the deployment we would propose for an evaluation. The surface is self-contained with no mandatory outbound dependency, and the deterministic answer path means it works with no model credential at all. What you would be inspecting is ordinary software, not a service call.
Who buys this
The operators whose problem this product is actually shaped around. Each has its own path from first contact to a decision.
Directors and vice-presidents of operations accountable for network performance, disruption cost and the answer to what happened this morning.
Scheduled carriers running turboprop and regional-jet fleets, often on capacity-purchase agreements, with a real operations control centre and no eight-figure software budget.
Public-sector, defence and state operators whose data cannot leave their environment and whose decisions must be defensible on the record.
Next step
We open with the audit chain and the tamper test, then work backwards through the copilot and the lookahead. Bring the evaluator who is paid to be sceptical.