Self-learning and personal filters

Haven keeps two kinds of user-visible rules in one place, the personal filters screen: rules the user wrote, and rules the page-content watch taught itself. They behave the same way in the engine and are shown together, but they are not equally cheap to remove — and that difference is the point of this page.

Rules you add yourself#

Two kinds:

• Websites — a domain. Like every other domain rule it is a suffix rule, so adding example.com also covers its subdomains.
• Keywords — matched like a strong keyword, i.e. anywhere inside a domain label, with fuzzy and phonetic protection for longer words.

Input is sanitised before it is stored: URLs are reduced to a bare hostname, and keywords below a minimum length are refused, because a two-character keyword over-blocks catastrophically.

If a domain the user now wants blocked is currently on the allowlist, the allowlist entry is removed first. The newer, explicit "block this" intent should win.

Removing a rule you added yourself is a single tap. It was your decision; undoing it is also your decision.

Rules Haven learned#

When the page-content watch confirms a catch on a domain the lists did not know, Haven writes that domain into the personal filters. From then on the DNS layer refuses it before the page ever loads again.

Two separate records are kept, on purpose:

• The filter rule — this is the actual protection.
• The learned-site entry — the score at the moment of learning, the human-readable reasons, a structural fingerprint of the page, when it was first learned, when it was last seen and how often. This is the audit note.

The audit note never gates protection. If writing it fails, the block still stands. And if the filter rule was refused (for example because the host is fenced off from learning), nothing is recorded either — an audit note must never outlive a rule that was never written.

Overturning a learned rule#

A learned rule and a hand-typed rule used to share one ✕. That is right for a rule you set yourself and wrong for a casino the watch caught: one tap in a craving moment would undo a decision that was made calmly, with evidence on the screen.

But making every automatic rule expensive rebuilds a different trap: a detector mistake has to stay cheap to correct, or a bug becomes a wall the user cannot climb.

So the friction is proportional to the engine's own evidence, and only to that.

Two claims, one price#

The user picks one of two honest reasons:

• "This is not a gambling page." A correction — the engine was wrong.
• "I know what it is and I want in anyway." A decision — the engine was right.

Both cost exactly the same. Haven cannot verify which claim is true, so if "this is not gambling" were the fast lane, that is simply the button an impulse would press, and the wait on the other one would be decoration. Equal cost means there is nothing to gain by lying to yourself.

What the claim does change is the record. A correction and a decision read differently afterwards, in the log and in the message an accountability partner receives.

Weak and strong catches#

Haven grades how strong its own case was, from what it recorded at the time: how far past the block line the score landed, whether the domain was caught more than once, and how many independent signals fired.

• A weak catch — a single marginal sighting, which is what most detector mistakes look like — is released immediately.
• A strong catch waits out the user's own cooldown, escalating on repeated requests, exactly like switching protection off. If an accountability partner is paired, they are told.

The accepted cost of this design: a genuine false positive on a strongly-scoring page also waits. In exchange, the cheap correction survives where mistakes actually happen, and the structural false positives are fenced off before they can be learned at all.

A release that has been waited out but never collected expires after a week. A release someone asked for a month ago is not a decision they are still making, and leaving it armed would hand a future bad moment a pre-approved shortcut. Collecting is always a separate, deliberate tap — nothing unlocks by itself.

Blocking it again#

Anything released can be blocked again immediately, from the same screen. Strengthening protection never has a waiting period.

Self-repair#

Two automatic repairs run when the app starts:

• Fence top-up. The protected-host list can grow between releases; existing installs receive the additions rather than only new installs. This is skipped for any host the user still deliberately blocks, so the repair can never silently overrule them.
• Withdrawing poisoned rules. If the detector is corrected in a release, the domains it previously caught in error are still sitting in the personal filters, and the DNS layer refuses them before the watch would ever run again — so fixing the detector alone would leave the user with a silently broken site forever. Those rules are withdrawn on the next start.

The second repair only ever touches rules the engine wrote. A domain the user typed in themselves is a decision, not a bug, and is left alone.

Viewing the evidence#

Inspecting a learned rule — its score, its reasons, how often it was seen — is never gated. Only changing something is. Someone should always be able to see why their phone did what it did.