The hardest part of end-to-end testing isn't writing the first suite. It's the third month, when the product has moved on and the suite quietly stopped describing it. Regeneration solves that — as long as it never changes behaviour behind your back.
Why coverage decays
Every release adds routes, renames labels, and reorders flows. A suite written against last quarter's UI keeps passing on the parts that didn't move and stops exercising everything that did. Pass rate stays green while real coverage shrinks, which is the most expensive failure mode in QA because nobody sees it happen.
Regeneration modes
Assertive supports three: merge, where a new generation is diffed against the current set and you accept changes step by step; additive, where only newly discovered journeys are proposed and existing scenarios are untouched; and snapshot, where the whole set is captured as a versioned artifact you can restore later. Most teams run additive weekly and merge after a major release.
Pinning stops silent drift
Any scenario can be pinned to the agent version that produced it. Pinned scenarios are skipped by regeneration, so an agent upgrade cannot alter the behaviour of a flow you have already signed off. Unpin deliberately, review the diff, and re-pin — the audit trail records who did which.
Review before you accept
Every regeneration produces a side-by-side diff showing added, removed and modified steps, plus a change hash and the agent version that generated it. Nothing enters your suite until a human approves the diff. That single rule is what separates a governed platform from an agent that rewrites your tests overnight.
Where to run it
Generation can run in the cloud against a public staging URL, or entirely inside your network with the on-prem Runner when the target application is not reachable from the internet. Either way the output is the same reviewable artifact — see the runner and CI docs for wiring it into a pipeline.