Four layers. One verdict authority.
ShieldBet's classification engine is built around a single architectural rule: only the hard override gate and the policy decision engine can produce verdicts. Every other layer contributes structured evidence. Nothing decides on its own.
Hard override gate.
Two static lists are checked first because matches there produce instant verdicts with no further analysis.
The hard blocklist contains 987 entries — known operators (Bet365, Ladbrokes, William Hill, Paddy Power, Betway, LeoVegas, plus offshore and crypto brands), verified affiliates and tipsters, and paid-entry competition products. A match equals an instant block. The page does not load.
The hard safe list contains 267 verified utility domains — search engines, banks, gov.uk, NHS, major retailers, productivity tools, and recovery organisations. A match equals an instant allow.
Why static lists first
Bet365 should never reach the analysis layers. It should be blocked before any code runs against it. The same is true for trusted utilities going the other way — gov.uk should never be subject to ML uncertainty. Static lists are fast, deterministic, and auditable.
One exception: hard-safe matches on path-sensitive container platforms (Reddit, Discord, Twitch, Telegram, YouTube) fall through to Layer 1 because the same domain can host both safe and gambling content.
Path-aware platform check.
The single most important architectural change since v1. The same domain produces different verdicts based on path.
| Domain | Path | What it is | Verdict |
|---|---|---|---|
| reddit.com | / |
Homepage | Allow |
| reddit.com | /search/?q=casino |
Search results page | Allow |
| reddit.com | /r/sportsbook |
Subreddit on risky path | Block |
| reddit.com | /r/gambling |
Subreddit on risky path | Block |
| discord.com | /invite/casinochat |
Invite path with gambling hint | Block |
| youtube.com | /results?search_query=casino |
Search page | Allow |
Evidence builders.
For every page that reaches this stage, four parallel analysers run and contribute structured evidence to a shared assembly. None of them produces a final decision.
URL analysis
Examines the domain, path tokens, query parameters, and known safe-domain signals. Identifies strong gambling-indicating URL patterns (sportsbook, betslip, casino, jackpot, freebet) and safe sector signals (banking, mortgage, NHS, gov.uk).
Keyword & content analysis
Scans the full page text against curated term dictionaries, with the title weighted to reflect editorial significance. Strong unsafe terms (free spins, sportsbook, welcome bonus) produce strong positive evidence. Recovery terms produce strong negative evidence.
Layout & intent analysis
Reads structural signals: bet-slip UI elements, high-density CTAs with gambling-adjacent language, ranking tables with affiliate link patterns, and conversion funnel architecture. The shape of the page often gives more information than the text alone.
Safe-context ML model
An embedded logistic-regression bag-of-words classifier runs on-device against URL, hostname, title, and visible page text. Returns safe/block probabilities and a confidence value. Lightweight, deterministic, and capable of running offline inside the Chrome service worker.
A larger transformer-based classifier has been trained on the labelled dataset and validated with a hostname-based train/validation split (eval_loss 0.141 at convergence). Wiring it into the runtime as a higher-confidence evidence source is planned post-launch work.
Policy decision engine.
The only component allowed to produce a verdict. Reasons across the complete evidence picture and applies a deterministic, ordered set of rules.
| Condition | Outcome |
|---|---|
| Direct gambling mechanism present (bet slip, spin button, deposit UI) | Block — direct mechanism |
| Paid-entry chance mechanism present (raffle, instant-win, prize draw) | Block — paid entry |
| Strong route to gambling + ML or text block evidence | Block — route to gambling |
| Dominant ML safe-context overrides noisy route signals (clean of mechanism, footer, promotion) | Allow — verified safe context |
| Route signals on a protected safe role (finance, recovery, editorial) with strong dampening | Allow — moderate-risk review |
| Route consensus without sufficient dampening | Block — route to gambling |
| Structured commercial promotion present | Block — structured promotion |
| Otherwise | Allow — weak / noisy evidence only |
The accountability layer.
Detection is only half of the product. The other half is making sure protection can't be removed at the moment of weakness.
Two-party unlock
You request an unlock. The backend sends a six-digit code to your trusted partner — never to you. They decide whether to share it. There is no path to the code that bypasses them.
60-minute window
If the code is verified, protection suspends for exactly 60 minutes. A Chrome alarm re-locks automatically at the expiry timestamp. There's no permanent unlock state and no UI to extend the window.
Companion monitoring
A separate companion extension watches whether the main extension is installed. If either is removed, your partner is notified immediately via the long-lived companion token flow.
Calibrated escalation
Partner notifications fire at meaningful thresholds — three attempts in an hour, six attempts, extension removal — not on every block. Alert fatigue is the enemy of accountability.
Therapeutic intervention
At the fifth attempt in a rolling hour, the standard block page is replaced by a structured therapeutic pause — a finite countdown, a coping choice, a warm close. Built from urge-surfing and implementation-intention research.
Logout requires partner approval too
The obvious workaround — log out, reinstall, start fresh — also requires the partner code. Even full account deletion requires the partner to know.
The architecture is the product.
Every other tool tries to make blocking smarter. ShieldBet makes removal harder. That's the difference that holds when willpower doesn't.