Status: Phase 1 stub. Matures in Phase 5 per §8.1.

Statement

Telemetry rendered on diagnostic surfaces — counts, latencies, hashes, pubkey prefixes, event IDs — is for the operator behind the diagnostics token. It is never duplicated to product surfaces, never logged to third parties, and never persisted past the session unless explicitly required (DynamoDB analytics tables, with hashed IPs per DR-2).

Why

The audit's largest single leak class was production-fixture pollution (S-1, ~31 occurrences) — the visible failure mode of operator data crossing into user-visible output. The principle behind S-1 generalises: any data that exists for the operator's benefit must stop at the operator's surface. A pubkey prefix shown in /diagnostics/user-events should not appear in a hovercard on a messaging conversation.

This is partly a privacy property (truncated hex is still hex) and partly a coherence property (a product user reading a hex prefix in their own chat thinks the app is broken). Both reasons apply.

How

Diagnostic routes require DIAGNOSTICS_TOKEN (server) + NEXT_PUBLIC_DIAGNOSTICS_TOKEN (client) — see §VI of the copilot instructions
IP-bearing analytics endpoints hash IPs with a daily-rotating salt before persistence (DR-2)
Pubkeys are truncated in logs (pubkey.substring(0, 8) + '...') per §II
The S-1 ESLint rule + post-build scanner block fixture markers from leaking into .next/
Semantic separation: telemetry primitives (<TokenRow>, <IssueBadge>) are gated to the design-system diagnostics/ subdir and may not be imported from product routes

Phase 5 deepens this stub with the full telemetry taxonomy, per-endpoint citations, and the leak-detection automation roadmap.