Glossary

Plain definitions of the terms a newcomer meets across the humanymous documentation. For how these fit together on a single request, see How Gate sees a request; for the exact rule and signal tables, see Hard rules & verdicts.

humanymous Gate is a reference implementation, not a production-hardened build. Definitions below describe the reference behaviour.

Verdicts and scoring

ALLOW. The verdict for a request not scored as automated (risk 0–29), or one carrying a valid verdict trust token that took the fast path. At the edge it maps to the action pass: the request is forwarded to your origin. On an attested route an ALLOW is priced rather than fast-pathed.

CHALLENGE. The verdict for an ambiguous request (risk 30–69). At the edge it maps to challenge_pow: Gate serves an accessible proof-of-work interstitial and does not contact the origin until the work is done. A score-based CHALLENGE — not one a hard rule promoted — can upgrade to ALLOW once the session solves the work.

DENY. The verdict for a request scored as automated (risk 70–100) or promoted by a high-confidence hard rule. At the edge it maps to block: the request is stopped and the origin is never contacted. Blocked visitors see plain language and an incident handle only — never internal identifiers.

Risk score. A number from 0 to 100 (one decimal place) that the seventh layer aggregates from the signals the earlier layers observed; higher means more evidence of automation. Policy thresholds map the score to a verdict: 0–29 ALLOW, 30–69 CHALLENGE, 70–100 DENY. The score is deterministic — the same input produces the same score — and a hard rule can override where the score alone would have landed.

Verdict. The engine’s decision for a request: one of ALLOW, CHALLENGE, or DENY, written uppercase. The edge also carries a fourth state, none (Unknown), for a request with no evidence captured yet, which fails open or closed depending on the route and HTTP method.

The seven layers (L1–L7)

L1–L7. The seven detection layers a request is scored across. L1–L4 run in the browser (JavaScript and WebAssembly); L5–L6 run on the Go server; L7 is the aggregation and decision step. No single layer produces a verdict on its own — inter-layer disagreement carries more weight than any one signal.

  • L1 Static client — reads static automation tells, such as the webdriver flag and headless indicators.
  • L2 Fingerprint — hashes canvas, WebGL, and audio output plus screen and hardware traits.
  • L3 Client integrity — detects patched native functions, proxies, and runtime hooks.
  • L4 Behavioral — observes mouse, keystroke, and scroll patterns and the isTrusted flag on events.
  • L5 Network / protocol — reads the JA3/JA4 and HTTP/2 fingerprint and header order from the connection.
  • L6 Consistency cross-check — checks that the user agent, client hints, in-browser evidence, and TLS all agree with each other.
  • L7 Scoring / decision — aggregates the L1–L6 contributions into the risk score, then applies hard rules.

Hard rules and fingerprints

Hard rule (HR-NN). A high-confidence pattern that can promote or override the score-based verdict — written with a hyphen and no space, for example HR-14. Engine-plane rules (HR-1 through HR-21) are evaluated inside the score pipeline and are the ones the Detection Observatory shows; Gate-plane rules (HR-22 through HR-30) are evaluated at the proxy edge only. Some hard rules are high-confidence (a spike reads as automated traffic); others are heuristic and can catch some real users, so a spike there warrants investigation. See Hard rules & verdicts for the full table.

JA3 / JA4 (TLS fingerprint). Derived identifiers computed from the fields in a client’s TLS ClientHello — cipher suites, extensions, and their order — which tend to reflect the underlying network stack rather than the claimed browser. When these resolve to a different engine than the user agent claims, that disagreement is a cross-check signal. Capturing them requires that Gate or the Core terminate raw TLS directly; a re-terminating CDN in front removes them.

HTTP/2 fingerprint. A derived identifier from a client’s HTTP/2 behaviour — settings frames, header-table sizing, and stream priorities — read at the same layer as the TLS fingerprint. Like JA3/JA4, it is compared against the claimed user agent; a mismatch on both the TLS and HTTP/2 fingerprints together is a strong cross-check tell.

Cross-session correlation. Linking requests that share a device fingerprint across many different subnets or sessions, which can reveal one client rotating through residential-proxy addresses. It is one of the signals that feeds the score and, in its high-confidence form, a hard rule. It does not by itself identify a person; it binds only to signals already collected.

Fingerprint. A derived identifier for a client, combining signals such as TLS and HTTP/2 traits and device characteristics. It is used to bind tokens, meter rate, and correlate sessions — not to identify a named individual.

