The Readiness Gateway sits between trip intent and booking execution.
TRIP INTENT
│
▼
TRAVELLER READINESS
│
┌────────────┬────────────┬──────────────┐
│ READY │ REVIEW │ NOT_READY │
└────────────┴────────────┴──────────────┘
│ │ │
▼ ▼ ▼
BOOK MITIGATE STOP
Ready. The traveller has completed the relevant readiness process and acknowledged the guidance. The downstream workflow can proceed.
Review. A condition requires further action or mitigation before the trip proceeds.
Not Ready. A defined operational or policy constraint prevents the workflow from proceeding under current conditions.
The Gateway does not book the trip.
It determines the state that the downstream booking workflow should receive.
Why pre-booking matters
Risk intervention traditionally happens at several points after an itinerary has begun moving through the enterprise workflow.
That creates avoidable friction.
Once an itinerary has been booked, changing it can mean:
- cancellation costs
- rebooking
- administrative intervention
- assistance-provider escalation
- policy exceptions
- traveller disruption
- increasingly difficult rollback for automated systems
Third Rail moves the readiness decision left.
The question becomes:
"Can this trip proceed?"
before the system commits to executing it.
Why the Gateway checks again at the point of booking
A Readiness Assessment and the actual booking are not always the same moment. A traveller can be assessed today and not book for another two weeks, during which the destination situation, the itinerary, or the traveller's own circumstances can change.
The Readiness Check, immediately after assessment, is the traveller receiving and acknowledging their guidance. The Readiness Gateway, at the point of booking, is a separate revalidation: has anything material changed since the assessment ran. Only after that revalidation does the Gateway emit the readiness state the booking workflow acts on.
This is what makes the architecture a point-of-booking control, not only a point-of-assessment one.
The canonical state machine
Ready
The defined readiness process has been completed and no blocking condition has been identified.
The downstream workflow may proceed according to enterprise policy.
Ready → Book
Needs Review
A condition requires human or specialist intervention before booking can safely proceed.
The traveller is routed into an appropriate confidential workflow.
Needs Review → Mitigate → Ready → Book
Third Rail does not become the medical, security or immigration provider.
It orchestrates the state transition.
Not Ready
A hard constraint or configured enterprise boundary prevents the itinerary from proceeding under current conditions.
Not Ready → Stop
Third Rail does not decide enterprise policy
This distinction is fundamental.
Third Rail produces the readiness assessment.
The enterprise determines the operational consequences of that state.
For example, an enterprise may configure:
Ready → permit booking
Needs Review → require assistance clearance
Not Ready → prevent booking
Another enterprise may implement different escalation rules.
The Gateway therefore acts as a control point, not an enterprise policy engine.
The integration contract
The Gateway is designed to consume relevant signals from the assessment and, where appropriate, the approval outputs of existing specialist compliance, immigration, assistance and enterprise policy systems. Those systems sit upstream and contribute approval outputs only; the travel management company and the online booking tool sit downstream and receive the Readiness State.
Examples may include:
- traveller readiness assessment
- destination context
- enterprise travel policy
- visa/immigration status
- assistance clearance
- other pre-booking conditions
These signals are normalised into a single machine-readable state.
That makes the architecture consumable by both today's travel stack and tomorrow's autonomous travel agents.
The state as a gate
The Readiness State is built for two kinds of consumer.
A person reads Ready, Needs Review or Not Ready and acts on it. A machine, increasingly a booking or travel-risk agent, reads the same three values as a workflow gate: Ready proceeds, anything else halts and hands back to a person.
An agent never needs the reasoning behind an assessment, because it is never the thing that resolves it. That reasoning deliberately never crosses the boundary. The opacity is the control rather than a limitation: an agent that cannot see a traveller's underlying context cannot weigh that context against schedule pressure and reason its way past the gate.
Third Rail controls for agents today. Serving them as first-class consumers of the state, with the schema shaped by a design partner's own workflow rather than settled in advance, is the next layer and not a shipped feature.
Where to read next
- The Third Rail Architecture: how the readiness layer fits together.
- The Minimum-Disclosure Data Boundary: what data crosses the boundary, and what does not.
- The Assessment Receipt: the evidence that the process occurred.