Start here: Operator

Diátaxis quadrant: How-to. Audience: security operators and security-operations on-call staff who use 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 enforcement 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{"False-positive spike or abuse surge?"}
  Q -->|"humans getting CHALLENGE / DENY on routes that pass"| Wrong["False-positive spike"]
  Q -->|"one fingerprint across subnets, or a flood"| AB["Abuse surge"]
  Wrong --> U["Drill in by incident handle, read signals; if unjust: unblock"]
  U --> KS["Broad lockout: kill switch — dual-control, node-local"]
  AB --> C["Confirm the enforcement rule that matched"]
  C --> BAN["Ban the subject — temporary fp: is single Operator; permanent / CIDR is dual-control"]

Triage, in short

• false positive 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 enforcement rule that matched, then ban the subject.

The three levers

Warning: The kill switch is node-local and not route-scoped. Coordinate and verify each node separately in a fleet.

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 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 false positive spikes, abuse surges, and the exact steps behind each lever.
2. Verdicts, enforcement rules, and diagnostic signals — what each descriptive rule means and how to interpret dotted machine identifiers in a drill-down.
3. The Ledger — the live surface itself, eight views: Overview, Integrity, Sessions, Rate Limits & Bans, Policy, Settings, Approvals, 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.