UI: Detection rules

List

Route: /custom-rules. A table of your custom rules showing each rule's type and target.

Create / edit

Routes: /custom-rules/new and /custom-rules/:id/edit. The form captures:

• Type — stopword (content or redirect-chain URL), regex (content, redirect-chain URL, or every captured network request URL), blacklist domain, combo, or AI. Network request URL supports regex only and is fixed to the page target.
• Match scope — combo rules only; its own field, rendered just above the conditions. Across the whole scan (any links) or Within a single link (all conditions on one URL). The hint under the second option warns that a rule built only from link-less tags (AI, behaviour) has no link to attach to and will never match — see combo rules.
• Condition — the term, pattern, domain list, or natural-language instruction the type expects. Network-request regex patterns are limited to 4,096 characters; matching is either case-sensitive or case-insensitive (i).
• Tag — the tag the rule assigns when it matches.
• Target — page (the landing), the creative, or both; the available choices depend on the type.

A Test rule action dry-runs the rule against sample input so you can confirm it matches before saving.

On a fresh scan, a network-request regex can inspect up to 5,000 captured URLs. Testing or rechecking a stored scan uses its persisted initiator tree instead: main-frame hops plus up to 200 subrequests, with selected resource types omitted. A historical dry-run can therefore miss a request that was available to the original fresh-scan evaluation.

Recheck

After saving, an optional Recheck scans dialog lets you re-run the rule against existing scans so historical results pick up the new tag.

See the concept guides: Detection rules and combo rules.