Third Rail separates the question:
"Is this traveller ready?"
from:
"Which system books the trip?"
The answer to the first question comes from Third Rail.
The second remains with the enterprise's existing infrastructure.
Identity verification is the entry gate
Identity verification is the entry gate, not a closing formality. Before a Traveller Readiness Assessment can be created at all, the traveller is verified against the chip in their own passport through IdentiGate. That verification returns a verified-person assertion held on the traveller's own device. Third Rail keeps no record of it.
This is the control that keeps the gate honest. No verified person, no assessment. A non-human actor cannot originate an assessment on a traveller's behalf.
The same assertion then stands behind every signature in the flow: the traveller signs the Readiness Check as the person verified at entry, and signs again at the Check-Back before booking. One verified identity, two signatures, no identity record held by Third Rail.
Current enterprise stack
Traveller
│
▼
Trip Request
│
▼
Third Rail
Traveller Readiness
│
▼
Ready / Needs Review / Not Ready
│
▼
Enterprise Workflow
│
├── OBT
├── TMC
├── Travel Agent
├── Expense / Trip Request
└── AI Travel Agent
The direction of flow
Specialist compliance tools sit upstream of the Readiness Gateway. Visa, immunisation and destination screening systems contribute their approval outputs, and only their approval outputs. Third Rail never ingests the underlying data behind them.
The travel management company and the online booking tool sit downstream. They receive the Readiness State and act on it. Third Rail ingests nothing from either.
The identity primitive is offered to the tools already in this space as shared infrastructure they may adopt. It is value added, not a dependency. Third Rail consumes their approval outputs whether they adopt it or not.
Why an API
An API allows Third Rail to remain independent of the execution system.
The enterprise does not need to replace:
- its OBT
- its TMC
- its travel-risk provider
- its assistance provider
- its expense system
Third Rail provides the missing handoff between them.
Designed for agentic travel
The same architecture becomes more important as booking becomes increasingly autonomous.
An AI travel agent should not need to reconstruct an employee's private risk profile.
It needs an operational answer it can act upon.
AI TRAVEL AGENT
│
│ "Can I proceed?"
▼
READINESS API
│
├── Ready
├── Needs Review
└── Not Ready
│
▼
BOOKING ACTION
Third Rail gives autonomous systems a governance primitive they can actually execute.
Where to read next
- The Third Rail Architecture: the architecture overview this page supports.
- The Readiness Gateway: the control point that emits the readiness state.
- The Assessment Receipt: the evidence that the process occurred.