How Corexi measures

1. The walk

Autopilot signs in with the login you gave it (a test account, an authenticator secret, or a ready session), opens the product in a real browser set to your users' locale and timezone, and walks it as a new user would: it reads each screen, decides one action, does it, checks that something changed, and records the step. Guardrails keep it from paying, deleting, inviting, sending or signing out. A run ends at the screen target or the step budget; every step, including the ones that did nothing, is on the record.

2. What each screen is judged on

3. How a finding is made, and unmade

1. Written against a rule. The analysis cites one of 55 named guidelines (navigation, forms, tables, feedback, content, visual, accessibility, flow, conversion), each with its rationale and source (Nielsen Norman Group heuristics, WCAG, Baymard research, ISO 9241-11). The rule sets a ceiling on severity.
2. Checked against the page. Quoted evidence must exist in the page text; a bounding box must be on the image; an analytics-only claim is discarded.
3. Looked at twice. Every critical and high finding goes back to the model with the same image and one question: is this visible here? A finding the second look cannot see is dropped.
4. Deduplicated. Twins on one screen merge; a product-wide pattern (uppercase headers, placeholder-only fields, colour-only status) is one finding listing the screens it appears on.
5. Reconciled across runs. A finding seen again stays one row and takes the latest run's wording. One not seen on a revisited screen is marked "not seen this run" and only resolves when a second run also misses it, so one unlucky walk cannot declare a problem fixed. A resolved finding that returns is marked as back. "Not an issue" is remembered.

4. Severity and priority

Priorityorders the list and is shown on every card with its inputs: severity as impact (critical 80, high 60, medium 40, low 20), the screen's share of the product's sessions from Clarity or GA4 as exposure (10% or more +15, 2–10% +5, under 2% −10, unknown 0), the runs the finding was seen in as persistence (+5 per extra run, up to +10), and +5 when a rule confirmed it. Levels: P4 urgent at 85 and above, P3 at 65, P2 at 45, P1 at 25.

5. Behavioral data, fused per screen

When Microsoft Clarity, Google Analytics 4 or a Firebase-linked app property is connected, each screen gets its own numbers from the same window: sessions, sessions with rage clicks, dead clicks and quick-backs (Clarity, last 72 hours), sessions, views, engagement and bounce (GA4, last 7 days). A per-screen number counts only with at least 30 sessions and a rate above 2% for rage or dead clicks, 25% for quick-backs; below that it is noise and is not mentioned. Product-wide numbers say nothing about a screen. The product score blends the visual score with a bounded behavioral shift (±12 at most, less with thin coverage).

6. Flows as tasks

The screens of a run are grouped into the flows a person performs. Each flow reports the task in usability-research terms: the fewest steps a person who knows the product needs, the steps the agent took and the surplus, screen visits against distinct screens as lostness (Smith: √((N/S − 1)² + (R/N − 1)²), above 0.5 is lost), duration, actions that did nothing, handoffs to a human, whether the walk recovered, and whether the task was reached, reached with friction, or blocked. The flow's score starts at its weakest screen and loses points only for what a person would meet too: actions that changed nothing (3 each, up to 10) and hand-offs to a human (5, once). The agent's own wandering — surplus steps, lostness — is reported in the task numbers and never subtracted from the score.

7. Between releases

Every run is compared with the previous one: the product score then and now, the screens whose score dropped or improved most, screens seen for the first time and screens not reached, flows that moved, and findings opened, resolved and back. That comparison is the first thing the run summary says.

8. When a run cannot see enough

A capture can fail for reasons that have nothing to do with your product: a bot check, a session that expired mid-walk, a screen that never finished loading. When fewer than half the screens a run reached could be analysed, no score is saved at all and the run says why. A run like that is left out of your history and out of every comparison, so a bad afternoon on our side never shows up as your product getting worse. The same holds for the model service: if it stops answering, the run says the analysis service refused, not that your screens were empty.

9. How long a run takes

Long enough to be a real visit, short enough to start one and do something else: a small product is done inside a coffee break, a large one takes the better part of a lunch hour. The walk is deliberately unhurried, because a page judged before it finished rendering is a page judged wrongly. You do not have to wait for it: the run streams its steps live, and the summary arrives by email when it is done.

What is never a finding

• ·An analytics number alone ("product-wide dead clicks suggest…"). Numbers change a visible finding's severity; they are never a finding.
• ·A date in the current year called "future" or "test data".
• ·The product's language, diacritics, date or time formats.
• ·Uppercase column headers, placeholder-only search fields, a status shown by colour when text sits next to it, as anything above low.
• ·A phone-layout remark on a desktop walk, or a desktop convention on a phone walk.
• ·A list that is empty because the test account has no data, unless the empty state offers no way forward.
• ·Anything the model cannot see: sr-only text, aria attributes, focus styles, code.