Visitors

Two registers, reached as tabs on one screen, each read by a different person at a different moment: reception opens the visitor list first thing and again at the end of the day, and a site manager opens the device list whenever something is waiting on their signature.

​

Visits

Books a visitor in — who they are, their company, who they are visiting, and when they are expected — and tracks them through arrival and departure. The register leads with what needs doing, not with the full list: on site now and, more pointedly, still here and overdue — somebody recorded as on site whose visit was supposed to have ended hours ago. That is the one question a gatehouse is actually asked at the end of a shift, and nothing else in the building answers it. An overdue visit is highlighted directly on its row. Book a visitor in opens the same form used to edit one afterwards. Calling a visit off asks for a reason, and withdraws any devices declared for it in the same action — a pass for a visit that never happened cannot go on opening a gate weeks later.

​

Devices

What people have declared bringing in — laptops, memory sticks, external disks, cameras, phones — each on its own pass, checked at the barrier by the gate on the way both in and out. The column that matters here is on the way out, and it is deliberately not the same thing as the device’s status: it is computed by the same logic the barrier itself reads, live, so a device reading “authorised until Friday” on a Tuesday afternoon is drawn by the code that will be refusing it on Saturday morning rather than by what a manager decided last week. Whether a device needs a signature at all is decided by gatehouse rules or the device’s own kind of thing — a queue built only from the category would miss a camera a rule catches on size, and list a phone a rule waves through regardless of its category. Where a rule rather than the category decided, the row says which rule.

​

Deciding a device

Opening a device waiting on a signature asks what may this device do — two separate questions, because the real instruction a manager gives is rarely a single yes or no:

• It may come in — and separately, it may go out again. Authorising entry without exit is the ordinary instruction for a disk that needs checking before it leaves, not an edge case.
• Until a date — left empty, the device’s own kind decides how long the authorisation lasts (a laptop for a fortnight, a disk for a week by default); a kind with no period at all does not lapse.
• The note that travels with it — what the guard and the person who declared the device are told. Required when refusing, because somebody is being told no.

Refusing both directions at once is not offered as an authorisation — that is a refusal, and the dialog pushes you to Refuse it instead rather than letting you construct the same outcome the server would reject.