> ## 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.

# Visitors

> Who is expected and who is still on site, and the devices they bring in with them.

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.

| Standing | Meaning |
| - | - |
| **Expected** | Booked, not yet arrived |
| **On site** | Arrived and not yet departed |
| **Departed** | Left |
| **Cancelled** | Called off before it happened |

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](/property/gatehouse) 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.

| On the way out | Meaning |
| - | - |
| **Waiting on a signature** | Declared, and a manager has not yet decided |
| **May leave** | Authorised to exit |
| **Held at the gate** | Refused, or authorisation has lapsed |
| **Withdrawn** | Taken back before a decision, or after one |

Whether a device needs a signature at all is decided by [gatehouse rules or the device's own kind
of thing](/config/gatehouse) — 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.

<Card title="The gate" icon="scan-line" href="/property/gatehouse">
  Where a declared visit or device is actually checked, scan by scan.
</Card>

<Card title="Gatehouse settings" icon="gear" href="/config/gatehouse">
  The kinds of device, and the rules that decide which of them need a signature.
</Card>
