# Use a redacted session replay as supporting evidence

> Inspect one authorized, consented recording around a reported problem, distinguish rendered observations from inference, and avoid treating replay as automatic root cause.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/session-replay-investigation
- Execution mode: human_review
- Immutable automation template: none
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, content-media
- Required example events: page_view, outcome_failed
- Required Agentry resources: users, session_replays, cases
- Do not use when:
  - Do not inspect replay without authorization, consent, redaction, and a specific support or debugging purpose.
  - Do not infer clicks, form contents, network failures, or root cause from rrweb event types or timestamps alone.
  - Do not expose raw identities, form values, tokens, payment data, or unrelated parts of the session.
- Ask before using:
  - Which exact project, authorized distinct_id, reported timestamp, and expected outcome identify the relevant recording?
  - Which consent, sampling, and redaction policy applies to this user and page?
  - What rendering or replay-viewing capability will turn snapshots into visible evidence rather than guessed semantics?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## Why this matters

A stack can show where code failed; a replay can show visible interaction around
the failure. Neither proves root cause by itself. Replays are also high-risk
customer data and should be inspected only for a specific authorized purpose.

Agentry can locate recent recordings for an authorized `distinct_id` and return
snapshot data. Snapshot types and timestamps are rrweb data—not a natural-
language narrative. Meaningful interpretation requires an actual replay renderer
or another tool that can faithfully reconstruct the relevant segment.

## What you get

- One recording selected by exact identity and time bounds
- A minimal rendered segment around the reported outcome
- Visible observations separated from network, case, and code evidence
- A diagnosis hypothesis and next test, not an automatic root-cause claim

## Walk through it

**You:**
> Review the consented replay for the checkout problem reported at 14:20 UTC.

**Agent:**
> I will confirm the authorized identity and policy, locate the nearest recording,
> and render only the relevant segment.

```http
GET /v1/projects/:project_id/users/:distinct_id/summary
GET /v1/projects/:project_id/session-replays?distinct_id=:distinct_id&date_from=:rfc3339&date_to=:rfc3339
GET /v1/projects/:project_id/session-replays/:replay_id/snapshots
```

Fetch the current OpenAPI schema for exact query parameters and response fields.
Do not copy an email address directly into documentation or logs; URL-encode the
authorized project identity at call time.

Render the bounded snapshot interval with a faithful rrweb-compatible viewer.
Record only observable facts such as “the user selected the submit control and
the page displayed an error state.” A raw snapshot with `type: 3` does not prove
which element was clicked or what a form contained.

If a real case ID or fingerprint is available, inspect it separately:

```http
GET /v1/cases/:case_id
```

Correlate by time, session/release identifiers, and observed evidence. A nearby
case is not automatically caused by the visible interaction.

## The output

```text
Replay review — <replay id> — <bounded interval>

Authorization and privacy
- purpose, consent/redaction policy, reviewer

Visible observations
- <rendered fact with timestamp>

Separate technical evidence
- <case/network/deploy fact from its own source>

Hypothesis
- <possible explanation, explicitly labelled>

Next verification
- <reproduction, code inspection, or additional telemetry>
```

## Setting it up

Configure replay in an authenticated interactive owner session using the current
OpenAPI schema. Load the required browser recorder only after consent, sampling,
and redaction decisions are implemented. Mask inputs by default and exclude
authentication, payment, health, secret, and other sensitive surfaces.

Use stable pseudonymous identities and session IDs across the relevant product
events. Replays do not replace structured success/failure events or runtime error
capture.

## Variations

- *"Inspect only the 90 seconds around the reported failure."*
- *"Compare visible behavior with the selected real case without claiming causality."*
- *"Explain why this replay is not safe or sufficient to inspect."*
- *"Prepare a minimal reproduction checklist from verified observations."*