DET-SIGNUP-001 — waitlist velocity per origin

Rule ID: DET-SIGNUP-001 Title: Waitlist signup rate per Origin header per minute exceeding 3σ above baseline Category: signup Last validated: 2026-06-04 (initial catalog) State: live — waitlist_signups table exists; FLAG_WAITLIST_DATASTORE-gated. Querying the table is the source.

Telemetry source

• Postgres table waitlist_signups written by backend_v2/api/routes/waitlist_signups.py on POST /api/waitlist/signup.
• Per-row fields available: email, source, created_at. Origin header (referrer source) lands in source per the route's intake schema.
• Gating: FLAG_WAITLIST_DATASTORE must be ON for rows to write. Per backend_v2/api/feature_flags.yaml:3608+, the flag is currently default OFF pending attorney/Privacy Policy alignment per project_cf_gate_and_attorney_hold_until_raxx_app_perfect. Detection fires meaningfully only once the flag is ON.

Statistical method + baseline window

• Method: Poisson tail test on signups-per-origin-per-minute; rolling 24h baseline (waitlist trickle is too sparse for 7d aggregation pre-launch).
• Baseline window: rolling 24 hours per source. If source is null or unset, default-bucket all as unknown and apply a single shared baseline.
• Fire condition: observed count for a 1-minute window > μ + 3σ AND count >= 10. Floor of 10 prevents low-traffic FPs.

Threshold + expected FP rate

• Pre-launch placeholder: >= 20 signups per source per 60s.
• Post-launch: dynamic 3σ on 24h Poisson baseline per source.
• Expected FP rate: < 1 per week. Legitimate marketing-push spikes (a tweet from a popular account, a Hacker News front-page hit) will fire. That's by design — operator wants to know about those too. Tag as confirmed-organic in _log/ rather than tuning the rule down.

Alert route

• HIGH (single fire with N >= 30): #raxx-ops-alert-sev2-5 (ET) / #raxx-ops-alert-sev2 (off-hours). Per-event — sudden organic spike OR botnet seeding both warrant immediate look.
• MEDIUM (single fire 10–29): ops@ daily digest.
• LOW (sustained background-elevated trend without burst): silent log.

Escalation owner

• operator — origin attribution + organic-vs-bot decision is operator-only.
• security-agent if signature looks botnet-shaped (per signup/email_pattern_anomaly correlation).

Test fixture / synthetic positive

See _fixtures/waitlist_velocity_per_origin_positive.json for a synthetic 24-signup burst from source=getraxx-landing-page within 50s.

What to do when this fires

1. Pull the 60s window's rows: emails, source, IPs (if persisted), user-agents.
2. Cross-reference with DET-SIGNUP-002 (signup_email_pattern_anomaly) — if both fire on the same window, treat as confirmed bot signature.
3. If emails look organic-distributed and IPs are diverse, mark as confirmed-organic and log for retro analysis.
4. If emails share a domain pattern OR IPs cluster in one ASN, dispatch security-agent for posture review (rate limit, CF rule, captcha consideration — operator decision).

What NOT to do

• Do not delete the suspect waitlist rows from this detection alone. That's operator-only.
• Do not silence the rule when a marketing campaign is expected. The campaign firing the rule is the success signal too.
• Do not increase the floor above 10 — the pre-launch baseline is very low and the floor is what prevents 2-signup-from-one-coffeeshop FPs.