@osqd/bothandlerjs 0.3.0

package/docs/operations/index.md

@@ -0,0 +1,101 @@
+# Operations
+
+Knowing what the library is doing to your traffic, and changing it without a deploy.
+
+← [Documentation](../index.md)
+
+---
+
+| Page | For |
+| ---- | --- |
+| **This page** — events and hooks | wiring the engine into your own logging, paging and queues |
+| [The dashboard](dashboard.md) | seeing individual requests and the evidence behind them |
+| [Metrics](metrics.md) | counters, histograms, Prometheus |
+| [The audit](audit.md) | noticing that the traffic changed *shape* |
+| [Notifications](notifications.md) | webhooks, Slack, batching and redaction |
+| [Runtime changes](runtime-changes.md) | policy, guard, ranges and actors, live |
+
+---
+
+## Events and hooks
+
+Everything the engine concludes is available as an event, in two forms that are the same
+mechanism: a callback in the config, or a subscription you can add and remove.
+
+```ts
+const detector = new BotHandler({
+  onDenial:    ({ assessment, decision }) => audit.record(assessment.actor.key, decision.rule),
+  onDowngrade: ({ decision }) => pager.warn(`rule ${decision.rule} asked for more than its evidence`),
+  onAnomaly:   (anomaly) => yourAlerting.send(anomaly.severity, anomaly.summary),
+});
+
+// Or later, and more than once, and removable:
+const stop = detector.on("denial", ({ assessment }) => log.info({ actor: assessment.actor.key }));
+stop();
+```
+
+| Event | `onX` | Fires when |
+| ----- | ----- | ---------- |
+| `assessment` | `onAssessment` | Every assessment, including the ones that concluded nothing. The firehose. |
+| `decision` | `onDecision` | Every decision, with the assessment behind it. |
+| `denial` | `onDenial` | A request was actually denied — `block`, `drop` or `redirect`. |
+| `downgrade` | `onDowngrade` | The [guard](../concepts/the-guard.md) replaced a terminal action. **The one worth paging on a rise in.** |
+| `challenge` | `onChallenge` | A [challenge](../challenge/index.md) was issued, solved or rejected. |
+| `detector-failure` | `onDetectorFailure` | A detector threw or timed out. Operational, not about traffic. |
+| `policy-change` | `onPolicyChange` | The rule set was replaced at runtime. Your audit trail. |
+| `guard-change` | `onGuardChange` | The guard settings changed at runtime, with the before and the after. **The other one worth paging on.** |
+| `range-change` | `onRangeChange` | A range set was replaced — an allowlist entry added, a crawler's ranges refreshed. |
+| `actor-change` | `onActorChange` | One [actor's](../concepts/actors.md) memory was forgotten, or it was cleared as human, by hand. |
+| `anomaly` | `onAnomaly` | The [audit](audit.md) noticed the traffic change shape. |
+| `warning` | `onWarning` | A misconfiguration, at startup or since. |
+| `error` | `onError` | A detector, sink or store failed. |
+
+### Why `denial` and `downgrade` are separate events
+
+They are *derived* rather than left for you to compute from `decision`, and that is
+deliberate: "was this request refused" and "did the guard stop a rule" are the two
+questions every integration asks, and three integrations deriving them separately is three
+chances to disagree about the answer.
+
+### Why `guard-change` is separate from `policy-change`
+
+For the same reason the dashboard gates them separately: "which rules exist" and "how far a
+rule may go" are different powers with different consequences. A rule that overreaches is
+stopped by the guard; a change to the guard is what decides whether anything stops it.
+
+If you alert on one runtime change, alert on this one — and on `range-change`, because the
+allowlist is the one list that stops detection *running*: an address on it is not judged
+leniently, it is not judged at all.
+
+### `by` — who asked
+
+All four runtime-change events carry **`by`**, when whatever made the change could say who
+asked for it. Every mutating method takes a `{ by }` alongside its arguments, and the
+dashboard fills it in from its own `auth`.
+
+```ts
+detector.updateGuard({ falsePositivePolicy: "balanced" }, { by: "ada@example.com" });
+// warning: Guard settings changed at runtime by ada@example.com: falsePositivePolicy strict → balanced.
+```
+
+The library has no user model and does not want one; it carries the name it was given into
+the warning and the event, so an audit trail can say *who* rather than only *what*. See
+[runtime changes](runtime-changes.md).
+
+### None of them can hurt a request
+
+A handler that throws is caught, reported once through `onError`, and the remaining
+handlers still run — the same isolation the [detector pipeline](../detection/index.md)
+gets. None is awaited: returning a promise is fine and its rejection is reported, but the
+response never waits for your webhook.
+
+That is the whole integration surface. A logger, a pager, a queue, a metrics client, a
+webhook of your own — each is a function you pass in. Where you want batching, deduplication
+and redaction as well, [the notification hub](notifications.md) already has them; where you
+want the raw event, take it here.
+
+## Related
+
+- [Metrics](metrics.md) · [The audit](audit.md) · [Notifications](notifications.md)
+- [The dashboard](dashboard.md) — all of the above, rendered
+- [Configuration reference](../reference/configuration.md)

package/docs/operations/metrics.md

@@ -0,0 +1,74 @@
+# Metrics
+
+Counters, histograms, and the two series worth alerting on.
+
+← [Documentation](../index.md) · [Operations](index.md)
+
+---
+
+On by default; a handful of integer increments per request.
+
+```ts
+detector.metrics();      // structured snapshot
+detector.prometheus();   // Prometheus text exposition format
+```
+
+```ts
+app.get("/internal/metrics", (_req, res) => res.type("text/plain").send(detector.prometheus()));
+```
+
+**Serve it somewhere only your scraper can reach.** The detector-firing series describe how
+detection behaves, which is exactly what someone tuning a scraper would like to read.
+
+## What is counted
+
+Requests, verdicts, bot classes, actions, bypasses, detector firings and failures, the
+challenge lifecycle, a latency histogram and a score histogram; plus a gauge for tracked
+actors.
+
+## The two worth alerting on
+
+**`bothandler_downgrades_total`** — rules that asked to deny service and were refused for
+lack of proof. A rising count means your policy is asking for something the evidence does
+not support. It is the [guard's](../concepts/the-guard.md) own report card, and the single
+most informative number here.
+
+**`bothandler_verdicts_total{verdict="unknown"}`** — ordinary traffic. If this falls,
+either your traffic changed or your detection did, and you want to know which.
+
+## The one worth looking at *before* you move a threshold
+
+**`bothandler_score_bucket`** — how suspicion is distributed across everything that was
+scored, in ten buckets of ten points.
+
+Proven assessments are counted by `bothandler_proven_total` instead: their score is 100 by
+definition and decides nothing, so including them would put a spike at the top of the range
+that means nothing. This is what the [dashboard's](dashboard.md) score distribution is drawn
+from, which is why that chart and your alerting agree about how close ordinary traffic runs
+to the line.
+
+Moving `suspectThreshold` or a rule's `minScore` without looking at this is guessing. The
+histogram tells you how many requests sit in the ten points you are about to cross.
+
+## Per-detector timing is available and off
+
+Total assessment duration is always measured. Timing each detector separately costs two
+clock reads per detector per request, which on a twenty-detector set is forty reads to
+measure work usually counted in microseconds. Worth paying while you tune, not forever:
+
+```ts
+new BotHandler({ metrics: { perDetectorTiming: true } });
+```
+
+It fills `detectorTimings` in the snapshot, adds `bothandler_detector_duration_ms_sum` and
+`_count` to the Prometheus output, and puts an average beside each detector on the
+dashboard — which is how you find out that one `io` detector costs more than the other
+nineteen together.
+
+Switch metrics off entirely with `metrics: false`.
+
+## Related
+
+- [The audit](audit.md) — because a counter cannot tell you a number is *unusual*
+- [The guard](../concepts/the-guard.md) — what `bothandler_downgrades_total` is counting
+- [The dashboard](dashboard.md) — these numbers, drawn

package/docs/operations/notifications.md

@@ -0,0 +1,72 @@
+# Notifications
+
+Webhooks, Slack and your own sinks — with a ceiling, because this fires under bot load.
+
+← [Documentation](../index.md) · [Operations](index.md)
+
+---
+
+```ts
+notifications: {
+  sinks: [consoleNotifier(), slackNotifier({ url }), webhookNotifier({ url, secret })],
+  filter: { types: ["action", "downgrade", "error"], minScore: 70 },
+  redaction: { maskIp: true },
+  dedupeWindowMs: 60_000,
+  maxPerWindow: 200,
+}
+```
+
+## The sinks that ship
+
+| Sink | Notes |
+| ---- | ----- |
+| `consoleNotifier()` | development, and a reasonable default in a container |
+| `webhookNotifier({ url, secret })` | HMAC-signed, with the timestamp *inside* the signed payload; retries with backoff; per-attempt timeout |
+| `slackNotifier({ url })` | an incoming webhook |
+| `notifyJsNotifier({ ... })` | the sibling [NotifyJS](https://github.com/OSQD-ts) hub |
+
+Your own is one method — implement `Notifier`. If you want the raw event with no batching
+at all, take it from [the events](index.md#events-and-hooks) instead.
+
+## The two properties that matter under load
+
+Alerting is an asset or a liability depending on exactly these.
+
+**It never blocks a request.** `emit` returns immediately and a wedged webhook slows
+nothing. This is the same guarantee the event hooks give, for the same reason: nothing in
+this library may put an unbounded await on the request path.
+
+**It has a ceiling.** Repeats from one actor collapse within `dedupeWindowMs`; a global
+`maxPerWindow` catches distributed traffic where every event is genuinely distinct; and the
+**suppressed count is reported when the window rolls**, so a quiet channel is never mistaken
+for quiet traffic.
+
+Without both of those, the first real scrape either takes your site down or drowns the
+channel you would have used to notice it.
+
+## Redaction
+
+Addresses are masked to a `/24` or `/64` before an event leaves the process, and `Cookie`,
+`Authorization` and friends are stripped unconditionally.
+
+**Redaction runs on the way out**, so detection still sees everything. The engine needs the
+full address to key an [actor](../concepts/actors.md) and match a range; your Slack channel
+does not.
+
+## Filtering
+
+`filter` decides what is worth sending at all — by event type, and by a score floor:
+
+```ts
+filter: { types: ["denial", "downgrade", "anomaly"], minScore: 70 }
+```
+
+A good starting set is exactly those three: something was refused, the guard stopped a rule,
+or the [audit](audit.md) noticed a change. `assessment` is a firehose and belongs in a log,
+not a chat channel.
+
+## Related
+
+- [Events and hooks](index.md#events-and-hooks) — the raw, unbatched surface
+- [The audit](audit.md) — the source of `anomaly` events
+- [The dashboard](dashboard.md) — the notices panel these also land in

package/docs/operations/runtime-changes.md

@@ -0,0 +1,118 @@
+# Runtime changes
+
+Policy, guard, ranges and actors — changed without a deploy, and recorded.
+
+← [Documentation](../index.md) · [Operations](index.md)
+
+---
+
+## Why any of this is mutable
+
+Two things go stale between deploys, and both of them hurt.
+
+**Published crawler ranges.** A stale list turns a verified crawler into an accused
+impersonator — the address moved, the operator's file says so, and your copy does not.
+
+**A rule set.** Sometimes a rule is wrong in a way you want to fix *now*, not at the next
+deploy. That is exactly when the deploy pipeline feels longest.
+
+Everything below is available as a method, as a [dashboard](dashboard.md) control behind its
+own flag, and as an [event](index.md#events-and-hooks) so you have a trail.
+
+---
+
+## Rules
+
+```ts
+detector.updatePolicy(
+  [...detector.policy.rules, { id: "allow-healthz", match: { path: "/healthz" }, action: "allow" }],
+  { by: "ada@example.com" },
+);
+```
+
+Validated first, swapped **atomically**, announced through `onWarning` and `policy-change`.
+Invalid input throws and leaves the previous set standing.
+
+**What it cannot change:** `falsePositivePolicy`, `fallbackAction` and
+`terminalScoreThreshold`. No runtime edit can relax [the guard](../concepts/the-guard.md)
+through this door.
+
+## The guard
+
+Its own method, its own event, its own dashboard flag:
+
+```ts
+detector.updateGuard({ falsePositivePolicy: "balanced" }, { by: "ada@example.com" });
+// warning: Guard settings changed at runtime by ada@example.com: falsePositivePolicy strict → balanced.
+```
+
+Separate from `updatePolicy` because "which rules exist" and "how far a rule may go" are
+different powers. A rule that overreaches is stopped by the guard; a change to the guard is
+what decides whether anything stops it. `onGuardChange` carries the before and the after.
+
+If you page on one thing in this document, page on this.
+
+## Ranges
+
+```ts
+detector.updateCrawlerRanges("gptbot", await fetchOpenAiRanges());
+detector.updateRanges("datacenter", ranges);
+detector.listRanges();   // [{ name: "crawler:gptbot", size: 42 }, ...]
+```
+
+Parsed and validated before replacing the old set; invalid input throws while the previous
+set stands, because a range set that silently matches nothing is worse than a stale one.
+
+Two refusals specific to *crawler* ranges — a block wider than any crawler owns, and an
+empty list — are covered in [verification](../detection/verification.md), because those
+ranges do not merely describe a crawler, they verify one.
+
+`range-change` is worth alerting on: the allowlist is the one list that stops detection
+*running*. An address on it is not judged leniently, it is not judged at all.
+
+### Keeping them fresh automatically
+
+```ts
+import { startCrawlerRangeRefresh } from "@osqd/bothandlerjs";
+const stop = startCrawlerRangeRefresh(botHandler);   // twice a day, by default
+```
+
+Opt-in, because it makes outbound requests and a dependency-free package quietly fetching
+URLs on a timer is not something to inherit by accident. It fails open, per source.
+
+## Actors
+
+```ts
+detector.forgetActor(key, { by: "ada@example.com" });
+detector.clearActor(key, 60 * 60_000, { by: "ada@example.com" });
+```
+
+The support-ticket path: somebody is being challenged, you have looked at their requests,
+and you are satisfied. `forgetActor` drops what is remembered about them; `clearActor`
+exempts them for a stated number of milliseconds, so the exemption expires on its own rather
+than becoming a permanent hole nobody remembers opening. Both emit `actor-change`. See [actors](../concepts/actors.md).
+
+---
+
+## `by`, and the audit trail
+
+Every mutating method takes `{ by }`. The dashboard fills it in from its own `auth` — a
+basic credential names itself, and a custom `authorize` can return an identity instead of
+`true`.
+
+The library has no user model and does not want one. It carries the name it was given into
+the warning and the event, so your trail can say *who* rather than only *what*:
+
+```ts
+detector.on("policy-change", ({ by, rules }) => auditLog.write({ who: by, count: rules.length }));
+```
+
+Nothing verifies the name. It is as trustworthy as whatever supplied it, which is your
+authentication — the same thing that decides whether the change is allowed at all.
+
+## Related
+
+- [The dashboard](dashboard.md) — every one of these as a control, each behind its own flag
+- [The guard](../concepts/the-guard.md) — the settings `updatePolicy` deliberately cannot reach
+- [Verification](../detection/verification.md) — why crawler ranges are validated harder
+- [Actors](../concepts/actors.md) — what `forgetActor` forgets

package/docs/policy/actions.md

@@ -0,0 +1,196 @@
+# Actions
+
+All ten, ordered by what each costs a client that turns out to be a person.
+
+← [Documentation](../index.md) · [Policy](index.md)
+
+---
+
+That ordering is the useful one. Every action here will eventually be applied to somebody
+it should not have been applied to, so the question that matters is what that costs them.
+
+| Action | Terminal | Costs a person |
+| ------ | -------- | -------------- |
+| [`allow`](#allow) | | nothing |
+| [`log`](#log) | | nothing |
+| [`tag`](#tag) | | nothing |
+| [`delay`](#delay) | | a moment |
+| [`rate-limit`](#rate-limit) | | a retry, if they are fast |
+| [`challenge`](#challenge) | | seconds, and a working browser |
+| [`custom`](#custom) | | whatever you wrote |
+| [`redirect`](#redirect) | ✓ | their destination |
+| [`block`](#block) | ✓ | the page |
+| [`drop`](#drop) | ✓ | the page, with no explanation |
+
+The three marked terminal are the ones [the guard](../concepts/the-guard.md) will not let
+rest on a guess.
+
+The engine never touches a response object. It returns an `ActionOutcome` and the
+[adapter](../integration/adapters.md) applies it — which is why the same policy works
+identically on Express, Fastify, Koa and a Fetch runtime.
+
+---
+
+## `allow`
+
+Serve it. Explicitly, and that is not the same as having no rule: an `allow` above your
+other rules is how you say "this is fine, stop asking".
+
+```ts
+{ id: "verified-crawler-allow", match: { verdict: "verified-bot" }, action: "allow",
+  reason: "Crawler identity confirmed against its operator's DNS or published ranges." }
+```
+
+`params.headers` is honoured, so an allow can still carry something to the response.
+
+## `log`
+
+Serve it, and record it. The whole of `monitor-only` is built from this.
+
+```ts
+{ id: "observe-suspected", match: { verdict: "suspected-bot" }, action: "log" }
+```
+
+## `tag`
+
+Serve it, and attach the verdict to the **request** so your own handlers can react without
+re-running detection: `x-bot-verdict`, `x-bot-score`, `x-bot-class`, `x-bot-certain`,
+`x-bot-reason`.
+
+```ts
+app.get("/search", (req, res) => {
+  const bot = req.headers["x-bot-verdict"] !== "unknown";
+  res.json(bot ? cachedResults() : personalisedResults(req.user));
+});
+```
+
+Response-side verdict headers are **off by default** (`exposeVerdictHeaders`). An
+`X-Bot-Score` in the response is a live feedback signal for anyone tuning a scraper
+against you.
+
+## `delay`
+
+Serve it, slowly. `params.delayMs`, default 500 ms, capped at 10 s.
+
+```ts
+{ id: "slow-suspects", match: { verdict: "suspected-bot" }, action: "delay",
+  params: { delayMs: 1500 } }
+```
+
+Cheap for you and expensive for anything making thousands of requests, while a person
+notices a pause and nothing else. It holds a connection open, so it is a poor choice under
+heavy concurrency — prefer `rate-limit` there.
+
+## `rate-limit`
+
+A fixed window per [actor](../concepts/actors.md). Over the limit, the request is refused
+with `429` and a `Retry-After`.
+
+```ts
+{ id: "scraper-ratelimit", match: { botClass: "scraper" }, action: "rate-limit",
+  params: { limit: { max: 60, windowMs: 60_000 } } }
+```
+
+**This is the one action that needs a shared [store](../integration/stores.md).** A limit
+of 100/minute enforced independently by four replicas is a limit of 400/minute. With the
+default in-memory store it is per-instance, and the library will not pretend otherwise.
+
+A fixed window rather than a sliding one: one round trip instead of several, and the extra
+precision buys nothing for a mechanism whose job is to bound abuse rather than measure it.
+
+## `challenge`
+
+Serve a proof-of-work interstitial. Solving it grants a signed clearance cookie; the
+`clearance` detector reads it on subsequent requests.
+
+```ts
+{ id: "suspected-challenge", match: { verdict: "suspected-bot", minScore: 70 },
+  action: "challenge" }
+```
+
+Needs `challenge.secrets` configured — without it, a rule asking for one degrades to a
+`tag` and says so through `onWarning`. See [the challenge](../challenge/index.md) for what
+it does and does not buy.
+
+Challenging an actor that already holds valid clearance is refused and warned about:
+passing a challenge cannot change a proven verdict, so re-issuing would loop for ever.
+
+## `custom`
+
+Your own handler, registered by name.
+
+```ts
+import { defineHandler } from "@osqd/bothandlerjs";
+
+const shadowBan = defineHandler({
+  id: "shadow-ban",
+  description: "Serves an empty result set rather than an error",
+  execute: ({ assessment }) => ({
+    kind: "respond",
+    status: 200,
+    headers: { "content-type": "application/json" },
+    body: JSON.stringify({ results: [] }),
+  }),
+});
+
+new BotHandler({
+  handlers: [shadowBan],
+  rules: [{ id: "shadow", match: { botClass: "scraper" }, action: "custom",
+            params: { handler: "shadow-ban" } }],
+});
+```
+
+An `execute` returns one of three things: `{ kind: "continue" }` — optionally with
+`requestHeaders`, `responseHeaders` or a `delayMs` — `{ kind: "respond", status, headers,
+body }`, or `{ kind: "drop" }`. It may be async.
+
+A handler named in a rule but not registered serves the request and warns. **The guard
+does not apply to custom handlers** — it cannot know what yours does — so a handler that
+denies service is a decision you own entirely.
+
+## `redirect`
+
+Terminal. `params.location` is required; without it the request is served and a warning is
+raised.
+
+```ts
+{ id: "bots-to-api", match: { certain: true, botClass: "scraper" }, action: "redirect",
+  params: { location: "/api/docs" } }
+```
+
+Useful for sending automation somewhere it can be served cheaply and correctly — a data
+endpoint, a sitemap, a licensing page — rather than simply refusing it.
+
+## `block`
+
+Terminal. `403` by default with a plain-text body; `params.status` and `params.body`
+override both.
+
+```ts
+{ id: "scanner-block", match: { botClass: "scanner", certain: true }, action: "block",
+  params: { status: 403, body: "Automated scanning is not served here." },
+  reason: "Proven scanner. Refused on proof, not on suspicion." }
+```
+
+The body reaches a person often enough to be worth writing. Say what happened and how to
+reach you.
+
+## `drop`
+
+Terminal, and the harshest thing here: the connection is destroyed with no response at
+all. What a port behind a dropping firewall looks like.
+
+```ts
+{ id: "denylisted", match: { detector: ["ip-intelligence"], certain: true }, action: "drop" }
+```
+
+Reserve it for traffic you have decided about — a denylist entry, a confirmed attack. A
+person who hits this gets a browser error with nothing in it, cannot tell your site from an
+outage, and has no way to contact you. `block` with a `reason` is almost always the better
+answer.
+
+## Related
+
+- [The safety guard](../concepts/the-guard.md) — what happens when a guess asks for a terminal action
+- [Presets](presets.md) — these actions, assembled
+- [Adapters](../integration/adapters.md) — how an outcome becomes a response

package/docs/policy/index.md

@@ -0,0 +1,84 @@
+# Policy
+
+How an assessment becomes a decision.
+
+← [Documentation](../index.md)
+
+---
+
+The engine's two halves are deliberately separate. `assess` says what a request *is*;
+policy says what to *do* about it. Nothing in detection knows about actions, and nothing
+in policy re-examines a request.
+
+```ts
+const assessment = await detector.assess(facts);   // detection
+const decision = detector.decide(assessment);      // policy — pure, no state, no I/O
+```
+
+`decide` being pure is what makes the [replay](../testing/replay.md), the
+[corpus](../testing/corpus.md) and the dashboard's policy preview possible: a candidate
+policy can be run over recorded assessments as many times as you like, and nothing about
+the running system moves.
+
+## Rules, in order
+
+```ts
+new BotHandler({
+  rules: [
+    { id: "allow-verified", match: { verdict: "verified-bot" }, action: "allow" },
+    { id: "no-ai",          match: { category: "ai" },          action: "block" },
+    { id: "slow-scrapers",  match: { botClass: "scraper" },     action: "rate-limit",
+      params: { limit: { max: 60, windowMs: 60_000 } } },
+  ],
+  defaultAction: "allow",
+});
+```
+
+**First match wins.** Order is the whole semantics — a broad rule above a narrow one makes
+the narrow one dead configuration, which is why the dashboard lists rule hit counts
+*including the zeros* and why the rules in the editor are numbered and movable.
+
+If nothing matches, `defaultAction` applies (default `allow`). Every decision names the
+rule that produced it, including that one:
+
+```ts
+{
+  action: "challenge",
+  rule: "suspected-challenge",
+  reason: "Several probabilistic signals agree. A challenge the client can pass on its own.",
+  params: {},
+}
+```
+
+## Then the guard
+
+Between the rule and the decision sits [the safety guard](../concepts/the-guard.md), which
+refuses to let a terminal action rest on a guess. This is the mechanism the library is
+built around and it is worth reading that page before writing rules that block anything.
+
+A stopped decision carries what it was:
+
+```ts
+{ action: "challenge", downgradedFrom: "block", downgradeReason: "Strict mode permits …" }
+```
+
+## Reasons are part of the rule
+
+```ts
+{ id: "no-ai", match: { category: "ai" }, action: "block",
+  reason: "Not for model training. mailto:licensing@example.com" }
+```
+
+`reason` appears in the decision, in your logs, on the dashboard, and — for a `block` —
+can be served to the client. A refusal that explains itself and names a way to ask is the
+difference between a policy and a wall. Somebody on the other end is often a person.
+
+## Where to go next
+
+| | |
+| --- | --- |
+| [Matching requests](rules.md) | Every field a rule can match on. |
+| [Actions](actions.md) | All ten, ordered by what each costs a person. |
+| [Presets](presets.md) | Eight shipped policies; start from one. |
+| [robots.txt](robots.md) | The file your policy implies. |
+| [Runtime changes](../operations/runtime-changes.md) | Replacing rules without a deploy. |