> ## 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 settings
> Which kinds of device need a manager's signature before they may pass, and the rules that can override a kind's own default.
What counts as a declarable device, and which of those need a manager to sign off before they may
enter or leave a site.
## Kinds of device
Your own list — a laptop, a memory stick, an external disk, a camera, a phone, or whatever else your
sites actually see declared. Each kind carries:
| Setting | Meaning |
| - | - |
| **Carries storage** | Flagged wherever it appears at the gate, because that is the fact worth a guard's attention |
| **Needs a signature** | Whether this kind, by default, waits on a manager's authorisation before it may pass |
| **Signature lasts** | How long an authorisation is good for by default — a fixed period, or left open with no lapse at all |
Retiring a kind leaves everything already filed under it untouched.
Getting this wrong in the safe-looking direction is what breaks the whole feature. Tick every kind
and reception generates dozens of approval tasks before nine in the morning — a queue that size
gets cleared rather than read, and a signature against a two-terabyte disk then means exactly as
much as the forty against people's phones. This screen counts how many kinds need a signature and
says so out loud once it is nearly all of them, because a list of ticks cannot show you that on its
own.
A kind that requires a signature but is left with no default period authorises for ever — right for
an employee's own laptop, rarely what anyone means for a contractor's disk. Any kind in that state is
named directly on this screen; whoever signs can still set a date on the device itself.
## Rules that decide first
A kind of device can only say "a camera" or "a phone" — it cannot say "anything over a terabyte",
"anything a contractor brings", or "everywhere except head office". A rule can, and rules are checked
before the kind's own default, in order, with the first match deciding. Where none matches, the kind
of device decides as normal.
Each rule can be scoped to one site or to every site, and states plainly whether a match means **a
manager signs** or **waved through**. A rule the gate's context cannot answer — because it asks about
something this device does not have — is skipped rather than guessed at, and the device register
shows which rule actually decided each row.
### Checking a rule
**Check a device** replays the whole walk against a real declared device: which rules were asked,
whether each matched, and which one — a rule or the kind of device itself — made the final call. A
rule that never matches looks exactly like a rule that is working right up until you check, which is
why this exists rather than trusting the rule list to read correctly on its own.
Where a declared device is authorised, and where this configuration takes effect.
The scan screen these rules and defaults are read by, in real time.