# INP Evidence Packet

Use this worksheet with [How to Optimize INP: A Field-to-Trace Workflow](/insights/inp-optimization-field-to-trace-workflow). Duplicate it for each affected route template or independent interaction cause. Blank values are not measured results.

## 1. Investigation identity

| Field | Value |
|---|---|
| Investigation owner | |
| Technical reviewer | |
| Product or route owner | |
| Accessibility reviewer | |
| Opened on | |
| Target release | |
| Decision deadline | |
| Current state | Baseline / reproducing / candidate fix / staged / validating / closed |

## 2. Field cohort record

### Cohort definition

| Field | Baseline | Candidate or release |
|---|---|---|
| Stable route template | | |
| Device class | | |
| Browser scope | | |
| Market or deployment region | | |
| Release ID | | |
| Feature-flag state | | |
| Consent state | | |
| Interaction type | | |
| Approved component label | | |
| Collection period | | |
| Sampling rule and rate | | |
| Qualifying visit count | | |
| Visits without a qualifying interaction | | |
| Missing or blocked telemetry notes | | |

### Performance distribution

Record the same percentiles for equivalent cohorts. Do not fill gaps with estimates.

| Measurement | Baseline p50 | Baseline p75 | Baseline p95 | Release p50 | Release p75 | Release p95 |
|---|---:|---:|---:|---:|---:|---:|
| INP | | | | | | |
| Input delay | | | | | | |
| Processing duration | | | | | | |
| Presentation delay | | | | | | |

### Aggregate discovery sources

| Source | URL group or origin | Observation | What it cannot establish |
|---|---|---|---|
| Search Console Core Web Vitals | | | Slow interaction or source-code cause |
| CrUX | | | Component-level cause or release attribution |
| Other | | | |

## 3. Privacy and telemetry review

Use an allow-list. A blank row is not approval to collect a field.

| Field | Purpose | Allowed value or transformation | Retention | Access owner | Approved? |
|---|---|---|---|---|---|
| Stable route template | Cohort comparison | Named application template; no URL parameters | | | |
| Release ID | Release comparison | Deployment identifier | | | |
| Metric ID | Deduplicate callback updates | Library-generated metric identifier | | | |
| INP value and rating | Responsiveness distribution | Numeric value and library rating | | | |
| Interaction type | Pointer/keyboard cohort | Enum only | | | |
| Component label | Interaction attribution | Approved `data-rum-component` allow-list | | | |
| Load state | Startup/post-load distinction | Library enum | | | |
| Three phase timings | Phase diagnosis | Numeric values | | | |
| Long Animation Frame count | Coarse supporting evidence | Count only | | | |

### Prohibited by default

- [ ] No user-entered text or form values
- [ ] No account, order, email, or customer identifier
- [ ] No unrestricted URL, query string, or fragment
- [ ] No raw DOM text or unrestricted selector
- [ ] No unrestricted script URL, stack, or source excerpt
- [ ] No persistent cross-site identifier
- [ ] No unreviewed event payload

### Collection behavior

| Question | Answer |
|---|---|
| What consent or legal basis applies? | |
| What happens when telemetry is blocked? | |
| What happens when `sendBeacon()` returns `false`? | |
| How are repeated `reportAllChanges` callbacks stored? | |
| What is the sampling decision point? | |
| How is sampling bias monitored? | |
| How are expired records deleted? | |

## 4. DevTools reproduction record

### Field hypothesis

Complete before recording:

> On `[route template]`, `[device/browser cohort]` users performing `[interaction]` on `[component label]` show high `[input delay / processing duration / presentation delay]`, likely because `[observable mechanism]`.

### Reproduction conditions

| Field | Baseline trace | Candidate trace |
|---|---|---|
| Build or release | | |
| Environment | | |
| Browser and version | | |
| Device or CPU profile | | |
| Network profile | | |
| Data volume and state | | |
| Authentication and consent state | | |
| Feature flags | | |
| Cache or warm/cold state | | |
| Exact setup steps | | |
| Exact interaction | | |
| Trace filename or link | | |
| Reproduction count | | |
| Successful reproductions | | |

### Trace findings

| Question | Baseline | Candidate |
|---|---|---|
| Interaction located in trace? | | |
| Interaction duration | | |
| Input delay | | |
| Processing duration | | |
| Presentation delay | | |
| Dominant phase | | |
| Responsible main-thread or rendering work | | |
| Initiator or owning component | | |
| Third-party overlap | | |
| Long Animation Frame evidence | | |
| Alternative explanations | | |

## 5. Phase-to-fix hypothesis

| Field | Value |
|---|---|
| Observed mechanism | |
| Evidence connecting it to the interaction | |
| Proposed intervention | |
| Expected affected phase | |
| Smallest safe experiment | |
| Correctness risk | |
| Accessibility risk | |
| Privacy or security risk | |
| Product guardrail | |
| Technical guardrail | |
| Falsification condition | |
| Rollback owner and method | |

### Candidate comparison

| Candidate | Evidence addressed | Expected benefit | Cost or risk | Decision |
|---|---|---|---|---|
| Remove work | | | | |
| Reduce work | | | | |
| Defer or yield independent work | | | | |
| Narrow render scope | | | | |
| Move suitable computation | | | | |
| Architecture change | | | | |

## 6. Functional and accessibility checks

- [ ] Pointer interaction remains correct
- [ ] Keyboard interaction remains correct
- [ ] Focus order and focus return remain correct
- [ ] Loading, success, validation, and error feedback remain perceivable
- [ ] Repeated actions do not create stale state or duplicate submission
- [ ] Back, forward, refresh, and recovery behavior remain correct where relevant
- [ ] Screen-reader name, role, state, and announcements remain correct
- [ ] Reduced-motion and forced-colors behavior remain acceptable where relevant
- [ ] Visual output remains correct across supported viewport sizes
- [ ] Analytics and consent behavior remain correct

## 7. Release ledger

| Date/time | Release or flag | Exposure | Evidence checked | Guardrail result | Decision | Owner |
|---|---|---:|---|---|---|---|
| | | | Baseline | | | |
| | | | Pre-release traces | | | |
| | | | Early RUM | | | |
| | | | Expanded RUM | | | |
| | | | Mature CrUX/Search Console | | | |

### Decision record

| Field | Value |
|---|---|
| Final decision | Keep / revise / roll back / inconclusive |
| Evidence supporting the decision | |
| Cohorts improved | |
| Cohorts unchanged | |
| Cohorts regressed | |
| Unresolved interactions | |
| Telemetry limitations | |
| Traffic or release-mix limitations | |
| Follow-up owner and date | |

## 8. Outcome separation

Record these independently. Do not infer one from another.

| Outcome layer | Metric and cohort | Observation window | Result | Attribution confidence |
|---|---|---|---|---|
| Interaction responsiveness | | | | |
| Other Core Web Vitals | | | | |
| Errors and reliability | | | | |
| Accessibility and task completion | | | | |
| Crawl and index behavior | | | | |
| Search visibility | | | | |
| Product conversion | | | | |
| Revenue or qualified pipeline | | | | |

## 9. Closeout

- [ ] Baseline and release cohorts are comparable
- [ ] Trace evidence is retained
- [ ] Code and configuration changes are linked
- [ ] Privacy and accessibility reviews are complete
- [ ] Keep, revise, or rollback decision is explicit
- [ ] Uncertainty and missing data are documented
- [ ] Search and business outcomes are not presented as guaranteed consequences
- [ ] Next investigation is assigned only if evidence supports it