The Third Rail Architecture

Third Rail Systems occupies the pre-booking Traveller Readiness layer between individualised travel-risk assessment and booking execution.

The purpose is simple:

Determine whether a traveller is ready to proceed with a trip before the enterprise commits to booking it.

Third Rail does not replace the systems enterprises already use for travel risk, booking, assistance, expense or policy.

It connects them.

The problem

Enterprise travel is already surrounded by specialist systems.

Travel risk platforms produce intelligence. Assistance providers provide intervention. TMCs and OBTs execute bookings. Enterprise policy engines define what is permitted.

What is missing is the decision layer between trip intent and execution.

Today, that gap is frequently bridged by people, email, spreadsheets, manual approvals or processes that happen after a ticket has already been issued.

Third Rail turns that gap into an API.

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.

The architectural hierarchy

                    THIRD RAIL SYSTEMS
                           │
                  TRAVELLER READINESS
                           │
                 READINESS ASSESSMENT
                           │
                   READINESS CHECK
                           │
                   READINESS GATEWAY
                           │
                  ASSESSMENT RECEIPT
                           │
              ┌────────────┴────────────┐
              │                         │
        ENTERPRISE POLICY         BOOKING EXECUTION
              │                         │
         Enterprise              TMC / OBT / AI

What each layer does

Third Rail Systems The architecture and infrastructure company.

Traveller Readiness The category: determining whether an individual traveller is operationally ready for a proposed trip.

Readiness Assessment The private, on-device evaluation of this traveller against this specific trip.

Readiness Check The traveller-facing step: the individual receives their assessment-generated guidance and acknowledges it.

Readiness Gateway The control point at the moment of booking. Assessment and booking are not always the same moment, so the Gateway revalidates the completed assessment against present conditions, confirms nothing material has changed since the assessment ran, and converts the result into a single machine-readable readiness state, without carrying the underlying personal context across it.

Assessment Receipt The evidence that the assessment process occurred: one sanitised record, held by the enterprise as its duty-of-care evidence.

Separation of responsibility

System	Owns	Does not own
Traveller	Personal context and voluntary disclosure	Surrendering protected attributes to the enterprise
Third Rail	Readiness synthesis, state generation and attestation	Booking, ticketing or enterprise policy
Enterprise	Travel policy, thresholds and duty of care	Maintaining a central vulnerability database
Assistance provider	Confidential mitigation and support	Booking workflow orchestration
TMC / OBT / AI agent	Booking execution and itinerary management	Evaluating private traveller context

The output

Third Rail does not need to become another system of record.

It produces a state:

Ready
Needs Review
Not Ready

and evidence that the assessment process occurred.

The enterprise decides what those states mean operationally.

Built to outlive today's booking stack

Third Rail integrates with existing OBTs and TMC infrastructure because that is where enterprise travel execution happens today.

But the architecture is not dependent on the OBT as the permanent endpoint.

The same readiness contract can be consumed by:

TMC workflows
OBTs
travel-request systems
assistance platforms
enterprise policy engines
autonomous travel agents

Readiness is separated from booking execution.

What Third Rail does and does not do

Third Rail performs the readiness assessment, produces the readiness state, provides evidence that the process occurred, and hands the state to the existing enterprise workflow.

It does not replace TMCs, OBTs, travel-risk platforms, assistance providers, enterprise policy systems, or booking and ticketing systems.

Read the architecture

The Minimum-Disclosure Data Boundary: what data Third Rail actually receives, processes and retains.
The Readiness Gateway: the control point between trip intent and booking.
The Assessment Receipt: where the sanitised record gets its trust from.
Security and data handling: transport security, application controls and retention posture.
Direct Collection vs Minimum Disclosure: what asking the traveller directly actually costs.
Why Not Deterministic Rules?: why the assessment is not a rules engine.

Further depth for a technical reader: the Readiness API and why Traveller Readiness now.