Start here: Operator

How-to / navigation hub. For the security operator or SOC on-call who runs the humanymous Gate Ledger during a shift.

You are the person watching humanymous Gate while it fronts the origin. Your working surface is the Ledger: you watch the Overview view (“live edge decisions”) as ALLOW / CHALLENGE / DENY decisions land, and you decide whether a change in the pattern is a false-positive spike (real humans getting CHALLENGE or DENY) or an abuse surge (automated traffic Gate is correctly holding back). When you need to act, you have three levers — unblock a subject, ban a subject, or pull the kill switch — and you drill into a flagged session by its incident handle to read the hard rules and signal contributions behind the verdict. Gate is a reference implementation, not a production-hardened build; treat the numbers and thresholds you see as reference behavior, and confirm before you widen the blast radius of any action.

Your read-decide-act loop, from a pattern change on the Overview view to the lever you reach for:

flowchart TD
  O["Pattern change on the Overview view"] --> Q{"FP spike or abuse surge?"}
  Q -->|"humans getting CHALLENGE / DENY on routes that pass"| FP["FP spike"]
  Q -->|"one fingerprint across subnets, or a flood"| AB["Abuse surge"]
  FP --> U["Drill in by incident handle, read signals; if unjust: unblock"]
  U --> KS["Broad lockout: kill switch — dual-control, fleet-wide"]
  AB --> C["Confirm the hard rule that fired"]
  C --> BAN["Ban the subject — temporary fp: is single Operator; permanent / CIDR is dual-control"]

Triage, in short

• FP spike — humans reporting blocks, a jump in CHALLENGE/DENY on routes that normally pass. Drill into a sample session, read the contributing signals, and if the verdict is unjust, unblock and consider whether a route preset is too tight.
• Abuse surge — one fingerprint across many subnets, a destructive flood, a fingerprint sweeping many sessions. Confirm the hard rule that fired, then ban the subject.

The three levers

Warning: The kill switch is fleet-wide. It stops hard-rule enforcement everywhere Gate runs, not on one route or one node. Traffic that would have been challenged or denied will pass. Pull it only as a deliberate, two-person decision, and plan to restore enforcement.

Note: Your identity is derived by the server from your bearer token — the Console reads and requests with the Operator token. Dual-control actions need a genuinely distinct Approver token; you cannot approve your own request.

Note: On a route running the attested preset, a scoring-ALLOW is deliberately priced to CHALLENGE → Pass by the attestation floor. This is not a false positive, not a bug, and not a lockout — it is the configured behavior for that route. A real human self-resolves it: they solve the Pass, the solve returns a session-bound receipt, the client redeems it at POST /__hmn/stepup, and the resulting hmn_su proof fast-paths later requests on the route. Neither lever fits here — Unblock lifts bans, and there is no ban to lift; the kill switch demotes hard-rule enforcement but does not clear the attestation floor. If unattested humans are looping instead of self-resolving, the cause is a topology one (a diverged hsid cookie jar or a missing shared HMN_TOKEN_KEY), covered in Supported topologies, not an action for the levers.

Your next 3 reads

1. Incident Runbooks — the on-call playbooks for FP spikes, abuse surges, and the exact steps behind each lever.
2. Hard Rules, Verdicts & Signal-ID Reference — what each HR-ID means and what the dotted signal IDs in a drill-down are telling you.
3. The Ledger — the live surface itself, seven views: Overview (live edge decisions), Integrity, Sessions (incident drill-down), Rate Limits & Bans, Policy, Approvals (the dual-control commit queue), and Compliance.

Tip: The Ledger is served on the separate admin listener (default 127.0.0.1:8445 (loopback)), not on the public edge. In dev it uses a self-signed certificate, so expect a browser certificate warning.