> ## Documentation Index
> Fetch the complete documentation index at: https://docs.observerbee.com/llms.txt
> Use this file to discover all available pages before exploring further.

# States and the state engine

> How raw session recordings become a deduplicated map of your product's screens.

Raw session replays tell you what one user did. The state engine turns thousands of them into a single structural map of your product: which screens exist, and how users move between them.

## From replay to screens

Every recorded session is replayed server-side in a real browser. As the replay runs, the engine captures the screen at meaningful moments: significant DOM changes, clicks, and scroll dwell points. Each captured screen is a candidate for becoming, or matching, a state.

## Canonicalization

Two users on the same screen never see identical DOM. Usernames, timestamps, feed contents, and A/B variants all differ. Before comparison, each captured screen is canonicalized: dynamic content is ignored so that what remains describes the screen's structure rather than one user's data on it.

## Deduplication

Canonicalized screens are deduplicated across all sessions in the project. The engine combines several signals:

* **Perceptual hashing** of the rendered screen, to catch visually identical screens cheaply.
* **Visual and text embeddings**, to measure similarity when hashes alone are not conclusive.
* **An AI judge** for ambiguous cases, deciding whether two screens are really the same screen of the product.

The result is a **state**: one canonical screen of your product, with every session's traffic mapped onto it. A checkout page visited by 10,000 users in 10,000 slightly different renderings becomes one state with 10,000 visits.

## The state graph

States are connected by transitions: user A went from the pricing state to the signup state, and so did 4,000 others. Each transition is weighted by the real traffic that traversed it, giving you a graph of your product where edge weights are actual user behavior, not instrumentation you had to define up front.

Each state keeps representative screenshots, which the dashboard shows and the [agents](/concepts/agents-and-governance) use for analysis.

## Why this matters

* **No manual instrumentation.** You do not tag screens or define funnels by hand; the map is built from what users actually rendered.
* **Aggregate, not anecdote.** Questions like "where do users go after onboarding?" are answered from the whole graph, not a sample of replays.
* **A foundation for mining.** The path engine mines this graph to find [journeys and goals](/concepts/journeys-and-goals) with real drop-off numbers.