USE CASE · RELEASE VALIDATION
Make the critical path a repeatable release ritual.
Choose a handful of journeys whose failure would delay a deployment. Replay them locally, preserve the result and rerun the unchanged proof after a fix.
- Critical paths first
- Same proof after the fix
- Local review record
RELEASE REVIEW
Eight journeys. One changed state.
-
01
Sign-in passes
-
02
Checkout total passes
-
03
Account edit fails
-
04
Fix verified on rerun
Release rhythm
01 · CRITICAL PATHS
Automate the expensive doubt. Not every possible click.
Start with journeys tied to revenue, access or a high-cost operational workflow. Give each one a visible final assertion.
Three to eight journeys
A small set is easier to keep credible and review before every release.
Prioritize business impactName who reviews failures
A failing check needs a person who can distinguish product drift from an intentional change.
No unattended ambiguity02 · BEFORE RELEASE
Replay the saved proof. Inspect only what changed.
Run the deterministic journeys from the Mac that owns their authenticated state and evidence policy.
A current baseline
The final assertion and run-linked artifacts show the journey completed against this build.
Timestamped run stateA reviewable divergence
Open the exact step and its privacy-mode evidence instead of relying on a red status alone.
Local diagnostic context03 · AFTER THE FIX
Keep the journey stable. Rerun the evidence.
When the application changes, the same saved flow should prove the repaired state without rebuilding the test around the new result.
Failure to passing result
The unchanged journey captures the useful arc: baseline, detected drift and restored behavior.
Same observable assertionUse it next release
The value compounds when the team runs the same critical set without depending on the original author.
A ritual, not a demo