Home Use Cases Access Control
USE CASES · ACCESS CONTROL AND PUBLIC ID

Access Control

“The person in that entry log — was it actually them?”

A card can be lent, and a card can be lost. What the log records is that a card passed through, not that a person did. UniverseAI matches the image sent by your entry terminal on the server to verify the person themselves, and then follows which zones they moved through afterwards. Opening the door remains the job of the access system you already run.

Send Your Site Conditions Request a Live Demo

What actually happens at the entry point

We will not open with market size or growth rates. Here are the three scenes your team lives through every time.

SCENE 1 / A BORROWED CARD
A card passed through — a person did not
The log clearly carries that person's name. Yet the log itself cannot confirm who actually walked through the door. When something surfaces later, that record does not stand up as evidence.
Cause: what is being authenticated is not a person but an object — the card. Objects can be handed to someone else.
SCENE 2 / VISITORS
Issuing and collecting stays manual, permanently
Every visitor means issuing a temporary card, collecting it on the way out, and separately tracking the ones that never came back. The busier the site, the larger the share of the day this takes.
Cause: permission is granted to an object rather than to a person, so issuing, collecting and chasing that object all remain human work.
SCENE 3 / MULTIPLE SITES
Each site keeps its own list
Someone changes department or leaves, and that change does not reach every site at the same moment. At one of them, the door still opens.
Cause: entry lists are maintained per site, so a single person's permission change does not propagate across all of them at once.
All three scenes point at the same place — you have to authenticate a person rather than an object, and that list has to live in one source. One more thing sits on top of it. An entry log only tells you they came in. Which zones they moved through afterwards, and how long they stayed, still means opening camera after camera by hand. That is why this use case takes two products — GATE for the authentication, VCA for what follows it.

GATE + VCA — the authentication, and what follows it

Neither your access system nor your cameras get replaced. We add one server stage between your entry terminals and the system you already run, and layer a searchable record over the zones behind it.

A diagram with two parallel lanes: the upper lane shows GATE matching the image sent by an entry terminal and returning only a result, with door control staying in your access system; the lower lane shows VCA turning footage from existing zone cameras into routes and dwell time for the security team GATE authenticates. Your system opens the door. Grey = what you already own / blue and navy = the new stages 1. Authentication — GATE (our part) Entry terminals Speed gates, readers Already yours No replacement GATE Liveness + 1:N matching Authentication software on your servers Under 1 sec even at large scale Your access system Door control happens here Attendance, visitors, HR Permission policy lives here Face image Result only 2. Inside footage — VCA Zone cameras Existing CCTV Already yours No replacement VCA Routes and dwell by zone Face, body, clothing colour After-the-fact search Security and facilities Reviews candidates Cross-checks entry logs Makes the final call Opening the door is done by your access system. What we return stops at the authentication result.

The upper lane is the primary one; the lower lane supports it. GATE verifies the person from the image the entry terminal sends and returns a result, while opening the door stays with your access system. VCA picks up which zones that person moved through afterwards. Access alone is a complete configuration — VCA is added when you need what happens after entry.

Component What it does Why it is needed
GATE (primary) Matches the image sent by the entry terminal inside your own servers. After a spoof check (liveness) and a 1:N match against the enrolled list, only the authentication result is returned to your system. Face and palm can be used together. What is authenticated shifts from a card to a person. Remove the object that can be lent, and borrowed entry goes with it.
VCA (supporting) Layers onto your existing zone cameras, narrowing candidates by combining face, body, clothing colour and carried-item conditions, and showing routes and dwell time within a zone. No cameras are replaced. An entry log only tells you they came in. What came after — retraced camera by camera — becomes a handful of candidates instead.
Used together The authentication result and the movement through the zones behind it line up on the same person. It removes the state where you know who came in but nothing after that.
“These are the requirements we fit.”
Large enrolled populations — multiple sites consolidated onto a single list, or public identity verification where the enrolled population is inherently large. The bigger the 1:N scale, the more clearly this is our place.
Environments where biometric data cannot leave the organisation — an on-premises installation on your own servers, storing matching features rather than original photographs.
Sites that must see past the door — where zones carry separate permissions and movement has to be retraced after the fact.

Conversely, if the scope is one office building with a handful of doors, there is little reason to stand up a server solution. That scale is usually served well by conventional access hardware, and the point where we start to earn our place is the moment sites multiply or the enrolled population grows. Tell us the scale first and we will give you the answer that fits it.

Adoption takes four steps

From confirming site conditions to rollout — here is exactly what is exchanged at each step.

1
Confirm site conditions
Number of entry points, number of sites, size of the enrolled population, and zone-permission requirements — plus the access system and terminal types you run today. With those we draft a configuration against your conditions and reply. This is also where we tell you plainly whether the scale is our place.
2
Live demo
We run enrolment, 1:N matching and liveness judgement live. If VCA is in scope, condition-combination search and zone routes are shown in the same session.
3
Pilot verification
Pick one or two entry points and verify under real lighting and real footfall. Figures measured in certification testing do not reproduce as-is in the field, so seeing it in your own conditions is the most accurate route. Scope and duration are agreed case by case.
4
Integration and rollout
We hand over the REST API integration specification. Making the entry terminals or the access management system call our server is carried out by your in-house team or your SI partner; we supply the engine, the specification and verification support.
We are not the ones opening the door
What we return stops at the authentication result — match, confidence, liveness verdict. Deciding whether the door opens and actually controlling it belongs to your access system, as does attendance, visitor and HR integration. No terminal hardware has to be replaced, but integration development is always required, and deciding early who owns it is what moves the overall schedule most.

