Admin Panel

Bailiff & Enforcement Agent Numbers

Phone numbers extracted from uploaded correspondence by the bailiff-scan microservice. Hit count = how many distinct documents the number appeared on. A number seen on 3+ documents is treated as verified (shown with a badge). Numbers are classified by the local Ollama (qwen2.5:3b) — false positives can be deleted.

Add bailiff number manually

For handwritten numbers on letters where OCR can't reliably read the handwriting. Read the letter yourself and type the number here.

Email Accounts

Mailboxes on mta01 (mail.vindex.legal) — served by the mailctl agent over the WireGuard net. A mailbox is a real inbox with its own IMAP/SMTP login; an alias only forwards an address into an existing mailbox.

Mailboxes

Aliases (address → mailbox)

System & Customer Logs

Workspace-attributed view over request_log. Metadata only — no request/response bodies or AI content. Severity is derived: critical = 5xx / network failure, error = any failed request (incl. provider 4xx like credit exhaustion — a failed analysis is a real customer impact), info = success. Rows with no workspace are platform jobs (e.g. case-law sync) shown as System / unattributed.

Server Logs

PM2 console output from the legal-analyser process — the tagged lines ([tts], [AI Gateway], [folders], etc.) that the log-monitor microservice ingests into the server_logs table. Auto-refreshes every 30s.

Usage analytics

Client console feed (browser_console_log) — anonymous usage telemetry. "Installs" are pseudonymous browsers, not named users; identified rows appear only where a user explicitly turned diagnostics on.

Daily health digest

Permanent rollup (daily_health) — one row per company per completed day, kept after the raw console rows purge. Anonymous pool = pseudonymous console rows with no company attribution. Chat/request/rung columns come from the permanent tables, so history backfills past the feed's start.

Sessions

Newest activity first. Click a session to replay its journey below.

Session journey

Sentinel

Per-principal abuse detection — scores request behaviour (velocity, endpoint sweeps, error ratios, failed logins, geo anomalies) and writes sentinel_incidents. In shadow mode nothing is blocked; signals.wouldAction records what would have fired. Blocks take effect via the in-app gatekeeper's 5s cache.

Refresh

Banbo devices

Endpoint agents reporting over the WireGuard tunnel (ingest :3019, peer-only). Silent heartbeat + fresh WG handshake = dead agent alert; stale handshake = transport.

LAN devices (via router watch)

Device events

Incidents

Blocks

Config

ALSA Corrections

When a user tells ALSA an answer is wrong, the complaint is checked against the live interface before it reaches you. Corrections that are provable from the interface (ALSA named a tab or window that does not exist) are applied automatically and do not appear here. What is listed below is what the interface cannot settle on its own: needs review = both sides refer to real controls, so the disagreement is about the order or the choice of step; rejected = the correction itself refers to something that does not exist, so the user is probably mistaken. Approving applies the correction to everyone; rejecting discards it. Corrections change the answer only — never a prompt, never the workflow, never code.

Recently decided

The last 50 decisions, including the ones applied automatically. Shown so a wrong call can be spotted and reversed — a decision here is one row, not a deployment.

What ALSA understands

The phrasings ALSA recognises as ordinary conversation rather than as a question to answer — greetings, thanks, farewells, yes/no, stop, repeat. Before this list existed, a bare “morning” had no command verb in it, so the rules had nothing to match and ALSA replied “Are you talking to me?”. Adding a phrasing here fixes that kind of mistake without a code change.

Two things worth knowing before you add one. Only phrasings of four words or fewer are ever matched — that is deliberate, and it is what stops “good morning, I want to file an N244” being treated as nothing but a greeting. And the match is exact: the whole sentence must be the phrasing, not merely contain it. Longer speech skips this list entirely and goes to ALSA as a real question.

What ALSA has taught herself

When ALSA refuses to act on something and the user immediately says it another way that does work, that pair is proof she was wrong the first time. The local model reads those pairs and decides which refusals were genuine instructions rather than the microphone mangling the words. The safe ones are added here automatically — nobody approves them first. That is a deliberate setting, and this list is where its mistakes become visible.

Each row shows the phrasing ALSA now accepts, what the user actually said that worked, and how confident the model was. A row that shows never used after a few days is probably noise and worth removing. Learning is capped per day so one bad run cannot flood the list.

Support tickets

Tickets a user raised through ALSA — either by asking her directly or by saying yes to her offer after she kept failing to resolve the same problem. The context on each ticket is the captured evidence: the last chat turns including which rung answered (or failed), so you rarely need to ask what they were doing. Reply posts the answer back into their chat as an ALSA message — she told them she would get back to them, and this is her doing it.