Designing Replay Vision scanners

A scanner is one prompt applied to one recording at a time. It watches the recording and writes an observation. Replay Vision fixes the watching part. It does not fix the thinking part. The thinking is the design work this skill covers.

Every scanner that produces useful observations shares three properties:

1. One focused question that only the recording can answer.
2. A recording query that selects only sessions able to answer it.
3. Permission to answer no or inconclusive.

Design in this order: question, type, query, prompt, model, first-batch test. Then hand off to [[creating-replay-vision-scanners]] for sizing and the create call.

Step 1: Test the question

Write the question in one sentence before you touch the API. Then run three checks.

Only the recording can answer it. If an event already answers the question, build an insight instead. A rage click event already proves the rage click. The scanner question must add something the event cannot: "did the clicked control actually fail?"

One recording answers it. A scanner sees one recording and cannot compare it with recordings it has never seen. Push every cross-session question to a scout, a digest, or product analytics. Comparisons between experiment variants, trends over time, and "how common is this" all live outside the scanner prompt.