Enterprise risk programmes increasingly need to demonstrate not merely that a policy exists, but that a defined process was actually performed.
Third Rail provides evidence of that process without requiring the enterprise to retain the personal attributes used during the assessment. This page answers where the sanitised record gets its trust from. It explains provenance, not the underlying assessment engine.
The Assessment Receipt is cryptographically proven. It carries verifiable evidence that a Traveller Readiness Assessment took place, produced a Readiness State, and was delivered to a traveller whose identity was verified at entry, without carrying any of the attributes the assessment ran on.
Four questions the receipt answers
-
What was assessed? The trip intent and enterprise reference.
-
Which logic ran? The assessment version and destination context version.
-
When did it happen? A timestamp in UTC.
-
Can the event be verified? A cryptographic attestation seals the integrity of the assessment event.
What the receipt records
- trip intent and enterprise reference
- assessment version
- destination context version
- completion timestamp
- readiness state
- attestation hash
The provenance chain
The receipt binds the relevant assessment metadata into an attestation.
Conceptually:
Trip Intent
+
Assessment Version
+
Destination Context Version
+
Timestamp
│
▼
ATTESTATION
│
▼
Assessment Receipt
The receipt is therefore not simply:
"Someone clicked a button."
It provides evidence of which defined assessment process produced the recorded readiness state and when.
Example
{
"trip_intent_id": "TRS-4471",
"employee_reference": "EMP-892",
"readiness_state": "READY",
"assessment": {
"version": "assessment-2026.3",
"context_version": "destination-context-2026.08.26"
},
"evidence": {
"completed_utc": "2026-08-26T12:16:00Z",
"attestation_hash": "f1a9d6203be4c8172a95dd0c46f8b3ea",
"identity_data_disclosed": false
}
}
(Illustrative example. Version identifiers and the attestation hash are for illustration and do not correspond to a live assessment.)
What the receipt does not contain
The receipt does not need to contain:
- sexual orientation
- gender identity
- disability status
- neurodivergence
- racial identity
- medical information
- the traveller's underlying assessment profile
The receipt proves process, not personal identity. It does not describe the internal assessment logic, and it exposes no internal representation of the traveller's context.
Governance evidence
The receipt can form part of an enterprise's broader evidence trail for travel-risk governance and duty-of-care processes.
It is not itself a legal certification, nor does the existence of an attestation make an organisation automatically compliant with ISO 31030, GDPR, the EU AI Act or any other framework.
Its purpose is narrower and more useful:
The receipt provides technical evidence that the defined assessment process occurred under specified parameters. It supports enterprise governance frameworks without constituting a standalone legal certification.
Identity verification and acknowledgement
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 traveller's acknowledgement step — confirming they received their readiness assessment — uses IdentiGate's existing identity verification and e-signing infrastructure, covering 179+ countries, rather than a custom-built solution.
Identity assurance and special-category attribute processing are architectically separate and are never bound together in one place. IdentiGate verifies who the traveller is and captures their signed acknowledgement. Third Rail's on-device assessment engine processes the traveller's readiness profile as a vector of traits, never as a named record tied to that identity. The two systems interact only at the point where a signed acknowledgement becomes a required input to the Ready / Needs Review / Not Ready state — they do not share a data store or a processing layer.
Where to read next
- The Minimum-Disclosure Data Boundary: what data Third Rail actually receives, processes and retains.
- Security and data handling: transport security, application controls and retention posture.
- Reference library: the evidence base behind these claims.
- The Third Rail Architecture: how the readiness layer fits together.