DET-SIGNUP-002 — email pattern anomaly

Rule ID: DET-SIGNUP-002 Title: N waitlist signups within 5 minutes sharing an email subdomain or local-part pattern Category: signup Last validated: 2026-06-04 (initial catalog) State: live — queries waitlist_signups directly

Telemetry source

• Postgres table waitlist_signups, email + created_at columns.
• Same FLAG_WAITLIST_DATASTORE gating as DET-SIGNUP-001.

Statistical method + baseline window

• Method: pattern-share detection over rolling 5-minute window. Pattern derivation:
• Domain: the email domain part (@example.com).
• Local-part regex shape: the email local-part collapsed to its character-class signature (letters → L, digits → D, separators preserved). E.g. alice.smith42 → LLLLL.LLLLLDD.
• Baseline window: rolling 7 days for domain frequency; 24h for local-part-shape frequency.
• Fire condition (domain): >= 5 signups sharing a domain within 5 min, AND the domain's prior 7d total signup count < 3 (excludes gmail/yahoo/icloud which legitimately cluster).
• Fire condition (local-part shape): >= 4 signups sharing the exact character-class signature within 5 min.

Threshold + expected FP rate

• Threshold: as above; no dynamic baseline (pattern detection is rule-based, not statistical).
• Expected FP rate: ~1 per quarter pre-launch. Family/friend groups signing up together can share a domain (e.g., a 5-person small-business signup). Confirm by checking if domain has MX records that resolve to a real provider.

Alert route

• MEDIUM (single fire, domain pattern): ops@ daily digest.
• HIGH (domain pattern + same window co-fire with DET-SIGNUP-001): #raxx-ops-alert-sev2-5 / #raxx-ops-alert-sev2. Compound signal = bot signature.
• LOW (local-part shape only, no domain cluster): silent log.

Escalation owner

• operator — list quality decision.
• security-agent for HIGH cluster pairings.

Test fixture / synthetic positive

See _fixtures/email_pattern_anomaly_positive.json for a synthetic 6-signup cluster sharing domain tempmail-X9.test within 4 minutes.

What to do when this fires

1. Inspect the email cluster. Look-alike service domain? Disposable-email provider? Synth pattern?
2. Cross-check with DET-SIGNUP-001 — co-fire = bot.
3. If confirmed bot: do not delete rows automatically; tag the rows as suspected-bot (operator-only column or comment) and leave for batch cleanup decision.
4. If confirmed organic small-business cluster: log to _log/ as known FP, do not tune the rule down.

What NOT to do

• Do not block the domain proactively. Domain-block is operator-only and should be a deliberate posture decision, not a per-fire reaction.
• Do not tighten the threshold below 4 — small organic groups will start tripping it.
• Do not add a whitelist of "good" domains (gmail, etc.) inline in the rule code. Whitelist via configuration so operator can audit.