Smart Corridor

Smart Corridor is the corridor and e-gate clearance product of the Smart Corridors & e-Gates solution. A smart corridor provides seamless, contactless identity verification with face biometrics for high-throughput environments such as border crossings, airports and secure facilities: travellers are identified with a liveness check while they walk through a designated passage, without stopping for a manual identity check, and each person is classified as a known or unknown entity.

Smart Corridor runs on top of Face Matcher, the real-time face identification server that processes the camera streams and matches faces against watchlists. Face Matcher answers who is this face; Smart Corridor turns that stream of answers into what happens to this traveller.

What the corridor adds

• One identity per traveller: the Corridor Identity Grouping Service (CIGS) groups the many detections a person produces while walking past several cameras into a single anonymous identity.
• A clearance decision: the Smart Corridor & eGate Hub turns identifications into GREEN, RED or no-match clearance per unit, publishes them as GraphQL subscriptions (per topic, or the aggregate corridorEvents stream) and keeps a short event history.
• An officer screen: the corridor dashboard on port 8095 shows live passages, matches and zone state to the border officer, with traveller-facing feedback along the corridor.
• Optional zone tracking: the Multi-Camera Tracking (MCT) overlay follows people across cameras for position and zone events; without it, the Corridor Behavior Service derives zone signals from Face Matcher data.

Corridor and e-gate units

The same stack serves two unit types, selected per unit in configuration. A corridor (TYPE=CORRIDOR) is a walk-through passage optimised for throughput, where travellers are identified in motion. An e-gate (TYPE=EGATE) is a fixed checkpoint where the clearance decision drives a physical gate through the gate hardware integration. One stack can serve several units of either type.

Capabilities

Capability	Description
Passport-less biometric clearance	Tokenless passage: no document presentation, no stopping, no gate interaction during transit
Real-time face identification	Faces captured from live video are matched 1:N against configured watchlists, with a PAD liveness check
Multi-camera face and pedestrian detection	Every camera in the corridor contributes detections; a person is followed across camera boundaries
Identity grouping	Face detections from different cameras and time points are grouped into one anonymous identity per traveller, so each person is counted and tracked once
Watchlist clearance with smart alerts	Matches against allowed watchlists raise green clearance events; denied watchlists raise red alerts for officer intervention
Identification avoidance detection	Pedestrians present in the zone without a detectable face are flagged
Zone occupancy monitoring	Configurable per-zone person limits with violation events carrying allowed and detected counts
People counting	Unique-person crossing counts based on grouped identities
Position tracking	Person movement and position updates within the corridor, visualised on the officer floormap
Age estimation	Estimated age from facial images to support detection of unaccompanied minors
Live feedback	Real-time guidance for travellers and notifications for border agents via the Operational Interface

Every capability surfaces as a standardised notification: identification outcomes as identification.* topics, traveller presence as identity.* topics, and movement, counting and behaviour as zone.* topics. Consumers subscribe to exactly what they need through the Hub's /graphql endpoint; the full list is in the Event Catalog.

Decisions stay downstream

The corridor observes, identifies and reports; it does not make border-crossing decisions. Downstream systems, such as the Innovatrics Border Control Platform or other border management systems, apply their own business rules to the event stream: routing known travellers onward, escalating unknown entities, or alerting officers on watchlist hits.

How it depends on Face Matcher

The smart-corridor deployment package vendors a byte-identical copy of the Face Matcher release in its face-matcher/ folder and starts it first. The corridor services join Face Matcher's face-matcher-network and rely on it only through Face Matcher's published integration list: the network name, the container names and ports, the credentials, the license and the start order. Nothing in the vendored copy is edited, so a Face Matcher upgrade is a new release checkout, and a separately deployed Face Matcher is the stated direction for future releases. Cameras and watchlists are managed in Face Matcher (in its Station UI or through its API); the corridor only needs to know which cameras belong to which unit and which watchlists mean "allowed". See Face Matcher in the corridor.

Licensing

One iengine.lic file in secrets/, obtained from the Customer Portal for the host's hardware ID, licenses the whole stack: Face Matcher reads its own entitlements from it, and the corridor services are licensed by the smart_corridor block in the same file. See First Deployment.

In this section

• Getting Started: prerequisites, first deployment, unit and watchlist wiring
• Integration: the GraphQL event model, the event catalog, storage, gate hardware and the Border Control Platform link-up
• Guides: configuration, monitoring, maintenance and troubleshooting
• Architecture: layers, deployment layouts, network topology and security hardening
• Manuals: the complete reference for the Hub, CIGS, CBS, the optional MCT overlay, Face Matcher in the corridor and the operational interface