Your access system knows the badge. Your camera saw the person.
PARVEK puts those two together — matching the user id on the credential against the person recognized at the door, on your own appliance, with neither system replaced. We integrate with the access-control system you already run.
We are ready to integrate with your access-control system. We build the connection to your access-control system as part of onboarding, and you watch it run on your own doors during the 30-day trial — before you commit to anything.
We integrate with the platform you already run — the connection is built against your system during onboarding rather than picked off a shelf.
Representative platforms, not a certified-connector list. What decides it is whether your system can produce an event export carrying a system id, event id, badge id, user id and timestamp — through an API, a database view or a scheduled export. Most enterprise platforms can, including ones not named here. We confirm yours before you commit to anything.
Two systems. Two halves of the same event.
Your access system records the credential
It knows a badge was presented, which door opened and when. It does not know who was holding the badge.
Your cameras record the person
They saw who walked through. They do not know whether that person was the one entitled to.
Your operators join the two by hand
Export from one system, scrub footage in the other, line the clocks up. It is slow enough that most events are never checked at all.
A badge swipe tells you a credential was used. A camera tells you a person went through. Neither tells you whether they were the same person.
Matched on user_id, on your appliance
Deliberately small, which is why it works on almost any system. Read the access event, find the camera detections around it, and compare the person to the credential.
user_id is the field the match turns on What we read from your PACS
Five fields. Nothing about door control, nothing written back, and no change to how your access-control system operates.
system_id- Which access-control system the event came from, so a multi-system estate stays unambiguous.
event_id- The PACS’s own identifier for the event, so every correlation can be traced back to its source record.
badge_id- The credential presented at the reader.
user_id- The person the credential belongs to. This is the field the correlation turns on.
timestamp- When the PACS recorded the event, used to find the camera detections that bracket it.
What happens per event
- The door event arrives
PARVEK reads the access event from your PACS: which system, which event, which badge, which user, and when.
- The camera covering that door is checked
Detections around that timestamp are pulled from the camera watching the reader — who was there, and how many of them.
- Identity is compared
Where face recognition is enrolled, the person seen at the door has a user id of their own. The correlation is simply whether that matches the user id on the badge.
- The event is classified
Matched, mismatched, or unverifiable — and an unverifiable result is reported as unverifiable rather than quietly treated as a pass.
What the integration gives you
The first group falls out of the user-id match itself and is part of every access integration. The last depends on the camera view at that specific door, so we confirm it door by door at the assessment rather than promise it everywhere.
Access event verification
Every door event paired with the camera frame from the moment it happened, so a badge swipe stops being a line in a log and becomes something you can look at.
Badge–person mismatch
The badge says one user opened the door; the camera recognized a different enrolled person. That gap is the signal, and it is what the user-id match exists to find.
PACS alarm verification
A door-forced or door-held alarm raised with its video attached, so an operator can tell a real forced door from a delivery propping it open — without opening a second system.
Access investigation
Follow a person or a credential across doors and cameras on one timeline, instead of exporting from two systems and lining up clocks by hand.
Tailgating detection
One access grant, more than one person through the door. Needs a camera positioned to count people cleanly at the reader, so we confirm it door by door at the assessment rather than assume it everywhere.
Where this will and will not work
These decide the outcome more than the model does. If your site cannot meet them, we would rather say so now.
A PACS that will export events
An API, a database view, or a scheduled export — any of them works, and most platforms offer at least one. What we cannot do is read a system that will not give up its event log.
A camera that actually sees the reader
Correlation is only as good as the view. A camera that catches the back of a head as the door closes cannot confirm who went through it.
Face recognition enrolled, for identity matching
Pairing a door event with video needs no enrolment. Deciding whether the right person used the badge does — without it, the mismatch check cannot run.
A shared identity between the two systems
The PACS user id and the enrolled person have to be the same individual. Mapping those is a commissioning task, and on a large estate it is the bulk of the work.
Frequently Asked Questions
How do we see this working before we commit?
In the 30-day trial, on your own doors and your own cameras. We build the connection to your access-control system as part of onboarding, and you watch it run on your own doors during the 30-day trial — before you commit to anything. The appliance is lent at no cost for the trial, so you are not buying hardware to evaluate it.
Which access-control systems do you support?
LenelS2, Genetec, AMAG, Honeywell, Software House, Brivo, Gallagher, Identiv and others. Representative platforms, not a certified-connector list. What decides it is whether your system can produce an event export carrying a system id, event id, badge id, user id and timestamp — through an API, a database view or a scheduled export. Most enterprise platforms can, including ones not named here. We confirm yours before you commit to anything.
Do we have to replace our access-control system?
No, and that is the point. PARVEK reads events from the system you already run, the same way it reads streams from cameras you already own. It does not control doors and it does not sit in the access path.
Can PARVEK unlock or lock doors?
Not in this design. It reads events and correlates them. Door control stays entirely with your access-control system, which keeps PARVEK out of the path of anything safety-critical.
Does any of this need the cloud?
No. The correlation runs on the appliance on your premises, alongside the detection that is already running there. No video and no access events leave the site to make the match.
What does it need from us to work?
A PACS that will export its events, a camera that genuinely sees the reader, and — for identity matching specifically — face recognition enrolled, with the PACS user mapped to the enrolled person. That mapping is the real work on a large estate.
What happens when it cannot tell?
It says so. An event with no clear view of the door, or where nobody enrolled was recognized, is reported as unverifiable rather than quietly passed. A verification system that hides its own blind spots is worse than none.
AI surveillance and analytics are technology-assisted and do not guarantee prevention or detection of every security incident or 100% accuracy.
Bring us your access-control system
Tell us what you run, how your doors and cameras are laid out, and which access question costs your team the most time. We will confirm what your system can export, then prove the correlation on your own doors during the 30-day trial.
The appliance is lent at no cost for the trial — you do not buy hardware to evaluate it.