> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # Gatehouse > The guard's scan screen — a code, a verdict sized to read at arm's length, and an override on the refusal itself. The screen a guard actually stands at: scan a pass, get a verdict, move on to the next van. Everything about it is built for standing up, one-handed, all shift. ## Setting up a shift Three things, set once and then left alone for the rest of the shift: **site**, **which gate**, and **which way** people are moving — coming in or going out. All three are remembered on this device, so a gatehouse with only one gate answers the site question once and never sees it again. The code box underneath is the opposite: it clears and refocuses itself after every single scan, because whatever a wedge scanner types next has to land somewhere. ## Scanning Scan a badge or a device pass, or type its reference by hand, and the screen records the presentation and the decision in the same action — there is no second button to confirm it. A guard waving a van through with their arm produces one event, not an event and a pending confirmation nobody comes back to. The verdict is the largest thing on the screen, in one of four states: | Verdict | Meaning | | - | - | | **Let through** | Authorised to move in this direction | | **Turn it back** | Refused, with the reason underneath it | | **Overridden** | Refused, and then let through anyway by a guard's decision | | **Not registered** | Whatever was scanned is not a declared device or visit | Underneath the verdict, whatever the pass identifies — a device or a visit — is shown with the facts that matter at the gate: whose it is, its serial number, whether it carries storage, who is expected and when. A device carrying storage is flagged directly on this panel, because that is the fact a guard is actually being asked to check. ### Overriding a refusal The override button appears **on the refusal itself**, not as a separate screen to go find — a guard who has decided to let the plant manager out has already made the decision, and asking them to leave this screen to record it is asking them to not bother. Overriding asks for a reason, and produces a second event alongside the refusal: the refusal stays in the log exactly as it happened, with the override recorded beside it, because the question six months later is both what the guard was told **and** what they decided to do about it. A scan nobody declared is still recorded, with **not registered** as its verdict — the log is not edited to smooth over an ambiguous case. How often that happens is itself the answer to whether the declaration process is working. ## What has come past this gate Below the scanner, a running log of every scan at this gate — allowed, refused, and overridden alike — for the shift handover: reading the last twenty rows is usually how one shift tells the next what happened. This screen only works online. A failed check is shown as a failure rather than answered from anything cached, because an answer computed against a stale register may already be wrong — the one failure a gate cannot afford. The two registers behind what this screen checks — who is expected, and what has been declared. Which kinds of device need a manager's signature before they may pass, and the rules that decide it.