Skip to main content

Data Model

Border Control Core is the system of record for the cluster. Consuming applications (enrollment products, Smart Corridor, eGate, external integrations) reference the same Traveler, Document, Journey, and Encounter entities — no application-specific identity model.

The traveler representation is biometric-agnostic at the interface level: entities reference biometric records, they do not embed biometric processing logic. See Biometrics via Border Control Core for the matching contract.

Draft of a Model​

Traveler
├── Biographic                      (1:1)
├── Demographics                    (1:1)
├── Applicant / EnrollmentProfile   (0:1 or 1:N — domain decision)
├── Document                        (0:N)
│   ├── Authenticity                (0:1)
│   └── DocumentBiometricModalities (0:N)
├── Encounter                       (0:N)
│   └── EncounterEvent              (0:N)
├── Journey                         (0:N)
│   ├── JourneySourceSnapshot       (1:N)
│   └── JourneyRisk                 (0:N)
├── TravelerRisk                    (0:N)
└── CapturedBiometricModalities     (0:N)

The four root entities developers will most often work with each have their own page. Risk and modality sub-entities are referenced where relevant; their detailed schemas will be published as those capabilities ship.

Entities​

  • Traveler — definitive identity entity, root of the model
  • Document — official travel or identity documents linked to a traveler
  • Journey — planned or actual movement on a transport instance, with its JourneySourceSnapshot audit lineage
  • Encounter — recorded interaction session at a border touchpoint, with its EncounterEvent atomic steps

Standards Alignment​

The model adopts the field semantics of established border-control identity standards so integrators familiar with them can map directly:

  • Primary — EES (Entry/Exit System), ETIAS, ICAO Doc 9303
  • Secondary — VIS (Visa Information System), SIS II (Schengen Information System), eu-LISA interoperability framework

Field optionality reflects the minimum required for system integration. Individual deployments may enforce stricter requirements via configuration.

Domain separation​

Border Control owns operational identity for border processes; it must not be conflated with adjacent domains:

DomainConceptPurpose
Border ControlTravelerOperational identity used in border processes
Border ControlEncounterSnapshot of traveler interaction (e.g., enrollment, crossing)
Gov ID (optional)IndividualUnique identity representation within Gov ID context
Gov ID (optional)ApplicantEnrollment snapshot within Gov ID context

Applicant and Encounter are conceptually similar (time-based snapshots) but belong to different domains and must not be directly mapped.

See also​