What we base these claims on

Only what has been measured and what has been deployed — followed by the limits, stated just as plainly.

99.97%
Accuracy under KISA certification testing
Under 1 sec
1:N response target (no millisecond guarantee)
400M+
Face database scale
4
Certifications: KISA, iBeta, GS 1st Grade, ISO
Evidence of 1:N running at scale

We hold a reference from operating a large-scale face payment service — an environment with a large enrolled population and high daily authentication volume. The 1:N demanded by access control is work of the same nature. We keep client names off the table outside, and yours is protected by the same rule.

Origin and deployment

A Korea-developed, non-Chinese vendor. It installs on-premises, in the cloud or into container environments (Docker, Kubernetes), with active-active configuration and automatic failover. Where your internal security policy or procurement specification treats vendor origin as a requirement, we prepare the supporting documentation.

Stated up front
  • Liveness screens spoof attempts such as printed photos, video replayed on a screen, and masks. Field performance tracks terminal camera quality and lighting, so we tune the decision thresholds to those conditions.
  • The accuracy figure was measured under KISA certification testing and shifts with on-site lighting, angle and enrolment image quality. Entry points mix backlight and night-time conditions, so we recommend verifying in your real environment first.
  • Response time is designed to the under one second mark. The actual figure is set by server specification, enrolled population and the network segment, so send us those three and we will propose a configuration and prepare it so you can measure it in your own environment.
  • VCA narrows the candidates; your officer makes the final determination. It is not a feature that automatically identifies a person from a single photograph.
  • VCA works with most ordinary cameras, but accuracy drops on cameras with very low image quality or poor angles. We confirm the minimum image-quality baseline (standard 2MP-class CCTV) with you in advance.
  • Your existing entry terminals stay in place. Speed gates, readers and kiosks remain the ones you already own; what we supply is the engine and the integration specification.

Frequently asked questions

The nine questions facilities and security teams actually ask first.

Do we have to replace the access system we already use?
No. We return the authentication result; deciding whether the door opens and controlling it stays with the access system you run today, as does attendance, visitor and HR integration. Integration development is required so that system can call our server — tell us its name and version and we will confirm the integration method and respond.
We have one building and a handful of doors — is this worth it?
At that scale conventional access hardware usually covers it well. Where we earn our place is when multiple sites need to be consolidated onto one list, or when the enrolled population grows — as in public identity verification. Tell us your current scale and your expansion plan and we will tell you exactly which side you are on.
Can we get rid of cards entirely?
A cardless, face-based configuration is possible. In practice you will still need a policy for exceptions — people not yet enrolled, conditions where the face is hard to read — and that handling is defined in your access system. Using face and palm together lets the palm cover the situations where the face is blocked.
Can permissions differ by zone?
Permission policy itself is managed in your access system. We confirm who the person is at each entry point and return the result; how that result maps onto zones is decided by the access system. Send us your zone-permission requirements and we will reflect them in the integration design and reply.
Does face data leave our premises?
Under an on-premises configuration it stays inside your environment. Storage is template-only: only the feature data required for matching is kept, and original photographs are not. That said, some regulations treat templates as personal data too, and we do not offer that interpretation — we state the storage method accurately and the judgement belongs to your legal and compliance teams.
How is visitor management handled?
Once a visitor is enrolled, they are verified at the entry point in exactly the same way. The workflow around it — request, approval, expiry — belongs to your access management system, and our role is to return a verification result when that system calls. Tell us your current visitor procedure and we will map out where the integration points sit.
To see movement inside a zone, do we need new cameras?
You do not. VCA layers onto the ordinary cameras already installed, integrating via ONVIF and RTSP. Cameras with very low image quality or poor angles can reduce accuracy, so we confirm the minimum image-quality baseline in advance. Send us your current camera list and we will review it and respond.
Does it slow down as the enrolled population grows?
The 1:N response is designed for under one second, and the engine handles a 400M+ face database. The actual configuration still depends on enrolled population, daily authentication volume and concurrency, so send us those three numbers and we will review a configuration and reply. We do not confirm a specific millisecond figure on the spot.
What does adoption cost?
We respond with a quotation. What we need to prepare it: number of entry points, number of sites, size of the enrolled population, whether you will install on your own servers or in the cloud, and your target deployment date. Tell us as well whether zone movement is in scope and we will cover it in one pass.

Related products

Detail pages for the two products that make up this configuration.

GATE — Biometric authentication on your servers →

The deployment-boundary diagram, the specification table, every strength with its caveat, and where it does and does not fit
VCA — The video search brain →

Condition-combination search on face, body, colour and carried items, plus companions and routes

So the name in the log is the person

Send us four things — number of entry points, number of sites, size of the enrolled population and zone-permission requirements — and we will draft a configuration against them and respond with a demo schedule.

Send Your Site Conditions