S2b: send-volume, webmail, recipient and subject-brand features

[jiashuoz]

Summary

Adds abusekit's second wave of v0 scoring features, addressing common bulk-phishing shapes:

• Send volume: sends_10m_max, sends_1h, sends_first_day
• Webmail concentration: webmail_recipient_share, webmail_sends_1h (config/webmail.yaml, extended with common country-variant domains)
• Recipient hashing: distinct_recipients_1h, plus a closed recipient_hash format
• Resource-kind aliases: common spelling variants for the "key" resource kind
• Brand matching: extra public brands (config/brands.yaml, reorganized alphabetically by category) plus an optional private brands_extra file (--brands-extra), and a new subject_brand_match feature (brand mentioned in the message subject, not just the resource/agent name)

This is a fresh implementation on a new branch from origin/main — it does not merge, rebase onto, or cherry-pick feat/s2b-send-and-brand-features (withdrawn/superseded, PR #6, left untouched).

Review fixes folded in

• B1 — established senders must not reach high on volume alone: every send-volume/webmail-volume feature is gated to 0 once a subject is more than 7 days old (youngAccountFactor), and sends_10m_max searches bounded history rather than an unbounded lifetime maximum, so the signal decays instead of persisting forever once set.
• B3 — brand tokenizing now splits on any Unicode punctuation/symbol rune (not a hand-picked list), so a brand followed by :, ,, !, ), " or / matches, and a possessive 's no longer glues onto the brand word.
• S1 — subject_brand_match is no longer suppressed by integration-adjacent words ("tracking", "api") inside the subject line itself; it is suppressed only when the SENDING ACCOUNT's own resource/agent name carries an integration token.
• S2 — subject_brand_match excludes any brand already credited by name_brand_match, capping the combined per-brand contribution.
• S4 — recipient_hash must match ^[A-Za-z0-9_:+/=-]{8,128}$.
• S5 — subject_line masks an email-shaped substring (@) instead of rejecting the whole event; every other field still rejects one outright.
• S6 — a recipient_hash paired with recipient_count > 1 is rejected (a hash represents exactly one recipient).
• S7 — webmail_sends_1h is computed directly from the trailing window, never as webmail_recipient_share * sends_1h; every sum caps its per-event recipient_count.
• S8 — config/webmail.yaml extended with common country-variant domains (hotmail.co.uk, outlook.fr, live.co.uk, yahoo.fr, yahoo.de, yahoo.co.jp, mail.ru, gmx.de, t-online.de, libero.it).
• N1 — a brand entry can be marked case-sensitive, for a short token that doubles as an ordinary English word (config/brands.yaml's UPS).
• N2 — a brand mentioned inside ordinary community-gathering text ("... group meetup", "... fan club") does not match.
• N3 — soft hyphen (U+00AD) and invisible separator (U+2063) are stripped alongside the existing zero-width characters.
• N4 — kind also accepts "api key", "API Key", "api_keys", "keys" (and a few more common variants) as aliases for "key".
• N5 — every new feature excludes future-dated events.
• N6 — recipient_count, if present, must be a positive integer.
• README documents --webmail and --brands-extra.

Fixture score table

Fixture	Score	Tier	Required band
reference_operator.jsonl	0.9996	high	[0.99, 1.0]
benign_transactional.jsonl	0.0143	low	[0.0, 0.05]
burst.jsonl (before first send)	0.9707	high	[0.9, 1.0]
burst.jsonl (final)	0.9788	high	[0.9, 1.0]
benign_fast_onboarding.jsonl	0.4014	medium	[0.15, 0.45]
benign_integration_heavy.jsonl	0.1602	low	[0.05, 0.35]
dormant_then_blast.jsonl	0.8957	high	[0.8, 0.98]
benign_self_send_only.jsonl	0.1802	low	[0.05, 0.35]
benign_receipts_fanout.jsonl	0.3732	low	[0.05, 0.4]
benign_selfsend_brandname.jsonl	0.1800	low	[0.05, 0.35]
benign_variant_a.jsonl	0.6491	medium	[0.35, 0.70]
webmail_blast.jsonl (new)	0.6948	medium	[0.55, 0.85]
single_brand_blast_45m.jsonl (new)	0.9916	high	[0.95, 1.0]
established_newsletter_burst.jsonl (new)	0.0734	low	[0.0, 0.2]
day0_marketplace_seller.jsonl (new)	0.7170	medium	[0.6, 0.78]

Every existing fixture keeps passing its previously-committed band; none needed retuning except benign_transactional.jsonl, which dropped recipient_hash from three multi-recipient batch sends (a pre-existing data-quality issue S6 now correctly catches — a hash paired with recipient_count > 1 is invalid).

Which fixture bounds which weight (sensitivity windows)

Measured against the shipped weights; "zero"/"half"/"double" are the resulting risk with that one weight set to 0x/0.5x/2x, everything else unchanged. The committed mutation test (TestWeightMutation_EveryWeightIsLoadBearing) checks the zeroing case for every weight in config/local_weights.yaml, including these seven; it passes only because at least one scenario per weight below moves outside its band.

Weight	Bounding scenario	Band	base	zero	half	double
sends_10m_max (0.012)	webmail_blast fixture	[0.55, 0.85]	0.6948	0.4068 (out)	0.5554	0.8832 (out)
webmail_recipient_share (1.1)	webmail_blast fixture	[0.55, 0.85]	0.6948	0.4311 (out)	0.5677	0.8724 (out)
webmail_sends_1h (0.014)	webmail_blast fixture	[0.55, 0.85]	0.6948	0.3595 (out)	0.5306	0.9023 (out)
subject_brand_match (1.5)	isolated synthetic scenario (backdrop + subject_brand_match=1)	[0.5, 0.68]	0.5793	0.2351 (out)	0.3941 (out)	0.8606 (out)
sends_1h (0.0008)	isolated synthetic scenario (backdrop + sends_1h=300)	[0.26, 0.32]	0.2809	0.2351 (out)	0.2573 (out)	0.3318 (out)
sends_first_day (0.0008)	isolated synthetic scenario (backdrop + sends_first_day=300)	[0.26, 0.32]	0.2809	0.2351 (out)	0.2573 (out)	0.3318 (out)
distinct_recipients_1h (0.0008)	isolated synthetic scenario (backdrop + distinct_recipients_1h=300)	[0.26, 0.32]	0.2809	0.2351 (out)	0.2573 (out)	0.3318 (out)

sends_1h/sends_first_day/distinct_recipients_1h are deliberately small "companion" weights (correlated with sends_10m_max/webmail_sends_1h in every committed fixture that exercises them at all — the same resource_velocity_1h/resource_total relationship this repo already has), so no realistic fixture's band is tight enough to prove any one load-bearing alone; each gets its own isolated synthetic scenario, the same pattern already used for this repo's existing weak companion weights (resource_total, key_total, etc.). No weight was chosen to make a band's edge land exactly at the base score: every band above was set with a margin on both sides, single_brand_blast_45m's upper bound (0.9916 vs 1.0, margin 0.0084) being the tightest, since that fixture is already deep in the sigmoid's saturated tail — everywhere else the margin is >= 0.02.

day0_marketplace_seller.jsonl (base 0.7170, band [0.6, 0.78]) additionally exercises S2 in a realistic combined scenario: its agent is named after the fixture's fictional brand, so subject_brand_match correctly reports 0 (excluded by name_brand_match already crediting it) rather than double-counting.

Hygiene check

A repository-wide check for incident-specific phrasing ran before every commit and returned nothing.

Gates

gofmt -l ., go vet ./..., go test -short ./..., go test ./... (Postgres, ABUSEKIT_REQUIRE_DB=1), go test -race ./internal/..., go mod tidy, make lint, make test, make test-db all clean.

---

Round 2

Applied every item from review: blocker R1 (history-relative volume, no calendar-age cliff), should-fix R2–R8, hygiene H1–H2, and four nits. Each item shipped as its own commit with a failing test first. Full commit list: 3c822f3 R1, c15b0ee R2, 79f0e12 R3, abded4f R4, 77412ed R5, f871d36 R6, 78eca33 R7, e79cd50 R8, 98110f5 H1, 68197a8 nits.

R1 — history-relative volume, no calendar-age cliff

The hard 7-day gate is replaced: burst_factor = current 10m/1h volume ÷ max(1, prior daily-average or prior 10m peak over the preceding 30 days, excluding the trailing 24h), combined with ageDecayFactor = clamp(1 − (age_days − 3) / 27, 0.2, 1) — smooth, continuous, floored at 0.2, never a hard 0.

Continuity probe (synthetic account, fixed burst, only age varies):

age	risk
6d23h	0.9659
7d1h	0.9649
8d	0.9523

No cliff: each step moves by ≤ 0.011, versus the old gate's 0.98→0.01 swing across the same boundary.

Required outcomes (all four replay fixtures, ABUSEKIT_REQUIRE_DB=1 go test ./internal/worker/...):

Fixture	Requirement	Tier	Score
dormant_branded_burst_8d.jsonl (R1a)	at least medium, target high	high	0.9861
established_newsletter_burst.jsonl (R1b, pre-existing)	low	low	0.0832
paid_launch_5d.jsonl (R1c)	below high	low	0.2194
dormant_then_blast.jsonl (R1d, rebuilt — no brand-named agent, no resource burst)	high	high	0.8965

sends_10m_max's current-burst search is now bounded to a trailing 24h window (was whole-history).

Accepted trade-off: benign_receipts_fanout.jsonl moved from low (0.05–0.4) into low-medium (0.4771, new band [0.4, 0.55]) — required to give dormant_then_blast enough volume signal to reach high without a brand/resource burst. Documented in internal/worker/replay_test.go and mutation_test.go.

R2 — precise subject-suppression on integration names

Replaced the old whole-account "any resource name anywhere carries an integration token suppresses everything" rule with exemptSubjectBrands: only a live (not deleted), agent-kind resource's name is considered, and only the brand adjacent to the integration token in that name is exempted — never all subject matching. New tests: a key named api no longer suppresses anything; a deleted agent named sync no longer suppresses anything.

R3 — community-word gate as whole phrases, subjects only

Bare single words (chat, group, fans, club, community, meetup) replaced with contiguous phrases (group meetup, fan club, community event), applied only to MatchedBrandNamesForSubject — never to MatchedBrandNames, restoring name_brand_match for an agent literally named "<brand> Support Chat". "<brand>: chat with support" now matches; "<brand> group meetup" does not.

Known gap, documented and accepted: community_group_photo_walk.jsonl (day-0, 80 webmail recipients/10 min, "Fictabook photo walk this Saturday" — no community phrase) scores high (0.9993), same as any other day-0 branded burst. Getting it below high would require either muting fresh-account volume (breaks R1's dormant/8-day-old requirements) or adding a phrase this subject doesn't contain — chose to keep R1's outcomes and document the gap in TestReplay_CommunityGroupPhotoWalkKnownGap.

R4 — subject_brand_match excludes self-sends

subjectBrandMatch's loop now skips isSelfSend events, matching design's own contract.

R5 — tier envelope

Fixture	Scenario	Tier	Score	Margin from cut (0.8)
single_brand_100_45m.jsonl	a hundred recipients/45 min, single brand	high	0.9853	0.1853
brand_colon_country_variant_20m.jsonl	60 recipients on hotmail.co.uk/20 min, brand followed by :	high	0.9771	0.1771
slow_sender_15_per_hour_6h.jsonl	same total volume as above, paced 15/hour over 6h	medium (known gap)	0.5674	— never reaches high

The slow-sender case is documented as a known gap of the local scorer in both internal/worker/replay_test.go's TestReplay_SlowSenderKnownGap and docs/design's §8 open-questions.

R6 — bound the new weights by real fixtures, commit the sweep

Replaced isolated synthetic scenarios for sends_1h, sends_first_day, distinct_recipients_1h, subject_brand_match with real replay fixtures, using distinct fixtures so a wiring swap between two features fails a test:

• moderate_volume_single_brand.jsonl — bounds subject_brand_match (15 webmail recipients, far too small alone, plus one brand mention).
• repeat_recipient_resend.jsonl — bounds sends_1h AND distinct_recipients_1h with genuinely DIFFERENT values (40 recipients contacted twice each; sends_1h's sum exceeds distinct_recipients_1h's deduplicated count).
• first_day_burst_then_quiet.jsonl — bounds sends_first_day, evaluated 26h after the subject's first event so the burst has aged out of every other current-window feature, isolating the one permanent-fact feature that hasn't.

TestWeightMutation_NewWeightsSurviveHalfAndDoubleSweep commits the ×0.5/×2 sweep as a test (not just a doc claim). Per-weight sweep results — for each of the 7 new weights, at least one scenario leaves its band at 0.5x or 2x:

Weight	Breaks at 0.5x	Breaks at 2x
sends_10m_max	dormant_then_blast, dormant_branded_burst_8d, webmail_spread_1h, repeat_recipient_resend	dormant_then_blast, day0_marketplace_seller, benign_receipts_fanout, paid_launch_5d, webmail_spread_1h, moderate_volume_single_brand, repeat_recipient_resend
sends_1h	(none)	repeat_recipient_resend
sends_first_day	first_day_burst_then_quiet	first_day_burst_then_quiet
webmail_recipient_share	webmail_spread_1h, moderate_volume_single_brand, repeat_recipient_resend, first_day_burst_then_quiet	established_newsletter_burst, day0_marketplace_seller, paid_launch_5d, webmail_spread_1h, moderate_volume_single_brand, repeat_recipient_resend, first_day_burst_then_quiet
webmail_sends_1h	repeat_recipient_resend	day0_marketplace_seller, webmail_spread_1h, repeat_recipient_resend
distinct_recipients_1h	(none)	repeat_recipient_resend
subject_brand_match	moderate_volume_single_brand	moderate_volume_single_brand

Corrected docs/plans' "every new weight bounded by a fixture" claim to describe the real mix (real fixtures plus a small isolated-synthetic residual before this round; now fully real-fixture-bounded).

R7 — generic brands in subjects

subject_brand_match is now multiplied by the same ageDecayFactor R1's volume features use, instead of exempting a fixed brand allowlist (apple/google/microsoft/amazon/stripe) — chosen because age-decay generalizes to every brand, not just five named ones, and reuses an already-reviewed mechanism. established_product_copy_brand_mention.jsonl (2-month-old paid account routinely sending "Our product now integrates with Glowbank Calendar") stays low (0.1023).

R8 — rollout: producer-supplied account age

subject.created accepts an optional account_created_at (RFC 3339), validated exactly at redaction. Extract prefers it over the derived "earliest ingested event" firstSeenAt whenever present, so every R1/R7 history-relative feature is correct from day one without a full event backfill.

unbackfilled_established_account.jsonl — a real, 60-day-old paid account whose only ingested history is its signup plus one 100-recipient newsletter send (no backfilled prior sends):

	Tier	Score
with account_created_at	low	0.2369
without account_created_at (identical events otherwise)	high	0.9996

H1 — generic category comments

config/brands.yaml's marketplace/social/shipping category comments no longer pair a category with a specific quoted lure theme; a new test (TestBrandsYAML_CategoryCommentsStayGeneric) fails if the removed phrases reappear.

Nits

• canonicalise now strips every Unicode category Cf rune (was a hand-enumerated 7-character allowlist) — also catches U+2064 (INVISIBLE PLUS) and U+180E (MONGOLIAN VOWEL SEPARATOR).
• The case-sensitive brand-token check NFKC-normalizes before comparing, so fullwidth "ＵＰＳ" is recognized like "UPS".
• config/webmail.yaml gains hotmail.fr/de/it/es, outlook.de, live.fr, yahoo.es, yahoo.com.br.
• content.sent's subject_line is now NFKC-folded unconditionally at redaction, not only on the branch where an email-shaped substring happened to be masked.

Full fixture scores (existing + all round-2 additions)

Fixture	Tier	Score
reference_operator.jsonl	high	0.9997
dormant_then_blast.jsonl (rebuilt, R1d)	high	0.8965
benign_receipts_fanout.jsonl (band widened, documented)	medium	0.4771
webmail_blast.jsonl	high	0.9992
established_newsletter_burst.jsonl	low	0.0832
day0_marketplace_seller.jsonl	medium	0.7657
dormant_branded_burst_8d.jsonl (R1a)	high	0.9861
paid_launch_5d.jsonl (R1c)	low	0.2194
webmail_spread_1h.jsonl (mutation coverage)	medium	0.7046
community_group_photo_walk.jsonl (R3, known gap)	high	0.9993
single_brand_100_45m.jsonl (R5)	high	0.9853
brand_colon_country_variant_20m.jsonl (R5)	high	0.9771
slow_sender_15_per_hour_6h.jsonl (R5, known gap)	medium	0.5674
moderate_volume_single_brand.jsonl (R6)	medium	0.7042
repeat_recipient_resend.jsonl (R6)	high	0.8648
first_day_burst_then_quiet.jsonl (R6, +26h)	medium	0.5843
established_product_copy_brand_mention.jsonl (R7)	low	0.1023
unbackfilled_established_account.jsonl (R8, with field)	low	0.2369

Hygiene check

Hygiene check clean.

Gates (round 2)

gofmt -l ., go vet ./..., go build ./..., go test ./... (short and DB-backed via ABUSEKIT_REQUIRE_DB=1), go test -race ./internal/..., go mod tidy (no diff), make lint all clean before every commit.

---

Updated for main

Merged origin/main (PR #5's S4 eval harness + PR #8's design doc) via git merge (no rebase, no force-push). One conflict, doc-only: eval/fixtures/README.md (both sides had appended a new section) — resolved by keeping both sides' content, generic wording only.

The merge combined cleanly at the text level but not the type level: eval/replay.go's feature.Extract call predates S2b's WebmailSet parameter. Fixed by threading a feature.WebmailSet through the whole harness rather than patching just the one call site.

WebmailSet threading

• eval.LoadReplayDataset(in, brands, webmail, benignLabel) — webmail flows straight into every feature.Extract call. No package-level global, no panic on the zero value (feature.WebmailSet{} matches no domain, same as configuring none).
• abusekit eval gains --brands-extra and --webmail, named/env-var'd/defaulted identically to serve's own flags (main.go's parseServeFlags) — the harness now loads brands/brands-extra/webmail the same way a real deployment does.
• New test TestLoadReplayDataset_WebmailRecipientShareIsNonZero: a webmail-heavy replay subject scores a non-zero webmail_recipient_share through the harness, and the identical subject against an empty WebmailSet reads back to 0 — verified load-bearing by temporarily reverting the wiring and confirming the test catches it.

F9 TODO — webmail-blast and subject-lure corpus families

Every other eval/gen family's recipient_domain is a synthetic .example.test name and no family ever sets subject_line at all, so webmail_recipient_share/webmail_sends_1h/subject_brand_match read 0 across the entire synthetic corpus regardless of the wiring fix above. Two new abusive families close that gap:

• abusive_webmail_blast — same fast decline/success/upgrade/resource-burst shape as abusive_fast, then a content.sent blast to REAL consumer webmail domains (config/webmail.yaml's own list — a public fact, not customer data).
• abusive_subject_lure — same shape, then a blast whose subject_line carries a FICTIONAL brand lure (eval/fixtures/test_brands.yaml's Fictabook/Fictashop/Glowbank — never a real one; a full lure sentence is a stricter hygiene bar than a bare resource name).

Regenerated eval/fixtures/synthetic/{events,labels}.jsonl deterministically from the documented seed (20260927) — confirmed byte-identical across two runs. 20 families, 297 subjects (was 18 families, 286). Makefile's gate target now passes --brands-extra eval/fixtures/test_brands.yaml so the fictional lure brand is recognized when scoring this corpus.

Floors: old -> new

The new features and families change scores. Every floor was checked against a fresh run, same margin policy eval/floors.yaml documents, weights untouched:

Metric	Old baseline	New baseline	Old floor	New floor
precision	0.8036 (45/56)	0.8169 (58/71)	0.72	0.72 (unchanged)
recall	0.8333 (45/54)	0.8788 (58/66)	0.77	0.77 (unchanged)
AUROC	0.9735	0.9819	0.93	0.93 (unchanged)
high-tier recall	0.7222 (39/54)	0.7879 (52/66)	0.60	0.60 (unchanged)
family: burst	0.8333 (5/6)	0.8333 (5/6)	0.60	0.60 (unchanged)
family: churn_incarnation_ge3	1.0 (18/18)	1.0 (18/18)	0.85	0.85 (unchanged)
family: dormant_then_blast	1.0 (6/6)	1.0 (6/6)	0.60	0.60 (unchanged)
max_ece	0.1108	0.1265	0.115	0.132

Every floor except max_ece held with MORE margin than before, not less — none were re-derived beyond confirming they still clear (per "do not tune weights," none were tightened either). max_ece broke on its own, before any weight was touched: the feature-set change alone moved baseline ECE from 0.1108 to 0.1265 (seven new hand-set, unfitted weight dimensions — an expected calibration cost, not a regression), already past the old 0.115 floor. Re-derived to 0.132 (baseline + 0.0055, the same deliberately-tight margin T5 documented), confirmed to still catch subject_age_h zeroed (ECE 0.1509) and upgrade_delay_min zeroed (ECE 0.1378) — TestGate_NegativeWeightRegressionCaughtByTightECEFloor passes unmodified against the new corpus.

min_high_tier_recall's old three-way exact-tie observation (zeroing burst_ratio_24h_vs_lifetime/first_day_distinct_domains/linked_labelled_abusive_n each landing on 34/54) no longer holds against the new corpus — those three now give 0.7273 (48/66), 0.6970 (46/66), 0.7121 (47/66) respectively (different corpus composition, no longer coincidentally equal). The floor stays at 0.60 regardless: it sits safely below all three (wider margin than before) while still catching the one weight this corpus's floors independently catch when zeroed, resource_velocity_1h (0.5152, 34/66). first_day_distinct_domains, self_send_before_external, and linked_deleted_n remain — honestly, same as before — not independently caught by any current floor when zeroed alone.

New synthetic-corpus metrics (2026-09-29 run, --brands-extra eval/fixtures/test_brands.yaml)

Metric	Value
precision	0.8169 (58/71)
recall	0.8788 (58/66)
F1	0.8467
AUROC	0.9819
ECE	0.1265
high-tier recall	0.7879 (52/66)
high-tier precision	1.0000 (52/52)
family: burst	0.8333 (5/6)
family: churn_incarnation_ge3	1.0000 (18/18)
family: dormant_then_blast	1.0000 (6/6)

Full weight-zeroing sweep (25 weights, new corpus)

Every config/local_weights.yaml weight zeroed one at a time, re-run against the regenerated corpus (--brands-extra eval/fixtures/test_brands.yaml):

Weight zeroed	precision	recall	ECE	AUROC	high-tier recall
burst_ratio_24h_vs_lifetime	0.8889	0.8485	0.1020	0.9839	0.7273 (48/66)
declines_before_first_success	0.8000	0.7879	0.1034	0.9629	0.6667 (44/66)
distinct_recipients_1h	0.8169	0.8788	0.1252	0.9825	0.7879 (52/66)
fingerprint_seen_on_other_subjects	0.8169	0.8788	0.1215	0.9819	0.7879 (52/66)
first_day_distinct_domains	1.0000	0.8636	0.0642	0.9920	0.6970 (46/66)
first_funding_prepaid	0.8088	0.8333	0.1102	0.9681	0.7424 (49/66)
key_total	0.8169	0.8788	0.1260	0.9821	0.7879 (52/66)
key_velocity_1h	0.8788	0.8788	0.1291	0.9854	0.6970 (46/66)
linked_deleted_n	0.8116	0.8485	0.1216	0.9790	0.7273 (48/66)
linked_labelled_abusive_n	0.8116	0.8485	0.1216	0.9771	0.7121 (47/66)
name_brand_match	0.8030	0.8030	0.1052	0.9597	0.7121 (47/66)
name_has_at	0.8169	0.8788	0.1265	0.9819	0.7879 (52/66)
neighbors_truncated	0.8169	0.8788	0.1265	0.9819	0.7879 (52/66)
resource_total	0.8261	0.8636	0.1196	0.9815	0.7727 (51/66)
resource_velocity_1h	1.0000	0.6970	0.0776	0.9747	0.5152 (34/66)
self_send_before_external	0.9818	0.8182	0.0940	0.9784	0.7879 (52/66)
sends_10m_max	0.8382	0.8636	0.1130	0.9845	0.7879 (52/66)
sends_1h	0.8169	0.8788	0.1255	0.9824	0.7879 (52/66)
sends_first_day	0.8169	0.8788	0.1261	0.9824	0.7879 (52/66)
subject_age_h	0.8219	0.9091	0.1509	0.9835	0.8333 (55/66)
subject_brand_match	0.8169	0.8788	0.1266	0.9819	0.7879 (52/66)
upgrade_delay_min	0.8219	0.9091	0.1378	0.9840	0.8333 (55/66)
upgraded	0.7833	0.7121	0.1198	0.9469	0.6515 (43/66)
webmail_recipient_share	0.8169	0.8788	0.1266	0.9819	0.7879 (52/66)
webmail_sends_1h	0.8169	0.8788	0.1265	0.9819	0.7879 (52/66)

Baseline (no weight zeroed): precision 0.8169, recall 0.8788, ECE 0.1265, AUROC 0.9819, high-tier recall 0.7879 (52/66).

The two bolded ECE values (subject_age_h, upgrade_delay_min) are the negative-weight regressions max_ece's tight margin exists to catch — both exceed the new 0.132 floor. resource_velocity_1h's bolded high-tier recall (0.5152) is the one weight this corpus's min_high_tier_recall floor independently catches on its own. Every S2b weight this PR added (sends_10m_max, sends_1h, sends_first_day, webmail_recipient_share, webmail_sends_1h, distinct_recipients_1h, subject_brand_match) shows little-to-no aggregate-corpus movement when zeroed alone — expected and already documented in eval/floors.yaml's own note that several existing weights (first_day_distinct_domains, self_send_before_external, linked_deleted_n) aren't independently caught by any corpus-level floor either; these seven weights' load-bearing-ness is proven at the fixture level instead, via internal/worker's own mutation tests (TestWeightMutation_EveryWeightIsLoadBearing, TestWeightMutation_NewWeightsSurviveHalfAndDoubleSweep), not by this aggregate gate.

Test counts

• eval package: 35 tests, all passing (34 before this update, +1 new: TestLoadReplayDataset_WebmailRecipientShareIsNonZero; every other LoadReplayDataset call site across the package's tests updated in place for the new WebmailSet parameter).
• eval/gen package: 5 tests, all passing, unchanged count (TestGenerate_Deterministic, TestGenerate_FamilyCoverage, TestGenerate_EventsValidateAndRedact, TestGenerate_RoundTripsThroughLoadReplayDataset, TestGenerate_RecallVariesWithSeed) — TestGenerate_RecallVariesWithSeed now also loads and threads config/webmail.yaml.
• cmd/abusekit package: all 10 TestRunEval_* tests passing. 6 were broken by webmail loading becoming unconditional in runEval (each ran from a tmp dir with no config/ subdirectory to resolve the relative default against) — fixed by adding an explicit --webmail flag, the same way --brands already was; a 7th (TestRunEval_UnknownRuleAndScorerAreBadInput) was passing only because it happens to fail on an UNRELATED check with the same exit code, so it got the flag added too so it actually exercises what it claims to.
• Full repo: go build ./..., go vet ./..., go test -short ./..., go test ./... (Postgres, ABUSEKIT_REQUIRE_DB=1), go test -race ./internal/... ./eval/..., go mod tidy (no diff), make lint, make test, make test-db, make gate all clean.

Hygiene check

Hygiene check clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_014cdM7WyRc3mD3vQNXMTDB8