Three Design Principles Behind Relay Re-ID
The timing constraints of the route dictate the architecture, and the architecture dictates how much personal data is exposed. The three have to be designed together, not handled separately.
Relay Re-ID Along the Route
People do not stop and wait for a match. The features have to be in place before they reach the next node, and the window is only seconds to tens of seconds.
Learn about relay Re-ID along the routeDynamic Candidate Set Architecture
The central controller stays the single authority but pushes only the subset of candidates likely to appear at that node, balancing availability against accuracy.
Learn about the candidate set architectureOn-Site Data and Verifiable Deletion
Biometric features never leave the venue, retention is capped at 24 hours, and deletion covers the copies on every node and leaves an audit record.
Learn about data locality and deletionRelay Re-ID Along the Route
Ordinary face recognition happens at a fixed point: the person stops, the system matches, the gate opens. A venue built around movement is a different problem. People keep moving, so their features have to be distributed before they reach the next node. If that fails, every downstream node has to identify them from scratch and the benefit of self-service stops at the first counter.
Technical Highlights
- Calculated from the spacing between nodes on site and the speed of the crowd, the time between stations is only seconds to tens of seconds, and feature distribution has to finish inside that window
- Ticket and facial features are bound once at the entry point, so no document has to be shown again at the nodes along the route
- Nodes never talk to each other directly; everything is relayed through the central controller, which keeps credential and connection-trust management simple
- A failed match raises an immediate alert for on-site staff to handle, so human-machine cooperation keeps rigor from slipping as automation takes over
Use Cases
- Check-in, security screening and inspection routes at major transport hubs
- Entry flow separation and seating guidance at performance venues and stadiums
- Named-ticket entry and re-entry verification at concerts and large events
- Continuous passage through multiple checkpoints in hospitals and corporate campuses
Dynamic Candidate Set Architecture
There are two obvious ways to identify people across nodes: centralize the matching at the controller, or push the whole roster to every node. On a real route each has a fatal flaw. We take a third approach: the controller stays the single authority, but only the subset of candidates likely to appear at that node is pushed to the floor.
Technical Highlights
- The bottleneck with central matching is not latency but the single point of failure: once the controller goes down, the entire route fails with it
- Push the whole roster to every node instead and copies of the features multiply with the node count, widening personal-data exposure and making scheduled deletion hard to evidence node by node
- A dynamic candidate set pushes only the subset the few downstream nodes need; if the controller drops out, each node carries on with the list it already holds, degraded but not halted
- Shrinking the candidate set from everyone on site to a small subset lowers the false-match rate, so recognition accuracy genuinely improves rather than merely saving resources
- Version control and consistency checks keep the lists on different nodes from diverging
Use Cases
- Large routes with dense peak traffic and high numbers of people on site at once
- Venues with unreliable networks that have to tolerate brief controller outages
- Temporary events that cannot be fully cabled and need node positions moved as the crowd shifts
On-Site Data and Verifiable Deletion
How footage and biometric features are handled often decides whether a project can go ahead, more than recognition accuracy does. We put data governance into the architecture itself instead of adding a policy document afterwards.
Technical Highlights
- No public cloud by default: the authoritative copies of biometric features and raw footage exist only inside the venue
- Retention is capped at 24 hours, deletion covers the copies held on every node, and an auditable record is kept
- A node holds only the candidate set it needs at that moment; once the person has passed, the controller withdraws it and no long-term copy remains
- Matching runs against a self-taken image captured on site; there is no connection to government image sources and no matching against ID photos
Use Cases
- Public venues that require explicit commitments on personal-data protection
- Projects that have to pass an information-security review or a privacy impact assessment
- Agencies and venues where regulations forbid image data from leaving the site
Looking for Venue Partners to Prove Out Relay Re-ID
If you manage a major transport hub, a venue or an event route, we can assess node placement, network requirements and the deployment approach against the conditions on your site.
Get in Touch