Operations control centre
The flight that is about to break is already on the board. It is just not near the top.
Nexus Dispatch is decision support for the operations control centre. It reads the operation the way a dispatcher does — flight by flight, constraint by constraint — and sorts the board by risk instead of departure time, with the drivers behind every score visible. It does not release aircraft. It helps the person who does make a better-informed call, and it writes down what they decided and why.
Status Working demonstration surface over a working engine, running on seeded and public data. No airline is operating it.
The problem
A dispatcher working a bank of departures reads four to six systems that do not talk to each other: weather, crew legality, maintenance status, ATC constraints, gate and turn state. Each is authoritative about its own slice and blind to the rest. The flight that is about to break is on the board somewhere — it just is not near the top, because the board is sorted by scheduled departure.
The answer
Nexus Dispatch reads the same operational records the desk already has and re-sorts them by risk, with the reason chips that produced each score attached. When a flight needs a decision, the candidate recoveries are scored side by side against doing nothing, and the dispatcher’s choice — with the person, the time and the reasoning — is appended to a chained record that fails verification if anyone edits it afterwards.
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.
Every flight carries a 0–100 operational risk score with reason chips naming what is driving it — weather at destination, crew duty margin, maintenance status, ATC or flow constraints. The board sorts by exposure, so the flight most likely to break is the one you read first.
Open any flight and see the risk drivers, the recommendation, the timeline, crew and maintenance state, and passenger impact on one page — with approve, reject and note actions that append to an auditable trail rather than disappearing into a chat window.
Candidate recoveries are scored side by side against the do-nothing baseline on delay minutes, misconnects, crew legality, gate impact, cost and confidence. The comparison is the deliverable — the dispatcher chooses.
Ask the operation a question in plain language and get an answer assembled from the records, with its sources and a confidence note attached. With no model credential configured the analyst still answers, deterministically, from the records alone.
Advisory decisions are written into a chained record with a keyed signature. The chain verifies in the interface, and a record edited after the fact fails that verification — which is the entire point of having it.
Boundaries
Three questions any operator should ask before an evaluation, answered before you have to ask them.
Nexus Dispatch is decision support. It never releases an aircraft, never files or amends a flight plan, and never executes a recovery. Every recommendation requires a qualified human to approve it, and the approval — with the person, the time and the reasoning — is what gets written to the record. Dispatch authority and operational control stay exactly where regulation puts them.
The product reads flight, crew, maintenance and constraint records to score risk. In every current demonstration those records are synthetic; weather and published navigation data come from public services. Nothing is sent to a third party for scoring, nothing is retained for model training, and in an on-premises or controlled deployment the records never leave the operator’s boundary. Crew data is the sensitive part of this product and is treated as such: duty margin is shown as a constraint, not as a personnel file.
With no model credential the analyst answers deterministically from records — the normal demonstration configuration. If the public weather service is unreachable, the product falls back to clearly labelled synthetic observations rather than presenting stale data as current. If a record is unavailable, the flight is scored on what is present and the missing input is named rather than silently defaulted.
The same questions answered across the whole portfolio, with dates: trust & safety
Honest status · Pilot-ready
Working demonstration surface over a working engine, running on seeded and public data. No airline is operating it.
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 |
|---|---|---|
| The full dispatcher workflow — risk board, decision record, recovery comparison, analyst — runs end to end and can be exercised in a live session. | Evidence tier:Demonstrated | Demonstration surface, seeded carrier data. |
| Route planning uses real published navigation fixes rather than great-circle approximations. | Evidence tier:Demonstrated | Planning engine over a navigation database of published US fixes. |
| Weather comes from the public aviation weather service, not a fixture. | Evidence tier:Demonstrated | Live observation, forecast and advisory ingestion with a labelled synthetic fallback. |
| A decision record altered after it was written fails chain verification. | Evidence tier:Demonstrated | Hash-chained audit log with an in-interface verification and tamper test. |
| Risk scores and recovery costs shown in the demonstration are computed from synthetic fixtures and describe the demonstration, not an airline. | Evidence tier:Modeled | Seeded scenario data. |
Fair questions
These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.
You would not — adding a seventh screen to six would be a worse operation, not a better one. The argument for this product is that it consolidates the reading a dispatcher is already doing across systems into one ordering, and produces a record you currently reconstruct by hand. If it does not remove reading, it is not worth the desk space, and that is a fair thing to judge it on in a walkthrough.
Because a language model does not produce it. The score is computed by explicit rules over records, the drivers are listed next to it, and the same inputs produce the same score every time. You can disagree with the weighting — and in a pilot you would tune it — but you can always see what produced it.
That is the part we would open first. Decisions are chained and signed; the interface verifies the chain and includes a deliberate tamper test that fails on a post-hoc edit. What we do not have yet is SSO, role scoping and a retention policy, and those are named on this page rather than discovered in procurement.
Who buys this
The operators whose problem this product is actually shaped around. Each has its own path from first contact to a decision.
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.
On-demand and fractional operators flying short-notice missions where the schedule is written the night before and rewritten in the morning.
Directors and vice-presidents of operations accountable for network performance, disruption cost and the answer to what happened this morning.
Next step
Forty minutes, driven live on seeded data, ending with the risk drivers you would actually want scored in your operation — and what would have to be true to score them.