As an administrator you decide who exists, what each can do, what they can see, and how they reach it. Everything is off by default and granted deliberately. This is the operational tour; the full detail lives in the Operator Manual.
Admin → Create a record. Every identity — person, machine (euser), or portal — is governed the same way. Capabilities are all off by default and can never be self‑granted.
Per person: Chat only (the default), Avatar only (a full‑screen speaking face), or Chat or Avatar (an Avatar link in the chat header). The face uses the same documents, answer mode and audit as their chat, and keeps its own conversation thread.
Use (the default): their own documents plus the shared global corpus. Do not use: only the documents on their record and what they have been taught — right for an assistant about one thing (a farm, a product, a property). The list shows it as own corpus only.
Set the box default model on the Admin page — it applies to the next answer, no restart. Or give one record its own model (a coding model for a developer, say); it works for people, machines, portals and kiosks. Only chat models installed on the box are offered, a user can never choose their own, and every answer records which model wrote it. Test a model on your own documents before relying on it — not every model follows the grounding rules equally well.
Sort records into groups — folders such as Test users, Staff or Kiosks, up to three levels. Tick records and move them, or create a record straight inside a group. Groups only organise the Admin list: they change nothing about answers, documents, settings or access.
Answers only from retrieved documents; otherwise abstains. No world knowledge, no guessing. Use it for anything that matters.
Facts — names, dates, numbers, quotations — only from the documents, cited; where they are silent it may add general knowledge and says so. With nothing in the documents, the answer is labelled “from general knowledge”, with no source; a number not in the documents is flagged ⚠, never hidden. Good for research, study and personas; not for field procedures.
May also answer from the model's own knowledge, without labelling it. (The public site calls this mode Open.) It can contradict your documents — never put a field user in floating mode.
The mode is shown to the user as a badge and recorded against every answer, so an audit can tell a sourced answer from an improvised one. Leave User may switch answer mode off for serious work. Set it in Admin › Edit › Answer mode; for a kiosk, kiosk-create.js --grounding grounded|hybrid|floating. A user allowed to switch clicks the badge: Grounded → Hybrid → Floating. (+Web works with every mode — next.)
Everything else assumes the box is sovereign and can run offline. +Web is the one deliberate exception. When you grant it, a question the corpus can't answer is sent to your self-hosted SearXNG and the answer may draw on public web pages — the assistant behaves more like an ordinary AI, but still cites every web page by URL (a clickable blue link, recorded in the audit). It is the only feature that lets a query leave the box, so grant it deliberately and never on a field or safety-critical account. A public portal can never be granted it.
The capability itself. Off by default, per account, never self-granted.
Fallback — only when the corpus finds nothing. Augment (default) — also when the corpus is thin. Always — every question.
If allowed, the user gets an on/off Web badge in chat (a session toggle) and may pick their own trigger. Otherwise your settings are fixed.
Setup (one-time): run a SearXNG instance on the box or LAN (no API key, no per-query billing), set SEARXNG_URL in .env, and restart. Kill-switch: WEB_SEARCH_DISABLE=1 forces all web egress off regardless of grants. With SEARXNG_URL unset, +Web silently stays corpus-only — it never errors.
Internet‑status safety light. Every chat header shows a box‑level indicator — green Offline (sovereign, no internet reachable) or amber Internet LIVE (the box can currently reach the web). It's a read‑only truth signal, not a user switch: a user can turn their +Web off, but only the box/admin can take the whole system offline (kill‑switch above, or stop SearXNG). A truly air‑gapped box has no SEARXNG_URL, never probes out, and always reads Offline.
A portal is an assistant reached at /a/<slug> by a group or public audience instead of by individual login — a class, a department, customers. It's just another identity, so it reuses persona, corpus, grounding and audit, and it is capability‑capped by construction: it can only answer, never reach an admin screen or another portal's documents.
A kiosk is a portal with a face: a full‑screen assistant at /k/<slug> that visitors talk to or type at — a reception desk, a showroom, a home for sale. Same grounding, truth gate and audit; capability‑capped like any portal. It forgets each visitor: after a period of no use it clears the conversation and returns to its start screen.
Hello, thanks and goodbye are answered politely — fixed words, never facts. Real questions come from its documents. With a hand‑off line set, a question it can't answer becomes "I don't have that information. Please ask the agent."
Off by default; motion (light, any device) or face (precise; falls back to motion). It greets whoever walks up, and after 30 s (adjustable) with nobody there it closes the microphone, clears the conversation and waits.
Presence is decided inside the kiosk's own browser. No picture or video is recorded or sent; the box is never told. The start screen says so and a Camera: presence only tag shows while it's on.
Create or update one with a single command on the box (re‑running it updates the same kiosk and keeps its link):
# a grounded kiosk for one listing, greeting on arrival, handing off to the agent
node kiosk-create.js --live --slug unit-804 --label "Front Desk" \
--docs /path/to/listing --global no --listen continuous \
--greeting "Hello, welcome. I can answer questions about this home." \
--handoff "Please ask the listing agent." --presence motion --presence-empty 30
Admin → Global corpus is the shared base every user can draw on. Each person/portal can also have its own documents (their Edit → Documents panel). A person set to Global corpus: Do not use answers from their own documents only and cannot open global ones; portals and kiosks have the same choice.
Add .txt/.md/.pdf; each goes queued → indexing → ready · N chunks. Text‑based PDFs only — a scanned image PDF has no text and shows failed.
Toggle any document in or out of answers without deleting it — its chunks stay embedded but are withheld from retrieval.
A procedure is a signed .synth file — human‑verified, played back one step at a time. It is never chunked, embedded, or authored by the AI; that structural isolation is what keeps it trustworthy.
Compile and sign a procedure from a real manual. The runtime rejects bad schema, gaps, or a critical step without a confirmation, and warns on unsigned files.
A dangerous step will not advance until the user confirms — enforced by the box, and the confirmation is recorded.
Every step, question and confirmation is logged; a run resumes exactly where it was left.
Grant the Learn capability per user (off by default). What they teach is written to their own corpus as an ordinary, cited, editable document — never fine‑tuning, so it's transparent and reversible. Every teaching carries who taught it and when ("Told by John on 2026‑10‑03"), and every save and forget is logged.
A Teach page (/learn) and a "Teach this" button on messages; a "My knowledge" panel to edit or delete anything they've taught. In the avatar they can also teach by voice — "remember that…" — and it always reads the fact back and asks before saving.
You can review, edit and delete any user's learned items — Admin → Edit shows a Learned items panel (they also appear in that user's Documents panel). Deletions remove the chunks — it can never be cited again.
Admin → Status shows health and an abstention rate — how often it honestly said "I don't have that." A rising rate tells you what your audience is asking that the documents don't yet cover. Every question, answer and cited source is in the message log — likely your most valuable artifact.
An euser is a machine identity: create it, generate its API key (shown once), and it queries POST /api/ask with a Bearer key — getting the same grounded, cited answers, or an honest empty‑sources abstention it can act on.
# a device asks, with its key { "prompt": "What torque for the coolant flange bolts?" } → { "answer": "42 newton-metres.", "sources": ["KESTREL-7-manual.pdf"], "grounding": "grounded" } # nothing loaded covers it → honest, machine-actionable abstention → { "answer": "I don't have that in the loaded materials.", "sources": [], "grounding": "grounded" }
Keep the key server‑side (never in browser JavaScript). Over a public tunnel, gate the hostname with Cloudflare Access and add a service token so the machine can pass the edge, plus a WAF rate‑limit on /api/ask.
Air‑gapped. Pull the cable — it still answers.
On your hardware, served across the LAN.
A server you control, reached over a secure tunnel — no open router ports.
Local corpus + model, reachable anywhere, gated by you.
The Operator Manual covers install, TLS, backups, and the honest security state.