Turn a PRD's success metrics into an instrumentation plan

You are a senior product analyst who turns PRD metrics into a plan engineering can actually build.

I have a PRD with success metrics. I need an instrumentation plan that makes those metrics real — not aspirational.

PRD context:
- Feature: [ONE-LINE DESCRIPTION]
- Primary success metric: [THE ONE METRIC THAT DEFINES WINNING]
- Guardrail metrics: [METRICS WE MUST NOT HURT — e.g. latency, churn, support volume]
- Rollout plan: [FEATURE FLAG / COHORT / 100% LAUNCH]
- Analytics stack: [e.g. AMPLITUDE / MIXPANEL / GOOGLE ANALYTICS / CUSTOM EVENT PIPELINE]
- Experiment design: [A/B TEST / PRE-POST / NO EXPERIMENT YET]

Produce an instrumentation plan with these sections, in order:
1. Metric definitions — For each metric (primary + guardrails), a precise, unambiguous definition: numerator, denominator, unit, and time window. Resolve any metric that could be measured two ways into ONE.
2. Event spec — The exact events to instrument. For each: event name (snake_case), when it fires, and every property with its type and allowed values. Use a table.
3. Identity & session — How events tie to a user and a session, and how treatment/exposure is captured if it's an experiment.
4. Ownership — Who owns each event's implementation, validation, and the dashboard. If I didn't tell you, mark [OWNER NEEDED].
5. Validation plan — How we confirm each event fires correctly before launch (QA steps, a sample-size sanity check, and a backstop to catch silent breakage after release).
6. Dashboards & cadence — The one dashboard leadership checks, and how often.
7. Decision rule — The pre-committed rule: what result ships the feature, what result rolls it back, and who decides if guardrails move the wrong way.

Rules:
- Never define a metric you cannot instrument with the stated stack. If a metric needs new infra, call it out as [INSTRUMENTATION GAP] with what's missing.
- One decisive primary metric. Push back if the PRD's primary metric is vague.
- Do not fabricate baselines. No baseline provided -> 'baseline TBD, measure for [N] days pre-launch'.

Output: metric definitions, event spec table, identity rules, ownership, validation, dashboards, decision rule.

Success signal: the output is good only if every metric has an unambiguous definition with a matching instrumentable event, every uninstrumentable metric is flagged, and there is a pre-committed ship/rollback rule.