Three capabilities. One decision you can defend.
A visual recognition engine. One camera frame in — a named identity, or a labelled object, out.
Built for checkpoints, written to be audited. IRIS runs as an appliance inside your own perimeter and returns, with every verdict, the accept line, the rule that fired, the runner-up and the quality of the probe — so the decision can be defended months later by someone who was not there.
1,072
Enrolled identities, production deployment
29 ms
Recognition p50, service-side
9.3–27.7 pts
Correct identity's lead over the runner-up
The problem
Recognition is the easy part. Defending the decision is not.
Every serious engine can match a well-lit, front-facing, cooperative face. Checkpoints do not run on those. They run on a crop taken at arm's length, through a wide lens, of somebody already walking away — and then somebody has to explain the result.
Symptoms you've felt
The gate rejects known people. Tuned safely, a fixed threshold turns enrolled citizens away.
So it gets tuned down. Under queue pressure, until it starts admitting the wrong ones.
“Why this person?” has no answer. A verdict with no runner-up cannot be reviewed by anyone.
Published numbers without a method. A best case with no stated limit is not a measurement.
Data you never asked for. Identity records carry fields a camera has no business receiving.
Hardware coupling. A recognition layer tied to one supplier's gates and cameras.
Measured on this deployment
0.2 pts
Worst-case headroom on absolute score
A correct identification cleared the accept line by two tenths of a point. That is the headroom the line was left with — not room to absorb a harder probe.
5.9 pts
Empty band on distance to the runner-up
On the same evaluation set, the two populations never met. A band in which nothing was observed at all.
30 days
Retention, enforced inside the service
Record and image expire together. Not a storage rule somebody can forget to configure.
A recognition system should be judged by how it behaves at the edge of its own certainty.
Where the edge cases actually live
Speed gates & e-gates
A frame captured in the seconds a gate is open, of somebody already moving. The queue behind them is the cost of every false rejection.
Office & facility entrances
Lower volume, higher consequence. A wrong admission is not an inconvenience; it is an incident with a name attached to it.
Field wearables & handhelds
Arm's length, wide lens, uncontrolled light. The probe class on which fixed thresholds fail hardest — and the one they were never tuned for.
The engine
One engine. Three questions. None of them write.
IRIS exposes three recognition capabilities. Each answers one question, and none has a path by which it can alter who is enrolled — which is what makes recognition safe to expose more widely than enrollment.
Identification (1:N)
“Who is this?” — one face against the entire enrolled corpus.
Operational use
Gate and checkpoint clearance, watchlist screening, field identification from a wearable.
Verification (1:1)
“Are these two the same person?” — no corpus access at all.
Operational use
Document-to-holder matching, credential binding, confirmation at a manned desk.
Live multi-face
“Who is in this frame?” — every face, each with a bounding box.
Operational use
Continuous monitoring of a lane, hall or approach; wearable and fixed-camera streams.
A frame with no face is not an error
All three capabilities return a normal success response with face_detected: false and an empty result set. Rejecting would push the failure to the caller at the exact moment it has the least information to act on — mid-stream, at a gate, with a queue behind it. The system answers; the caller decides.
Object and scene detection
The same detection layer carries Zentara's object detection capability — sharing the GPU pipeline, the audit path and the retention controls on this page. Detection classes are configured per deployment, and every figure on this page describes the facial recognition path.
What recognition cannot do
By construction, not by policyCannot enroll
The recognition service has no write path to the corpus. Enrollment is a separate, governed operation with its own authority chain.
Cannot alter a decision
The accept line and the rule that fired travel in every response, so a change is detectable by any client. Authorisation and provenance are operator process.
Cannot record silently
A sighting and its image are written only when the caller sends a session header. No header, no sighting — and the audit entry is still written.
Cannot reach outward
The recognition path makes no outbound calls. Biometric data does not leave the appliance to reach a decision.
Risk moves toward the party best placed to carry it — and never silently.
The decision · measured
Absolute score is the wrong instrument. We measured it. It failed.
The conventional rule is a single one: score the face, compare against a fixed threshold, accept or reject. IRIS measured what that rule does across the evaluation set on this deployment.
Set it safely
The line goes high enough that no stranger is ever admitted. Defensible on paper.
Commissioning
Enrolled people bounce
Wearable and gate probes score below every enrollment photograph. Known citizens are reported unknown.
Week one
The line comes down
Queue pressure is immediate and visible; the risk of a wrong admission is neither. The line moves.
Under load
Now it admits strangers
Each move trades one failure for the other. A line tuned on clean probes is not a line that holds on a wearable crop.
The trade that was never real
Read the two red numbers together
On absolute score, a correct identification cleared the accept line by as little as 0.2 points. On distance to the runner-up, the two populations did not overlap. Between them sat 5.9 points of empty space.
Why it matters at a real gate
A crop taken at arm's length, through a wide lens, of somebody in motion scores below every evaluation photograph. Judged on absolute score alone, that person is reported as unknown. Yet the same crop is unmistakably nearest to one identity, and nowhere near the next. The signal is there. A fixed threshold throws it away.
Absolute score separates correct from incorrect badly. Distance to the runner-up separates them cleanly.
The decision · two rules
Two acceptance rules. Every response says which one fired.
A candidate is accepted by one of two rules, and the engine reports which in a field named matched_on — so a reviewer sees not only what IRIS concluded, but on what basis.
Cleared outright
Similarity meets or exceeds the accept line. A clean, high-quality probe against a well-enrolled identity — no further test required.
Stands far clear of the field
Below the accept line, but the top candidate is isolated — decisively nearer than every other identity in the corpus. Bounded by two floors and a minimum gap to the runner-up.
Name withheld
Illustrative, at production defaults. Below the accept line but 9.6 points clear of the runner-up — inside the measured correct-identity range. A fixed threshold would have discarded it.
The guard rail that makes margin safe
The margin rule answers “this one, not that one.” It does not answer “somebody rather than nobody” — an unenrolled stranger also has a nearest neighbour, and the gap test alone would admit that stranger under another person's name. So two floors bound it: the 65.0 retrieval floor decides what can be a runner-up at all, and a 69.0 confidence floor sits above the highest wrong candidate ever observed. On this evaluation set, every correct identity cleared the accept line outright.
Stated plainly rather than implied: the margin rule was designed for the wearable probe class — a crop at arm's length, subject in motion — which the evaluation set does not represent, and no measured correct identification was admitted on margin.
Defaults in force
Since a runner-up is never below the retrieval floor and the gap never under 6.0, an accepted top candidate is never below 71.0 — the margin rule operates in a narrow band beneath the accept line, 71.0 to 75.0. The 69.0 floor begins to bind only if the margin is cut below 4.0 points.
Read is_match
A row in the results is a neighbour, not an identification. Candidates below the accept line are returned deliberately — they are the evidence that makes a decision reviewable.
Never your own threshold
“Accept above 80” will reject correct identifications IRIS admitted on margin — using runner-up information your client cannot see.
Never hard-code the line
The accept line travels in every response. An operator changing it must not need a client release.
Margin needs a runner-up
If the second-ranked identity sits below the 65.0 retrieval floor there is no runner-up. The rule cannot fire, and the accept line decides alone — design clients for that case.
Evidence · quality metadata
A verdict on its own is not reviewable.
Quality metadata accompanies every recognition. It is the difference between “the engine got it wrong” and “the camera did not resolve the subject” — and it is the first thing to look at when a specific probe behaves unexpectedly. Every decision arrives with the evidence behind it — at the gate, and for as long as the operator's retention window holds it.
Architecture & deployment
Your hardware. Your network. Your building.
IRIS runs on an appliance inside the operator's own perimeter. The recognition path makes no outbound calls — no dependency on a Zentara-hosted service, and no connectivity required to reach a decision. Biometric data does not leave the deployment.
On-premise appliance
The standard deployment. GPU appliance in the operator's rack, on their private network.
Air-gapped
Recognition, audit, retention and erasure execute on the appliance with no outbound path. Updates arrive by a controlled media or staging process.
Edge-distributed
Appliances per site, for locations that cannot depend on a link staying up.
Sovereign hosting
Infrastructure located and administered within the operator's own jurisdiction.
What the operator holds
- The appliance and its GPU
- The enrolled corpus and every embedding in it
- The audit log, in the operator's own object storage
- The retention window, the accept line, and the authority to change either
- The TLS certificates for both entry points
Zentara holds no copy
Corpus, embeddings and audit log live in the operator's storage.
No deployment feeds another, and none feeds a vendor-side pool. An external integration the operator configures is theirs to assess — the no-outbound guarantee is scoped to the recognition path, and said so.
Three entry points, each scoped to its caller
Public gateway
Recognition and verification only. Every other endpoint is refused at the gateway and never reaches Core.
External integrators
Zentara Edge
Full API plus the operator console, over TLS, on the private network.
Operators · wearables
Host-local
Full API, loopback only. On-appliance tooling and maintenance.
Maintenance
Field eyewear · IRIS on the move
The hardest probe in the system is the one nobody stands still for.
Zentara's field eyewear runs IRIS against the probe class a fixed threshold handles worst: arm's length, wide lens, uncontrolled light, subject already moving. It is the reason the margin rule exists — designed for exactly this probe class — and the surface where this page's data protection controls matter most.
The wearer sees the evidence, not only the answer: every verdict arrives with the accept line, the rule that fired, the runner-up and the quality of the probe — at the moment of the decision, before anybody acts on it. A recording indicator faces the person being scanned, lit whenever a session header is being sent.
Field operating envelope · engine-side, device not separately measured
No on-device corpus and no on-device matching — recognition happens on the operator's appliance.
Platform: NVIDIA GB10 Grace-Blackwell class appliance — aarch64, CUDA 13, 128 GB unified memory. Detection and embedding both execute on GPU; every face reduces to a 512-dimensional L2-normalised embedding, searched exactly — no recall loss. A CPU fallback exists and the health endpoint reports which path is active, so a degraded appliance is visible in seconds.
Data protection
The restraint is engineered in, not written on top.
A recognition system is asked, every day, to hold more than it needs about people who have done nothing. These are behaviours of the running service, enforced in code rather than by client cooperation — two are deliberately operator-controlled, and named as such.
Recording is opt-in
A sighting is stored only when the caller supplies a session identifier. A script is not a wearer reviewing a shift.
Operator-controlled
Minimisation on the wire
Religion, marital status and parents' names are held in the identity record but never transmitted with a recognition.
Enforced in code
Never stored at all
Family-member identity numbers, household numbers and contact numbers are not held in any form.
Enforced in code
Retention expires the pair
30 days by default. A daily sweep deletes the record and its image together, inside the service.
Operator-controlled
Position carries uncertainty
Accuracy and fix age travel with every coordinate. Out-of-range values drop the whole fix rather than being clamped.
Enforced in code
Capture cooldown
The same identity is photographed at most once per 60 seconds within a session. The sighting is still recorded; only the duplicate image is skipped.
Enforced in code
Erasure — partial, and said so
A session deletes whole, records and images together. There is no per-subject erasure across sessions at Rev 1.0 — published as a limitation, not papered over.
Enforced in code
Immutable audit
One immutable object per entry; no entry can be silently overwritten by another writer. Audit entries carry no automatic sweep — deletion is the controller's explicit act.
Enforced in code
UU PDP · biometric data is specific personal data
What the operator has to defend in public — and with what.
Indonesia's Personal Data Protection Law (UU No. 27 of 2022) treats biometric data as specific personal data — data pribadi spesifik. Roles under the law are set in the engagement contract; in the standard on-premise deployment the operator holds the data and makes the decision, and Zentara documents exactly how that decision was reached.
Lawful basis, notification, impact assessment and the appointment of a DPO remain the controller's obligations. Zentara supports them; it does not discharge them.
Vendors & integrators
We do not sell gates. We do not sell cameras. That is the point.
IRIS is hardware-agnostic by design and by commercial intent. Zentara has no gate line, no camera line, and no incentive to displace the vendor who does. Where an integrator brings the physical layer, IRIS supplies the decision layer beneath it.
Engine supply
IRIS on a Zentara appliance behind your solution. You own the client relationship and the physical layer.
Gate & camera vendors
Embedded OEM
IRIS as the recognition layer inside your product, under a defined interface contract.
Manufacturers
Joint delivery
Zentara on the engine, deployment and data protection; you on hardware and site operations.
Multi-site programmes
What you connect
- Any capture path that can post a JPEG. Speed gates, e-gates, turnstiles, CCTV, PTZ, handhelds, wearables, smart glasses — via your own capture layer. No certified device list, no Zentara SDK.
- An HTTP interface over TLS. Post an image, receive a decision. Three recognition endpoints plus a health probe.
- Your own identity source. The identity store maps a national identity number to a record, populated from the operator's authoritative registry.
What you get from us
- No rate limit on recognition or verification. The real ceiling is GPU capacity, and it is documented rather than obscured.
- A decision you can explain. Accept line, rule fired, runner-up and quality metadata in every response.
- Request-level traceability. One identifier links your log line to ours. Support starts with evidence.
- Engineering contact, not a ticket queue. Integration is briefed by the team that built the engine.
The integrator owns the gate. Roles under the PDP Law are set in the engagement contract — in the standard on-premise deployment the operator holds the data and makes the decision. Zentara documents exactly how that decision was reached.
How to evaluate us
Ask any recognition vendor for these four things. Including us.
The answers are more informative than any accuracy figure — and an engine that cannot name its own limits has not measured them.
The measured separation between correct and incorrect identifications — not the accuracy rate.
What the engine returns when it is uncertain, and how the caller can tell.
The throughput ceiling, and what imposes it.
The list of things it does not do yet.
There is no accuracy percentage on this page
Because no such figure exists in our measurements. What was measured, on the production evaluation set, is separation: every correct identity finished 9.3 to 27.7 points clear of its runner-up, wrong candidates sat 0.0 to 3.4 points apart, and between the two populations lay 5.9 points in which nothing was observed at all.
And when IRIS is uncertain, it says so: is_match: false with the ranked candidates still returned, and a no-face frame answers face_detected: false rather than an error.
The ceiling is one lock, and it is removable
Sustained serial throughput is ≈29 req/s because concurrency inside the models is held at one — a deliberate, conservative setting inherited from an earlier architecture, not a rate limit. There is no rate limit on recognition or verification; the real ceiling is GPU capacity, and raising the lock is a measurement exercise, in progress.
Service-side latency is p50 29 ms, p90 40 ms, max 51 ms. The 23–55 ms end-to-end range over TLS is a separate client-side measurement — neither figure derives from the other.
Every limit we know about, and what is happening to each
Revision 1.0 · August 2026The accept line does not self-calibrate
The threshold is fixed at its default; tuning is manual. Multiple reference embeddings per identity are in progress.
Throughput ceiling ≈ 29 req/s
Concurrency inside the models is held at one, deliberately — a conservative setting inherited from an earlier architecture. Raising it is a measurement exercise, in progress.
Exact search scales linearly
Latency grows with corpus size. An approximate index is deferred until corpus size justifies the trade — not before.
Erasure is session-granular
No per-subject erasure across sessions at Rev 1.0. The controller identifies affected sessions until a per-subject path exists.
None of these is a defect in the recognition path. The full register — each limit with a status and a path forward — is published in the Technical Reference below. An evaluator who finds a limit we did not disclose has learned something about the engine, and something worse about us.
Why Zentara
Architect. Not vendor. End to end.
The recognition service — its decision logic, deployment architecture, audit design and data protection behaviour — was designed, built, measured and deployed by Zentara Labs. The same team answers an integrator's questions.
Ministries & national agencies
Decisions that must be defensible in public, under a data protection regime with criminal penalties.
Border, transport & critical facilities
High-volume lanes where a rejected citizen and an admitted stranger are both operational failures.
Hardware vendors & integrators
A recognition layer that will not compete with the physical layer you supply.
The rest of the stack, when it is needed
Start a pilot
Four stages. Each one ends with evidence, not a meeting.
Technical briefing → controlled evaluation on your data → pilot at one lane → deployment. Evaluation runs on an appliance in your environment. We do not require a copy of your corpus.
Documents
The claims, in writing.
Both documents are at Revision 1.0, August 2026 — the same revision the production measurements were taken against. Every figure on this page appears in them, with its method.
IRIS — product brochure
The engine, the two acceptance rules, the measured separation, the deployment topologies and the data-protection controls — written to be audited.
IRIS — technical reference
The engineering reference: API contract, the decision logic as executed, measured latency and throughput, data-protection behaviour, and the full known-limitations register.
FAQ
Common questions
What ministries, operators and integrators ask before an evaluation. Straight answers — including the partial ones.
The name expands to Image Recognition & Identification System, and we expand it on first use in every external document for exactly this reason. Iris recognition — matching the pattern of the eye — is a different biometric modality, and one Kementerian Dalam Negeri already operates for e-KTP enrolment. IRIS does not scan irises. It is a visual recognition engine: a camera frame in, a named identity or a labelled object out. 'Image' is doing the work in the name — Recognition carries objects, Identification carries faces, which is the precise biometric term for 1:N search.
Three capabilities. One decision you can defend.
See IRIS against your own probe class. Evaluation runs on an appliance in your environment, ends with evidence rather than a meeting — and we do not require a copy of your corpus.