Traveller decision support
Nobody loses sleep because they cannot see their aircraft.
This is the one product in the portfolio aimed at the passenger, and it is the least mature by a wide margin. It exists to test a single idea before anyone spends money on flight-data licensing: that travellers are not short of aircraft-position maps, they are short of an answer to what happens to me next. Every screen runs on fixtures, and the prototype says so on every screen.
Status Phase-zero clickable prototype on mock data. No live flight feed, no accounts, no backend. The prototype labels itself as mock data on every screen.
The problem
What is not solved is the moment a traveller realises something is wrong and has no idea what it means — whether the connection still works, whether to run, whether to book something else now or wait, and what to tell the person waiting at the other end.
The answer
The prototype scores a connection rather than reporting it, and exposes the levers that move the score — a slipping inbound, a gate change, a checked bag. It separates a late inbound aircraft from a weather hold from a crew issue, because the cause determines what a traveller should actually do. Every panel shows its source, its freshness and its confidence, and the assistant hands the action back rather than taking it.
What it does · 4 capabilities
Each capability below exists in the build described on this page. Anything planned rather than present appears under status, not here.
A connection is scored rather than reported, with scenario levers — if the inbound slips, if the gate moves, if a bag is checked — that visibly move the score and change the recommendation.
The prototype distinguishes a late inbound aircraft from a weather hold from a crew issue, because the cause is what determines what a traveller should do next.
That line is the product thesis, not a disclaimer. An assistant that hides its uncertainty when a traveller is stressed is worse than a map that admits it is only a map.
A read-only card for the family member, driver or assistant tracking someone else’s flight, plus airport-side detail like security waits and gate walking times.
Boundaries
Three questions any operator should ask before an evaluation, answered before you have to ask them.
The assistant never rebooks, never purchases and never acts on a traveller’s behalf. It explains the situation, states how confident it is and how fresh its information is, and hands the decision back. For a product whose whole value is trust under stress, that boundary is the product.
The prototype has no accounts, no backend and no persistence — there is nowhere for personal data to go, and none has ever been in it. Every trip, traveller and roster on screen is a fixture. A real build would hold trip and itinerary data and would need a proper data-protection design, including what a watcher view is allowed to show about someone else’s travel; that design does not exist yet and is not implied by the prototype.
Not applicable in a meaningful sense, and it would be dishonest to describe one: with no live feed there is nothing to lose. A real build would need a defined behaviour for a stale or unavailable feed — showing the last known state with its age, never a confident answer built on nothing — and that behaviour is a design requirement rather than a shipped feature.
The same questions answered across the whole portfolio, with dates: trust & safety
Honest status · Prototype
Phase-zero clickable prototype on mock data. No live flight feed, no accounts, no backend. The prototype labels itself as mock data on every screen.
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 intended experience can be walked end to end and reacted to. | Evidence tier:Demonstrated | Clickable prototype, fixtures only. |
| Connection risk, delay causes and every other number in the prototype are fixtures, not predictions. | Evidence tier:Concept | All screens read from a single mock data file. |
| The interface is provider-agnostic — a normalised feed drops in behind the same shapes without changing the screens. | Evidence tier:Concept | Single data module behind every screen, by construction. Unproven until a provider is connected. |
| The gating risk is commercial rather than technical: flight-data licensing must be resolved before a real build. | Evidence tier:Modeled | Provider cost review against the polling volume push alerts would require. |
Fair questions
These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.
Because leaving it off would misrepresent the portfolio. It is labelled CONCEPT, it says mock data on every screen, and the honest reason it has not been built is a commercial one we have not solved. A vendor who only shows you their strongest product is telling you something about the other ones.
A flight-data provider on terms that survive the polling volume that push alerts require, and a data-protection design for the personal data a real build would hold. Both are named on this page. Neither is code.
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.
Airport operators and fixed-base operators responsible for the weather information that reaches pilots and operations staff on the ground.
Next step
Most useful as a conversation about what your passengers actually ask you during a disruption. If you have that data, it is worth more than the prototype is.