Rules

Rules are deterministic operator-controlled overrides applied before the ML scoring pipeline. They're how you express "always block this domain" or "always allow this IP range" without waiting for the scorer to figure it out.

Anatomy of a rule

Each rule has four parts:

• Action:
  • block — force verdict=block, skip vendors
  • allow — force verdict=allow, skip vendors
  • review — force verdict=review
• Field — what to match against
• Pattern — the value to match
• Note — optional human comment (why this rule exists)

Available fields

email	Exact match, case-insensitive. e.g. known.spammer@example.com
email_domain	Exact match on the part after @. e.g. mailinator.com
phone	Prefix match. e.g. +44794 blocks all UK mobile prefix 7947…
ip	Single address or CIDR. e.g. 3.0.0.0/8 matches all AWS US East
country	ISO-2. e.g. RU matches Russia
asn	Numeric AS number from MaxMind (e.g. 16509 = AWS)

Rule precedence

If multiple rules match the same signup, we pick the highest priority:

1. Customer-scoped rules beat global (admin) rules
2. Within same scope: block > review > allow

So a customer-scoped allow rule wins over a global block, but a customer-scoped block wins over a customer-scoped allow.

Performance

Rule matching is fast (microseconds per check) and runs before vendor enrichment, so a matched rule means we skip HIBP, MaxMind, etc. entirely — you save vendor budget on traffic you've already decided about.

When to use which action

• Block: known fraud. The ML wouldn't have caught it for some reason. e.g. a specific email domain that keeps trying.
• Allow: known legitimate but ML keeps flagging it. e.g. your internal QA team signing up from an AWS dev box.
• Review: suspicious but not certain. Useful for new countries you're not familiar with — review queue lets you spot-check.

Audit

Every rule match increments its hit counter and updates last_hit_at. Use these to spot rules that haven't fired in months (delete them) or rules taking a lot of traffic (review whether they should be permanent).