[guardrail] Privacy guardrail: features we will deliberately never build

Purpose

A standing, referenceable list of capabilities we will not build, because they break the aggregate-only, no-individual-tracking contract that defines the privacy-first category. This is both an engineering constraint and the core of the brand.

Will NOT build

• Session replay / recordings (Umami v3, Clarity, Matomo)
• Heatmaps (Umami v3, Matomo)
• Individual visitor profiles / "Sessions" timelines (Umami)
• identify() / Distinct-IDs / cross-session user stitching (Umami)
• City / precise geolocation — country-only is the invariant (stricter than Plausible/Fathom)
• Any cookie / localStorage / device-persistent identifier
• Retargeting / ad-network / cross-site identity

Note

These are exactly the moves that cost Umami its purist credibility. Staying out is a feature. Any PR that approaches these should link here and be closed as wontfix unless this decision is explicitly revisited.

From the 2026-07-20 privacy-first competitive audit (vs. Plausible / Fathom / Simple Analytics / Umami).

Landed in 0a20a20 (on main):

• PRIVACY.md — the charter: guaranteed invariants + the "will never build" list.
• tests/unit/privacy-guardrails.test.ts — 7 executable guardrails that fail CI on drift (cookie/storage APIs in the tracker, city/region populated in the ingest, a replay/heatmap/fingerprint dep, or the visitor hash losing daily-rotation / per-site scoping / opacity).

Any PR approaching a listed non-goal now trips a red test and should link here.