How disruption handling works in the Activity Travel Protocol

Every travel business has a disruption protocol. Some of it is written down. Most of it exists in the heads of experienced staff who have handled enough weather cancellations, delayed coaches, and unreachable travellers to know, roughly, what to do next. The protocol is real. It is just not machine-readable.

The Activity Travel Protocol makes disruption handling a first-class part of the booking lifecycle — defined, enforced, and traceable from the moment something goes wrong to the moment it is resolved.

what disruption actually costs

A typhoon is forecast to make landfall near a resort area in two days. A regional destination management company has 340 active bookings with departure dates in the affected window. Each booking involves multiple suppliers: hotels, activity operators, transfer companies, equipment rental shops.

Under the current model, the DMC operations team begins a process that will occupy their entire staff for the next 48 hours. Each booking must be reviewed individually. Each supplier must be contacted separately. Each traveller must be notified through whatever contact method was captured at booking time — email here, WhatsApp there, a phone number that may or may not still be current. Commercial terms for cancellations must be checked booking by booking against whatever agreement was signed months earlier.

By the time the typhoon makes landfall, some bookings have been cleanly cancelled with full refunds processed. Others are in an uncertain middle state — the hotel has been notified but the ski school has not. Others have travellers who have not responded to any contact attempt and may or may not already be in transit. The operations team has no single view of which bookings are resolved, which are in progress, and which are at risk.

This is not a failure of effort. It is a failure of infrastructure.

why existing systems cannot propagate disruption

The root problem is the same one identified in the Booking Object post: there is no shared runtime entity that all parties in a booking can observe and act upon. Each supplier system knows about its own component. None of them know about the booking as a whole.

A disruption event is, by definition, a change that affects multiple parties simultaneously. A typhoon does not cancel one hotel booking — it affects every booking for every supplier in the affected region, all at once. But each of those affected bookings exists in a different system, with a different API, a different notification model, and a different cancellation terms structure. There is no mechanism to say: "declare a disruption event, propagate it to all affected bookings, trigger the appropriate response protocol for each one."

Existing itinerary platforms can display disruption information once a human has entered it. They cannot initiate the response automatically.

disruption as a protocol state

The Activity Travel Protocol treats disruption as a formal Booking Object state, not a special case handled outside the system.

When conditions indicate that a booking cannot proceed as planned, the Booking Object transitions to DISRUPTION_REVIEW state. This transition is triggered by a declared DisruptionEvent — which can originate from a supplier, an operator, a weather data feed, or an AI agent that has assessed the situation and determined that escalation is required.

The DISRUPTION_REVIEW state activates a defined response protocol:

Supplier notification. All suppliers with active components in the affected Booking Object receive a disruption notification through the protocol. They do not need to be called individually. The Booking Object is the shared reference — every party observing it can see that it has entered DISRUPTION_REVIEW and can access the DisruptionEvent declaration that explains why.

Human escalation path. The Human Escalation Manager — the protocol's mechanism for bringing a human into the loop — is invoked for decisions that exceed the AI agent's declared authority. Weather cancellations require a human decision on the rebooking offer. The HEM presents the structured situation to the operator and records the decision against the Booking Object's event log.

Traveller notification sequencing. The protocol defines when traveller notifications can be sent. Critically, notifications communicating disruption outcomes cannot be sent until the operator decision is finalised. An AI agent cannot notify a traveller that their booking is cancelled before the cancellation decision has been confirmed by a human. This is a NeMo Guardrails enforcement rule, not a convention — the agent is technically blocked from sending the notification early.

TRAVELER_UNREACHABLE chain. If the traveller cannot be reached during a disruption — a situation with genuine welfare implications — the protocol defines a six-step escalation chain (TU-1 through TU-6) that systematically expands the contact effort, escalates to the operator, and ultimately involves emergency contacts if the traveller remains unreachable. Every step is recorded in the immutable event log.

Commercial terms execution. Pre-Arrangement Declarations between suppliers and operators include disruption protocols: what each party does when a disruption event is declared, on what timeline, and with what commercial consequence. These terms are machine-readable — they feed directly into the disruption response, rather than requiring a staff member to locate and interpret a PDF contract.

what the 340-booking typhoon looks like with the protocol

The DMC's system declares a DisruptionEvent covering the affected geographic region and date range. The system identifies all 340 Booking Objects whose components intersect with the disruption scope. Each Booking Object transitions to DISRUPTION_REVIEW.

The AI agents monitoring those bookings begin the structured response in parallel — not sequentially. Supplier notifications go out through the protocol. The HEM queue fills with the decisions that require human confirmation: the 47 bookings where the traveller is already in transit and rebooking requires operator judgment. The other 293 bookings where the cancellation terms are unambiguous proceed through the defined response protocol automatically.

The operations team works the HEM queue — 47 decisions, clearly presented, with all context available in the Booking Object. They do not spend time locating contracts or making supplier calls. By the time the typhoon makes landfall, every booking is in a defined state: resolved, cancelled with confirmation sent, or in a human-reviewed exception process.

Disruption handling is not a separate workflow bolted onto the booking system. It is a protocol state, with a defined entry condition, a defined response sequence, and a defined exit criteria. That is what makes it possible to handle 340 disruptions in parallel rather than sequentially.