Travel-risk assessment can require highly sensitive personal context.
Enterprise booking systems generally should not.
Third Rail separates those two requirements.
The traveller's contextual assessment occurs within a privacy-preserving environment. The enterprise receives the operational result, rather than the personal attributes that produced it.
Assessment vs enterprise boundary
TRAVELLER CONTEXT
│
│ protected
▼
┌─────────────────────────┐
│ READINESS ASSESSMENT │
│ │
│ Traveller context │
│ Destination intelligence│
│ Stateless synthesis │
└────────────┬────────────┘
│
│ minimum disclosure
▼
┌─────────────────────────┐
│ READINESS GATEWAY │
│ │
│ Ready │
│ Needs Review │
│ Not Ready │
│ Assessment Receipt │
└────────────┬────────────┘
│
▼
ENTERPRISE
│
booking / policy
What remains protected
Depending on implementation, the assessment environment may process:
- gender identity
- sexual orientation
- disability
- neurodivergence
- racialisation
- sensory requirements
- mobility requirements
- medical or other highly sensitive contextual information
These attributes are not part of the enterprise readiness contract.
What the enterprise receives
The enterprise integration receives only what it needs to act.
For example:
{
"trip_intent_id": "TRS-4471",
"readiness_state": "READY",
"evidence": {
"completed_utc": "2026-08-26T12:16:00Z",
"assessment_version": "readiness-core-2026.3",
"context_version": "destination-context-2026.08.26",
"attestation_hash": "b4c9e21af307d8e5c1a6f9024de83b71"
}
}
(Illustrative example. Version identifiers and the attestation hash are for illustration and do not correspond to a live assessment.)
The enterprise does not need to know:
"This employee is a trans woman, is autistic, uses a wheelchair and is Black."
It needs to know:
The defined readiness process has been completed, and the resulting state is READY.
That is the architectural distinction.
Sanitised audit logging
The assessment infrastructure can retain evidence necessary to demonstrate that the process ran without creating a parallel enterprise database of traveller vulnerabilities.
Audit records can capture:
- assessment version
- destination-context version
- process metrics
- attestation
- readiness state
- execution timestamps
The underlying personal context is excluded from the enterprise audit record.
What the internal representation is
The traveller's personal context is held privately. The assessment works from an internal assessment representation that exists only for the duration of the assessment; it is not published, not exported to the enterprise, and not retained afterwards. What crosses the boundary is the readiness state and the evidence that the process occurred.
This separation also applies to the acknowledgement step. Identity verification and signed acknowledgement are handled via IdentiGate, while the readiness assessment itself stays on the traveller's device. See The Assessment Receipt for how those two systems remain architecturally separate.
Data minimisation as architecture
This is not a promise to "handle sensitive data responsibly" while building a conventional centralised database.
The objective is different:
Architect the enterprise integration so that it does not need the sensitive data in the first place.
That is the minimum-disclosure boundary.
Where to read next
- The Readiness Gateway: how the readiness state reaches the enterprise workflow.
- The Assessment Receipt: what the retained evidence contains.
- Security and data handling: transport and application controls, and retention posture.
- Reference library: the evidence base behind these claims.
- The Third Rail Architecture: back to the architecture overview.