Access control that understands people, vehicles, context and risk.
Smart Access Intelligence replaces the ordinary visitor book with a security workflow that can identify a person, authenticate who is presenting the identity, apply your site rules, control vehicle custody, record movements, and preserve an auditable history.
These are platform capability figures, not live customer usage statistics.
A visitor book records a visit. Smart Access Intelligence reasons about the visit.
The difference is not simply replacing paper with a screen. The platform connects identity evidence, authentication, authorization, vehicle custody, live presence, incidents and audit history into one security decision.
| Traditional visitor book / basic gate app | Smart Access Intelligence |
|---|---|
| Usually records whatever name or ID details the visitor provides. | Attempts to resolve identity evidence and separately authenticate the presenter. |
| Records a vehicle plate as plain text. | Can resolve the vehicle, compare observable physical attributes and maintain custody. |
| “Who are you visiting?” is often an unstructured note. | People, units and hosts provide searchable, categorized visit context linked to your site. |
| No reliable distinction between a person being identified and being authorized. | Identification, authentication and authorization are deliberately separate stages. |
| Paper says who wrote an entry, but not necessarily who changed or overrode it. | Individual operator accounts and audit events preserve accountability for security actions. |
| Current occupancy usually requires counting entries and exits manually. | Premises State maintains a live people/vehicle snapshot separate from historical movements. |
| Incidents are often kept in another notebook or chat group. | Incidents have lifecycle, assignment, notes, media evidence and review history. |
| Internet failure often means falling back to completely uncontrolled paper. | Clients can define deny, cached, provisional or controlled manual-offline behavior. |
| Repeated successful visits can become informal guard memory. | Continuity can contribute a small privacy-preserving risk signal without overriding hard rules. |
The guard captures only the information needed at the current stage while background intelligence performs the heavier work.
The system asks whether the person is authentic, whether the visit is authorized, and whether any asset release is allowed.
Risk, policy, custody, restrictions and override reasons remain visible rather than disappearing into a single “approved” status.
Operators, actions, checkpoints, movements and incident responses can be reviewed after the fact.
Three questions happen before a secure access decision.
The system deliberately separates identity, authentication and authorization. This prevents a common security mistake: assuming that knowing somebody's name automatically means they are allowed in.
Identification
Whose record is this?
The system resolves an identity from an ID number, Alien ID, passport details, resident records or controlled fallback evidence.Authentication
Is the presenter likely that person?
Knowledge questions, registered-contact possession, document checks and other available evidence establish confidence.Authorization
May this person enter or remove this asset?
Site policy, host context, watchlists, vehicle custody, resident rules and risk determine what happens next.A successful identity lookup is not, by itself, an access approval. A person can be correctly identified and still be denied, held for review, or require additional authorization.
Set up a client environment in the right order.
You can technically create records in many orders, but this sequence makes the system easier to understand and prevents configuration gaps.
Create your sites
A site is the protected place: estate, office, campus, factory, warehouse, hotel or other premises.
Create checkpoints
Add the actual controlled points: Main Gate, Pedestrian Gate, Reception, Loading Bay, Service Entrance and similar locations.
Create user accounts
Give every operator their own account. Avoid shared accounts because audit history should identify the actual operator.
Set security policies
Choose challenge count, OTP behavior, pedestrian exit rules, presence mode, screen-lock policy, offline behavior and physical-ID fallback rules.
Load residents and visit context
Add residents, known household members, resident vehicles, hosts, units, departments and destinations that security will need.
Set restrictions and capacity
Review watchlists and configure how the package's monthly verification allowance should be consumed.
Test before going live
Run a visitor entry, resident entry, vehicle entry/exit, pedestrian exit, incident, offline log and supervisor review.
Visitor entry: what the guard actually does.
The Gate Desk is intentionally simple. The guard captures only what is needed at each stage while the heavier intelligence work happens in the background.
A visitor arrives with a Kenyan ID
Kenyan ID
Enter the ID number. The system attempts its primary identity source and uses configured fallback sources when necessary. The person should not need to type their name before identity resolution.
Alien ID
Select Alien ID and enter the alien number. Available identity evidence is normalized into the same authentication process used by the rest of the platform.
Passport
Select Passport, use the searchable issuing-country list, capture passport details, and record that the physical passport was inspected. Passport inspection is not presented as a global government verification unless an appropriate source supports it.
Why the system asks questions
Adaptive questions test knowledge already held server-side, such as name components or date-of-birth information. Correct answers are never sent to the browser as hidden values. A wrong answer remains part of the verification history; a later correct answer does not erase the earlier failure.
Continue normally
When identity evidence and challenge performance are strong, the visitor proceeds to visit purpose, destination, host, movement mode and the final site decision.
Request stronger evidence
The system may ask for registered-contact possession, physical ID fallback or supervisor review depending on site policy and available evidence.
When contact verification is required
If a registered phone or email is available, the system can use subject-owned contact evidence. When tax-profile information is available, the platform can enrich missing contacts from that profile. Next-of-kin contacts are not treated as the subject's authentication contact.
That is not an identity failure. Some people legitimately do not have a KRA PIN. The platform continues with the best valid identity evidence available and follows the configured fallback policy.
Physical ID fallback
Where policy requires camera-only capture, the camera must open and an immediate image must be captured. Denied camera permission means that fallback route cannot proceed.
Where upload is allowed, the image receives a preview, OCR processing and supporting metadata checks. EXIF capture date/GPS may help when present, but missing EXIF alone does not make an ID fake.
The document text is compared with the identity already held by the verification session. A random image must not pass merely because a guard ticked “inspected.”
The operator confirms that the physical original was inspected. This supplements OCR/document evidence; it does not override an identity conflict.
A vehicle is not just a number plate.
People and vehicles are tracked separately. The person who brings a vehicle in becomes its operational custodian for that visit, even when the registered owner is somebody else.
For visual inspection, the guard confirms observable attributes such as body colour, body type, make and model. Model year is not treated as a dependable visual criterion. The guard can mark each observation as Match, Unsure or Mismatch.
Vehicle release is based primarily on who brought the vehicle in and who is attempting to remove it. A different authenticated driver may require authorization from the original custodian or an authorized resident owner, depending on the vehicle rules.
Resident vehicles
| Who is driving out? | Expected behavior |
|---|---|
| Resident owner | Normal authenticated release, subject to security policy. |
| Whitelisted driver | Normal authenticated release once that driver's identity is established. |
| Unknown / non-whitelisted driver | Owner authorization is required, normally using the configured authorization contact. |
| Blacklisted driver | Hard stop and alert. An OTP is not used to silently bypass a blacklist. |
Pedestrian exit and vehicle exit are deliberately different.
Clients can keep pedestrian exit fast while applying stronger custody controls to vehicles.
Direct pedestrian exit
Record the person's exit without requiring full re-authentication. Useful where the client prioritizes fast movement out.
Optional authentication
The operator can use quick exit or authenticated exit depending on circumstances.
Mandatory pedestrian authentication
The person must authenticate again before the exit is recorded.
Vehicle exit
Vehicle release remains an authenticated custody-control process. The system checks the vehicle, current driver and original custody relationship.
A person may leave on foot while their vehicle remains inside. Likewise, a vehicle and its custodian can have different movement times. This is why the platform maintains separate person and vehicle presence.
Where an authorized supervisor override is allowed, the system retains the original recommendation, identifies the supervisor, captures the reason and records the override in the audit trail.
Premises State answers one question: “What is inside right now?”
It is a current operational snapshot. It is not the historical visitor book—that is the Access Log.
Current snapshot
People believed to be inside, vehicles believed to be inside, time on premises, current custody and current status.
Historical ledger
Past entry/exit events, operator, checkpoint, purpose, destination, outcome, movement reference and other recorded context.
The People and Vehicles sections are stacked vertically and use a sticky navigator so operators can move quickly between them. Opening Details gives a visual intelligence summary with risk, identity confidence where available, time inside, visitor classification/status, visit volume and movement history.
Illustrative metrics above show how the detail view is read; they are not live customer data.
When connectivity disappears, the system can degrade honestly.
Offline does not automatically mean “verified.” Clients decide what their site is allowed to do during an outage.
Deny
No offline verification decision is permitted. Security waits for connectivity or follows an external emergency procedure.
Cached only
Only still-valid trusted cached evidence can support a clearly labelled cached decision.
Provisional
Security may capture a provisional movement for later reconciliation. The system does not claim that live authoritative verification occurred.
Manual offline logbook
If enabled, guards can capture a digital visitor-book record locally and synchronise it after connectivity returns.
A client administrator can also decide whether manual/offline records should automatically create incidents when they synchronise, allowing supervisors to review every period where live verification was unavailable.
Residents are site memberships, not a shortcut around authentication.
Being a resident tells the system how the person relates to the site. It does not mean that anybody who types that resident's name is automatically admitted.
Residents can be enrolled individually or imported in bulk. A resident can also have resident vehicles and a controlled list of known household people or children who may not have conventional identification documents.
Known people are clearly labelled as KNOWN RESIDENT PERSON. The system does not pretend they passed government-ID verification when they did not.
People, Units & Hosts tells security where the visitor belongs inside the site.
It is broader than a resident directory. It can represent a resident, employee, department, unit, reception point, facility contact or another legitimate internal destination.
The table supports search, filters, categories, pagination and record updates. Where useful, a host can be linked directly to an enrolled resident so the site does not maintain duplicate identity records.
A host match gives visit context. It does not authenticate the visitor and it does not automatically grant access.
Watchlists turn known security concerns into visible gate controls.
Authorized managers can create and update watchlist/restriction entries. The Gate Desk surfaces relevant restrictions during a matching transaction.
Restrictions should be specific, reviewable and supported by a business/security reason. A restriction can influence or stop an access decision depending on its type and your site's policy. Authorized updates should be auditable rather than silently replacing history.
Do not use vague notes such as “suspicious person” where a more precise, reviewable reason can be recorded. Access controls are stronger when supervisors can understand exactly what triggered them.
An incident is a case with a lifecycle—not a note that disappears.
Incidents can carry images, video or audio evidence and move through a controlled response workflow.
Resolution does not delete an incident. The original report, severity, site/checkpoint, assignee, response notes, evidence and lifecycle events remain part of the case history. If later evidence requires more work, an authorized user can reopen the case.
Upload or capture photographic evidence with preview.
Attach short relevant video evidence where permitted.
Attach audio evidence when it materially supports the incident.
Assignments, status changes and response notes create a reviewable history.
Administration defines how your security operation behaves.
Only authorized users should see the controls appropriate to their role and client scope.
Model the physical estate
Create protected sites and the actual gates/reception points that control movement.
Choose security strictness
Challenges, OTP, exits, presence behavior, screen locking, offline behavior, physical-ID fallback and trusted cache.
Control operator access
Create individual accounts, assign roles, status and site scope, and reset credentials where authorized.
Understand operating terminals
Review devices used to access the security workspace and enforce the organization's device policy.
Package capabilities
Platform administrators define package allowances and commercial limits; client administrators manage consumption within their package.
Standardize guard choices
Maintain searchable destinations and purposes so gates capture consistent data instead of free-form variations.
Every package has a verification allowance.
Verification capacity is a controlled entitlement rather than an unlimited background resource.
A malformed request rejected before a verification starts does not consume a unit. Once a valid identity-verification workflow actually begins, one unit is consumed even if an external source later fails.
Fixed daily
The client chooses a daily ceiling while the package monthly limit remains the absolute maximum.
Even distribution
The system spreads the monthly allowance across the days of the month, including remainder units.
Open monthly pool
No daily cap. Use capacity at any pace until the package monthly allowance is exhausted.
The Verification Limits dashboard visualizes package ceiling, month usage, remaining capacity, today's usage, current policy, average daily consumption, projected month-end usage, recent demand and site-level consumption.
Access decisions should be explainable after the person has left.
The platform preserves operational movements, verification outcomes and sensitive administrative changes in an audit-oriented record.
Ordinary users with report access see audit activity attributable to their own account. The super administrator alone can use the platform-wide audit view. Reports are server-paginated so large audit histories remain manageable.
Movement history is treated as an event ledger. Premises State is merely the latest current snapshot. Administrative reconciliation should not erase the historical event that occurred.
The platform is designed so convenience does not quietly become trust.
Security is layered across accounts, tenant separation, evidence handling, sessions, data minimization and auditable overrides.
Operators use their own credentials. Screen unlock uses the signed-in user's password rather than a shared gate PIN.
Client data is scoped server-side. A user's browser is not trusted to enforce client separation by itself.
Sensitive values and document evidence are protected at rest using the platform's encryption/hashing design where applicable.
Correct challenge answers are not sent to the browser for comparison.
A human override preserves the original recommendation, the overriding account and the reason.
Before authentication, the interface exposes only the information needed to complete the current security task.
Cross-site identity continuity
Authoritatively identified people receive a silent internal person identifier so successful history can contribute a small continuity signal. A guard does not see which unrelated client or site the person previously visited. Prior success can slightly lower uncertainty, but it does not override a hard restriction, blacklist, custody conflict or authorization failure.
Ordinary knowledge checks are not biometrics. A camera photo alone is not perfect forensic proof that a physical ID is genuine. Prior successful visits do not make somebody permanently low-risk. The system uses available evidence and records what level of assurance was actually achieved.
Give each role enough authority to work—without giving everybody everything.
Exact permissions depend on the client's configured role model, but these are the typical responsibilities.
| Role type | Typical responsibility | Should not normally do |
|---|---|---|
| Guard / reception | Run entry/exit workflows, inspect physical evidence, capture visit context, report incidents. | Change platform packages or broad tenant configuration. |
| Supervisor / security manager | Review exceptions, manage incidents, apply permitted overrides, review presence and operational reports. | Use another operator's account. |
| Client administrator | Manage sites, checkpoints, client users, site policies, residents/hosts and verification-consumption policy. | Increase the commercial package ceiling above the subscribed allowance. |
| Auditor / review role | Review permitted logs, evidence and historical access records. | Alter operational records without explicit permission. |
| Platform super administrator | Manage platform clients/packages and platform-wide controls/audit scope. | Use privileged access for ordinary gate work when a scoped account is more appropriate. |
Common terms in plain language.
How strongly the available evidence supports a claim, such as identity or vehicle match.
Testing whether the presenter is likely the person whose identity was resolved.
Deciding whether that authenticated person is allowed to perform the requested action.
The person operationally linked to a vehicle because they brought it into the premises.
The system's current belief about whether a person or vehicle is inside or outside.
The resident, employee, department, unit or facility context connected to a visit.
A decision-support signal built from current evidence and relevant history. It does not replace authorization rules.
One newly initiated identity-verification workflow counted against the package allowance.
A privacy-preserving indication that the same person has a configured amount of previous successful admission history elsewhere.
A security case that can be investigated, resolved, closed and reopened while retaining its history.
Questions clients and gate teams commonly ask.
Why can somebody be found by the system but still fail verification?
Finding an identity answers “whose record is this?” Authentication still has to establish that the person presenting that identity is likely the same person. Failed knowledge questions, missing possession evidence or conflicting documents can therefore trigger step-up or denial.
Does everybody need a KRA PIN?
No. The platform treats “no KRA PIN” as a legitimate possible outcome. It continues with valid identity evidence from the available identity sources and the site's configured fallback policy.
Why might the system ask for a phone OTP?
OTP is possession evidence for a subject-owned registered contact. Depending on policy it may be disabled, risk-based or always required. It is stronger than simply knowing a phone number.
Can a next-of-kin phone number authenticate the visitor?
No. Next-of-kin data may be useful context but is not treated as the visitor's own possession factor.
What if there is no internet?
Your configured offline policy decides whether the site denies the transaction, uses valid trusted cache, records a provisional event, or opens the manual offline visitor-book workflow. Offline outcomes remain clearly labelled.
Why would a vehicle exit be stopped when the driver is authenticated?
Authentication proves the driver's identity, not their authority to remove the vehicle. Vehicle custody, resident-owner whitelist/blacklist rules and original-custodian authorization are separate controls.
Can successful previous visits guarantee admission next time?
No. Previous successful admissions contribute only a small continuity signal. Current authorization, restrictions, vehicle rules and present risk remain more important.
Why was an uploaded physical ID rejected?
The image may be too poor, OCR may not correlate with the identity in the current session, the document may conflict with the resolved identity, or the required manual/camera evidence may be missing. The system should not approve an arbitrary image simply because it was uploaded.
What happens when the monthly verification allowance is exhausted?
The server blocks new metered identity-verification workflows before external intelligence providers are called. A client administrator can change the consumption mode within the subscribed allowance, but cannot raise the package ceiling.
Why does Premises State sometimes differ from the Access Log?
Premises State is the latest current snapshot; the Access Log is historical. In open-presence mode, repeated movements can be recorded even if an earlier movement was missed. Authorized reconciliation can correct current state without deleting movement history.
Start with the simplest operational checks.
Check browser camera permission and that the site is served over HTTPS. If site policy is camera-only and permission is denied, physical-ID fallback cannot continue through that route.
Confirm the currently deployed frontend build, hard-refresh once after an update, and inspect the request response—not only browser-extension warnings. Operational errors should identify the application action or API endpoint.
Use the signed-in user's own account password. There is no shared desk PIN in the current security design.
Confirm the active site/checkpoint, plate registration, vehicle presence record and custody/owner rules. Do not bypass a blacklist with a generic OTP.
Reconnect the terminal and allow synchronization. If configured, synchronised offline records may generate incidents for supervisor review.
Review the verification result, risk/assurance indicators, watchlist/restriction context, visit history and audit trail. The system is designed to show the evidence path rather than only a yes/no answer.
The system is strongest when the gate team follows the evidence—not shortcuts.
Identify the person. Authenticate the presenter. Apply the site's authorization rules. Confirm the physical vehicle and custody when relevant. Record what happened. Escalate exceptions. Keep current presence accurate without rewriting history.