The pieces

Gate. The reverse-proxy enforcement layer that fronts your origin. It terminates TLS, streams the detection bundle into served HTML, scores each request across L1–L7, enforces the verdict at the edge before the origin is contacted, and writes every decision to a tamper-evident audit log. First mention on a page is “humanymous Gate”, then “Gate”. See Which piece am I using?.

Core. The standalone detection engine (cmd/server) that embeds the same L1–L7 scoring as Gate and returns a verdict without edge enforcement or an admin plane. It is the reference and testing surface, and — because it can terminate TLS on its own accept loop — it captures JA3/JA4 and the HTTP/2 fingerprint directly. Gate and the Core share one scoring brain, so a request scores the same way in both.

Ledger. The admin single-page console, served from a separate admin listener, for reading enforced-and-recorded verdicts, audit integrity, bans, policy, and erasure. It is where operators work with hard-rule IDs, risk scores, and signal names; end users never see it.

Detection Observatory. A read-only, developer-facing page hosted on the Core that shows the engine’s per-signal scoring in isolation — the score trace, the hard-rule evaluations, and live self-test runs — with nothing enforced or recorded. It is dev-gated and refuses to start on a non-loopback address. It shows how a verdict was reached; the Ledger shows what the edge did to live traffic.

Origin / upstream. The application Gate sits in front of and forwards allowed requests to. “Origin” is the primary term; “upstream” is the name of the -upstream flag alias.

Challenges, tokens, and attestation

Proof-of-work (PoW) challenge. CPU work a challenged session performs, served as an accessible interstitial from the control plane; it is not a CAPTCHA. Solving it (signal l7.pow.solved) can upgrade a score-based CHALLENGE to ALLOW, because it demonstrates cost. It never overrides a hard rule — it proves CPU effort, not that a person is present.

humanymous Pass. An interactive, LLM-resistant challenge presented on a CHALLENGE verdict, designed so that solving it is hard to automate. On an attested route, a successful solve mints a short-lived step-up receipt that the Gate exchanges for the hmn_su proof. The same Pass is solved by an unattested human and an anonymous visitor alike, so there is no categorical human block. See Why am I seeing this?.

Attestation floor / attested route. A route an operator marks with the attested preset (strict plus the floor), typically a high-value mutating path such as checkout or a password change. On such a route an ALLOW is priced rather than fast-pathed: absent possession — an existing WebAuthn, Privacy Pass, or Web Bot Auth trust-upgrade — or an hmn_su step-up proof from a Pass solve, the ALLOW is demoted to CHALLENGE→Pass, never to DENY. The floor prices high-value passes into a per-session human solve; it does not detect or resolve a coherent spoof. See Configure attested routes.

Verdict trust token. A fingerprint-bound token (hmn_vt) that records a prior verdict so a valid ALLOW can take a fast path without re-scoring. It is bound to the client fingerprint: a token replayed from a different fingerprint, or forged, is rejected rather than honoured. It is session-scoped and short-lived, and carries no new identifier.

RIT (request-integrity token). A rotating, short-lived token that binds a request to its session and body via an HMAC, so that header or request-body tampering is detectable. A token that fails the body HMAC, or a RIT that is replayed or absent on an API call, is treated as a tamper or heuristic signal. Like the verdict trust token, it is session-scoped, not persisted to the audit log, and adds no new personal-data category.

Incident handle. The opaque reference an end user is given on a challenge or block page so they can appeal. It is the only identifier shown to blocked visitors — it maps to a record operators can look up, without revealing any detection detail.

Threat model

T0–T4 threat tiers. A five-tier scale used in threat-model and self-validation docs to describe the automation the design is meant to resist. It describes capability classes, not real users: T0 non-browser HTTP clients; T1 naive Selenium or Puppeteer; T2 stealth-patched automation with residual leaks; T3 real-engine automation where behaviour and network become the deciding — and lower-confidence — signals; T4 anti-detect tooling combined with real-human click-farms.

The T4 ceiling. An explicit design boundary: T4 is not solved. Real humans clicking through anti-detect browsers cannot be separated from legitimate users by client or network signals alone, so the design does not claim to detect them by those signals — it mitigates the tier through rate limiting, reputation, and, on attested routes, by pricing the ALLOW. This documentation does not claim otherwise anywhere.