Skip to content

GuardCore · Visitors & access

Visitor management, and the access events behind it

Signed in with their host, their vehicle and their badge; signed out, no-showed or denied — and a sweep that finds the visitor still on site when nobody noticed.

Talk to us Every GuardCore capability

The problem this solves

Visitor management is judged in an evacuation. The list has to be the people actually on site, which means it depends entirely on sign-out — the step nobody does. A register that only records arrivals is a register that is wrong by the afternoon.

GuardCore closes it from the other end. A visit is judged against its expected departure where one was given and against the site’s maximum hours where it was not, by a background sweep that raises one notification per visit. Pre-registration requires an expected arrival for exactly that reason, and the customer can pre-register their own visitors from their portal so reception is not transcribing an email at eight in the morning.

The access-control side is an integration console rather than a panel replacement, and it is worth being precise about that. Zones, credentials — card, fob, PIN or mobile, issued to a guard, a contractor worker or a visitor, each suspended or revoked with the time it happened — and an event log with rules over it. An ingested event that matches a rule can raise an incident by itself, through the same numbering as any other.

The part that a head end cannot do is the sequence. Two rules look across events rather than at one: repeated denials on the same credential inside a window, and the same credential granted at two zones closer together in time than anybody could travel between them. Neither is visible in a single row, and both raise a notification for review rather than an automatic accusation.

Worked example

A contractor’s card is denied four times at one door, then granted at a zone across the site a minute later.

  1. 1

    Each event lands once

    Ingested against the head end’s own event id, so a replayed feed does not multiply the record.

  2. 2

    The denials are counted together

    Four in a window, on one credential at one door — a pattern no single event shows, against a threshold and a window you set.

  3. 3

    The travel time is checked

    Granted at two zones inside an interval nobody could cover on foot. The second rule catches what the first cannot.

  4. 4

    It is raised for a person

    As a notification, not an automated conclusion, because the honest output of a correlation rule is "look at this".

A shared or cloned credential becomes a question somebody is asked, rather than four denials nobody read.

Capabilities

What visitors & access gives you

4 of these 5 are in the product today; the rest carry a badge saying what they actually are. Each one names what it is built on.

Visitor sign-in and sign-out

Live

Name, company, purpose, host, vehicle registration and badge on the way in; signed out, no-showed or denied on the way out. Pre-registration requires an expected arrival, so a booked visitor is a row rather than an email.

The visitor still on site

Live

Judged against the expected departure when one was given and against the site’s maximum hours when it was not, by a sweep that notifies once per visit — so the evacuation list is the list of people actually here.

Zones, credentials and an event log

Live

Access zones with their own rules, credentials issued as card, fob, PIN or mobile to a guard, a contractor worker or a visitor, each suspended or revoked with the time it happened — and an ingested event that matches a rule can raise an incident by itself.

The pattern one event cannot show

Live

Repeated denials on one credential inside a window, and the same credential granted at two zones closer together than anyone could travel — two sequences a single access event cannot reveal, found by a sweep and raised for review.

A live feed from the access-control head end

Roadmap

Events arrive today through an authenticated call carrying the head end’s own event id, which is how a middleware or a scheduled push feeds them. A shipped adapter for a named panel vendor is not built, and every provider starts as not connected.

On the roadmap. It is not built, not scheduled, and not something to plan a contract around.

What backs these claims

Each capability names the decision record, module, route or table it is built on. Ask us for any of them in an evaluation and we will walk you through the code.

Visitor sign-in and sign-out
POST /api/imss/visitors · /imss/visitors · OpsVisitors.tsx · imss_visitors
The visitor still on site
ADR 0040 · src/server/imss-jobs/visitor-overstay.ts
Zones, credentials and an event log
src/server/imss-access-control.ts ruleMatches severityFor · src/server/api/imss/v3/access-cases.ts credentialRevoke · imss_access_zones · imss_credentials · v3 access_credential · /imss/access-control
The pattern one event cannot show
ADR 0040 · src/server/imss-jobs/access-correlation.ts correlateAccessEvents · imss_access_events
A live feed from the access-control head end
imss_access_providers · src/server/api/imss/v3/access-cases.ts

Where this sits

Back to

GuardCore — every capability in one place

The whole module: what is live, and what is only on the roadmap.

Read next

A control room screen for the shift actually in progress

Unresolved duress at the top, who is on duty from the roster, the open incidents, the patrols under way — and dispatch orders that move through six states, each stamping its own time.

Twenty minutes on a real contract.

Real data, four logins, nothing typed on the day — including the parts we have not built, which we will point out ourselves.

Talk to us Every capability