Disruption & passenger recovery
Legacy systems find a seat. Recovery means rebuilding the journey.
A bad night at a hub produces a rebooking line three hundred deep and two agents to work it. Reaccommodation is high-volume, time-critical, rule-bound and almost entirely mechanical — which makes it exactly the kind of work that should be solved for every passenger in parallel, not one at a time down a queue. Rebound does that, and shows its reasoning for each one so the agent stays in charge of the outcome.
Status MVP at the advisory tier on deterministic synthetic data. It proposes; an agent approves. It neither connects to nor writes to any live passenger service or distribution system.
The problem
When a flight cancels, every passenger on it becomes an independent constraint problem with a party size, a connection, a fare class, a loyalty tier, an accessibility need and a duty-of-care entitlement that depends on why the flight cancelled. Agents solve those problems sequentially under pressure, and the last passenger in line gets the options the first forty already took.
The answer
Rebound takes the affected manifest, prioritises it by exposure rather than by who reached the counter first, and solves every passenger in parallel across own metal, interline partners and nearby airports — honouring cabin, minimum connection time, party integrity and live seat inventory. It classifies the disruption cause, authorises duty of care only where it is owed, allocates finite hotel and transport against real limits, and hands the agent a ranked plan with a written reason on every decision. The agent approves. Nothing moves before that.
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 affected passenger is scored on connection risk, accessibility and medical need, unaccompanied minors, party size and loyalty — so the working order reflects exposure rather than arrival at the counter.
A layered solver works own metal first, then interline partners, then a nearby airport with ground transfer — honouring fare cabin, minimum connection time, live per-cabin inventory and keeping a travelling party together. Inventory is decremented on assignment, so the engine cannot oversell.
The engine classifies the disruption as carrier-controllable or not, then applies the rules that follow — hotel, meals and ground transport authorised only when owed. This is deliberately the most conservative module in the system: a wrong classification is either a lawsuit or a blown budget.
Contracted rooms, ground transport and meal budget are allocated in priority order against real limits, cascading to overflow and flagging a shortfall before the airline over-commits rather than after.
Passengers the solver cannot place are escalated to a human with the options already computed and the binding constraint named. There is no code path that invents a seat, and every automated decision carries a written reason.
Boundaries
Three questions any operator should ask before an evaluation, answered before you have to ask them.
Rebound operates at the advisory tier by design. It produces a ranked plan; an agent approves it. Nothing is booked, no entitlement is issued and no passenger is moved without a human decision. Higher autonomy tiers exist on paper and stay there until an operator, not a vendor, decides the policy thresholds in writing. The people working a disruption desk are not the problem this product solves — the queue is.
This is the one product in the portfolio whose real-world input is personal data: a passenger manifest, with names, parties, accessibility and medical needs, and loyalty status. Today every manifest is synthetic and generated from a fixed seed — no real passenger data has ever been in it. In a deployment the manifest would stay inside the operator’s environment, the engine would run against it locally, and nothing would be sent to a third party or retained for model training. Accessibility and medical flags drive prioritisation and are never shown as anything other than a priority reason.
The engine is self-contained and has no runtime service dependency, so it does not have a network failure mode: given a manifest it produces a plan. When inventory or contracted resources run short it does not degrade quietly — it allocates what exists in priority order and reports the shortfall explicitly, then escalates the passengers it could not place. A run is reproducible from its seed, so an outcome can always be re-derived afterwards.
The same questions answered across the whole portfolio, with dates: trust & safety
Honest status · MVP
MVP at the advisory tier on deterministic synthetic data. It proposes; an agent approves. It neither connects to nor writes to any live passenger service or distribution system.
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 |
|---|---|---|
| A complete disrupted manifest is solved in one run, with a scored plan and a written reason for every passenger. | Evidence tier:Demonstrated | Engine run across three synthetic disruption scenarios. |
| The solver cannot oversell — seat inventory is decremented on assignment and an unplaceable passenger is escalated rather than seated. | Evidence tier:Demonstrated | Inventory invariant enforced in the itinerary solver and checked on every scenario run. |
| Duty of care is authorised only when the disruption cause makes it owed. | Evidence tier:Demonstrated | Cause-based entitlement rules over US carrier obligations and contract of carriage. Not an EU model. |
| Runs are reproducible — the same scenario produces the same plan. | Evidence tier:Demonstrated | Seeded deterministic data generation; no unseeded randomness anywhere in the engine. |
| Every automated decision carries a written reason, including the entitlement decisions that authorise or withhold care. | Evidence tier:Demonstrated | A `why` string is emitted on each decision by the entitlement and solver modules. |
| Cost, misconnection and recovery figures produced by the engine describe synthetic manifests. | Evidence tier:Modeled | Synthetic network, manifests and contracted resources. |
Fair questions
These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.
No, and it is not designed to. It removes the mechanical part — searching inventory, checking connection times, working out what care is owed — and hands the agent a ranked plan with the reasoning attached. The agent still decides, still handles the exceptions the solver escalates, and still talks to the passenger. What changes is that the two-hundredth person in the queue gets the same quality of option as the second.
You should not take it on trust, and we would open the rules rather than the interface. Care is classified by disruption cause against US carrier obligations and contract of carriage; carrier-controllable causes owe care, weather and air-traffic causes do not. It is explicitly not an EU261 model, because under that regime care is owed regardless of cause — claiming otherwise would be wrong, so we do not.
Inventory is decremented on assignment and the invariant is checked on every run. When the engine cannot place someone it escalates with the constraint named and the options pre-computed. There is no path that fabricates availability, and that is a property of the engine rather than a promise in a brochure.
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.
Directors and vice-presidents of operations accountable for network performance, disruption cost and the answer to what happened this morning.
On-demand and fractional operators flying short-notice missions where the schedule is written the night before and rewritten in the morning.
Next step
We run a severe-weather scenario end to end — three cancellations, scarce seats — and stop on the passengers the engine escalates, because that is where you learn whether it is honest.