Run each Journey Version in context.

Execute the intended outcome across declared contexts, keep functional, visual, and accessibility evidence together, then diagnose the change before it reaches Review.

Start with a Journey Inspect the evidence

Run 028Needs review

Run 028 showing Journey evidence, a visual difference, and diagnosis for the invitation dialog

The context is part of the result.

A Run does not turn a Journey into an anonymous pass. It records the exact version, environment, identity, and outcome being inspected.

01Journey Version
Invitation flow · version 7
02Declared context
Desktop · Light · en-US
03Run identity
Run 028 · pull request #1842
04Recorded result
Outcome proven · review required

Three kinds of evidence. One Run.

Functional, visual, and accessibility truth are peers. Each stays attached to the selected Journey Version and declared context.

Functional

Did the intended outcome occur through the recorded path?

Visual

What changed in the observed interface, and where?

Accessibility

Do names, focus, and interaction remain meaningful?

Diagnosis

See the difference before assigning blame.

Evidence makes the distinction explicit: product change, target or state mismatch, and runner or infrastructure failure are not the same consequence.

Finding: Invitation dialog bounds changed
Outcome: Still proven
Next owner: Review decision

Run diagnosis panel distinguishing a visual change from the completed invitation outcome

A Run hands the exact evidence to Review.

Review receives the selected Run, context, step, difference, evidence, and lineage—so the decision keeps its source instead of becoming a separate handoff.

See how Review records a decision

Execute the outcome you intend to keep.

Start with one Journey and retain the evidence every next version needs.

Start with a Journey Explore Journeys