Platform / Enterprise Applications / Release drift model

Calibrated model · synthetic rows · measured rates

What a vendor release does to an enterprise test suite. Measured rates, synthetic rows.

The charts on this page are computed from a synthetic dataset of 8,340 runs and 115,319 executed steps, generated to match rates measured on live Spec2RunAI runs against partner enterprise environments: a Guidewire PolicyCenter and an Insurity policy administration system, over nine months with two vendor releases each. Customer and partner agreements prevent publishing the run records themselves, so the rows are synthetic. The rates that shape them are not.

How to read this. Two kinds of number appear below. Rates — breakage before and after a release, recovery, verification coverage, replay, engagements per run, failure mix — were measured on real runs and carried into the model as its parameters. Counts — 8,340 runs, 1,559 selector breaks, 675 rewrites — are the size of the synthetic dataset and should not be read as production volumes.

Release dates in the model are representative, not the actual upgrade dates of the partner environments. Individual rows, test cases, and runs are generated and correspond to no customer record.

1 · Release windows

A vendor release multiplies step breakage by roughly four.

The view compares the share of executed steps that failed or were flagged for drift in the 14 days before each release with the 14 days after. Drift means the step passed but the wording it relied on no longer matches the page. The before and after rates are measured; the synthetic rows reproduce them around representative release dates.

Measured rates · synthetic rows0%1%2%3%4%5%Guidewire · release 1 — 14 days before: 0.79% of 3,309 steps0.8%Guidewire · release 1 — 14 days after: 4.02% of 3,360 steps4.0%Guidewirerelease 1 · 5.1×Guidewire · release 2 — 14 days before: 1.10% of 3,187 steps1.1%Guidewire · release 2 — 14 days after: 4.03% of 3,249 steps4.0%Guidewirerelease 2 · 3.7×Insurity · release 1 — 14 days before: 1.13% of 2,487 steps1.1%Insurity · release 1 — 14 days after: 4.14% of 2,849 steps4.1%Insurityrelease 1 · 3.7×Insurity · release 2 — 14 days before: 0.94% of 2,558 steps0.9%Insurity · release 2 — 14 days after: 3.92% of 2,727 steps3.9%Insurityrelease 2 · 4.2×
14 days before14 days after
Synthetic rows, measured rates. Four representative releases, two per environment. Post-release breakage sits at 3.9–4.1% against a baseline of 0.8–1.1%, an uplift of 3.7–5.1×. Release dates are representative.
Table view
WindowRunsStepsBrokenRate
Guidewire release 1, before2283,309260.79%
Guidewire release 1, after2343,3601354.02%
Guidewire release 2, before2283,187351.10%
Guidewire release 2, after2243,2491314.03%
Insurity release 1, before1762,487281.13%
Insurity release 1, after2052,8491184.14%
Insurity release 2, before1772,558240.94%
Insurity release 2, after1982,7271073.92%
2 · What happens to a broken step

Most selector breaks are recovered without a person. The wording changes only with one.

Two different things can happen when a page changes under a step. The engine can find the element another way and carry on — that is recovery, and the stored test does not change. Or the wording in the test no longer describes the page, so the engine proposes a clearer wording and a person decides. The two are kept apart because they have different owners.

Measured rates · synthetic rowsRecovered without a personRecovered without a person: 1,4331,433 (92%)Failed the stepFailed the step: 126126 (8%)
Synthetic rows, measured rates. Of 1,559 synthetic selector breaks, 1,433 (92%) were recovered by the engine and 126 (8%) failed the step with element-not-found.
Measured rates · synthetic rowsApproved by a personApproved by a person: 218218 (32%)DismissedDismissed: 155155 (23%)Awaiting reviewAwaiting review: 260260 (39%)Auto-applied (org-verified)Auto-applied (org-verified): 4242 (6%)
Synthetic rows, measured rates. 675 wording rewrites were suggested after drift. A person approved 218, dismissed 155, and 260 were still awaiting review; 42 were applied automatically because the same rewrite had already been verified elsewhere in the organization. The expected result of a step is never among the things a rewrite can change.
0.78Assertion Lock interventions per 1,000 executed steps (measured rate): times the engine proposed changing what a step verifies and was blocked.
77%of executed steps replayed from selector memory with no model call (measured rate).
791steps resolved by vision after the structural approach failed, 0.7% of executed steps.
3 in 1,000steps need a person after a vendor release: about 4% of steps break, and 92% of those recover automatically (derived from the two measured rates above).
47¢ → 9¢what a typical test case costs to run the first time and from the third run on, at $0.03 per AI engagement: 15.8 engagements on run one, 3.1 by run three (measured rates, published price).
3 · Verification coverage

A passing run is not a verified run. The gap is measurable.

Verification coverage is the share of a run’s steps whose expected result was checked and met. A step that ran and passed with nothing confirming the outcome counts as not verified. In the measured runs, 23% of executed steps had no expected result written by the tester, which is the main reason coverage sits below 100%: the engine cannot verify what nobody specified.

Measured rates · synthetic rows05001,0001,500Guidewire: 28 runs with 0–10% of steps verifiedInsurity: 23 runs with 0–10% of steps verified0–10%Guidewire: 44 runs with 10–20% of steps verifiedInsurity: 32 runs with 10–20% of steps verified10–20%Guidewire: 46 runs with 20–30% of steps verifiedInsurity: 38 runs with 20–30% of steps verified20–30%Guidewire: 43 runs with 30–40% of steps verifiedInsurity: 42 runs with 30–40% of steps verified30–40%Guidewire: 52 runs with 40–50% of steps verifiedInsurity: 73 runs with 40–50% of steps verified40–50%Guidewire: 351 runs with 50–60% of steps verifiedInsurity: 203 runs with 50–60% of steps verified50–60%Guidewire: 690 runs with 60–70% of steps verifiedInsurity: 634 runs with 60–70% of steps verified60–70%Guidewire: 1,451 runs with 70–80% of steps verifiedInsurity: 1,285 runs with 70–80% of steps verified70–80%Guidewire: 1,204 runs with 80–90% of steps verifiedInsurity: 875 runs with 80–90% of steps verified80–90%Guidewire: 723 runs with 90–100% of steps verifiedInsurity: 503 runs with 90–100% of steps verified90–100%Share of steps in the run whose expected result was checked and met
Guidewire PolicyCenterInsurity Policy Administration
Synthetic rows, measured rates. Per-run verification coverage, 4,632 Guidewire runs and 3,708 Insurity runs. Median run: 77% (Guidewire) and 76% (Insurity). Overall step-level coverage 75% and 74%. Rates were pooled across the two environments, which is why they match.
Table view
Coverage bandGuidewire runsInsurity runs
0–10%2823
10–20%4432
20–30%4638
30–40%4342
40–50%5273
50–60%351203
60–70%690634
70–80%1,4511,285
80–90%1,204875
90–100%723503
4 · Cost over a test case’s life

The first run is the expensive one. By the third, memory carries most of the steps.

Spec2RunAI bills AI engagements: four when a step is resolved for the first time, one when it replays from selector memory. The view follows 240 synthetic test cases through their first twenty runs, reproducing the measured first-run and steady-state rates.

Measured rates · synthetic rows0.04.08.012.016.0Run 1: 15.815.8run 1Run 2: 3.83.8Run 3: 2.9Run 4: 2.9Run 5: 3.13.1Run 6: 3.1run 6Run 7: 3.0Run 8: 3.1Run 9: 3.1Run 10: 3.13.1Run 11: 3.2run 11Run 12: 3.0Run 13: 2.9Run 14: 3.1Run 15: 3.0Run 16: 3.2run 16Run 17: 3.3Run 18: 3.3Run 19: 3.3Run 20: 3.33.3run 20AI engagements per run, by how many times the test case has run (mean of 240 synthetic test cases)
Synthetic rows, measured rates. Mean AI engagements per run fall from 15.8 on the first run to 2.9 by the third and settle near 3.3. The releases cause the small rise in later runs as changed steps are re-resolved.
Table view
Run no.Mean engagementsMemory replay
115.770%
23.8373%
32.9378%
42.8579%
53.1478%
63.179%
73.0178%
83.0778%
93.1277%
103.0778%
113.1878%
123.0577%
132.9478%
143.1379%
152.9578%
163.2178%
173.2676%
183.3177%
193.377%
203.3377%
Measured rates · synthetic rows0%25%50%75%100%Run 1: 0%0%run 1Run 2: 73%73%Run 3: 78%Run 4: 79%Run 5: 78%78%Run 6: 79%run 6Run 7: 78%Run 8: 78%Run 9: 77%Run 10: 78%78%Run 11: 78%run 11Run 12: 77%Run 13: 78%Run 14: 79%Run 15: 78%Run 16: 78%run 16Run 17: 76%Run 18: 77%Run 19: 77%Run 20: 77%77%run 20Share of steps replayed from selector memory with no model call, by run number
Synthetic rows, measured rates. Share of steps replayed from selector memory: 0% on the first run by definition, 73% on the second, and 77% by run twenty.
5 · Why runs fail

A failure classified by cause goes to the right person.

Every failed run is classified as an application defect, a test defect, a data problem, or an environment problem, with a confidence score. The mix below reproduces the measured one: roughly half of failures are real defects.

Measured rates · synthetic rowsApplication defectApplication defect: 226226 (47%)Test defectTest defect: 126126 (26%)DataData: 6666 (14%)EnvironmentEnvironment: 6262 (13%)
Synthetic rows, measured rates. 480 failed runs by classified cause. Application defects are 47% of failures and test defects 26%.
Method

How the model was built.

What was measured

Aggregate rates from live Spec2RunAI runs against two partner enterprise environments, January to October 2026: step breakage in the 14 days before and after a vendor release; the share of selector breaks recovered by the engine; the status mix of suggested rewrites; the distribution of per-run verification coverage; the share of steps without an expected result; memory-replay rate and AI engagements by run number; failed runs by classified cause; and Assertion Lock interventions per thousand steps. Rates were pooled across the two environments, which is why the two appear alike on this page.

What was generated

A seeded generator produced 240 synthetic test cases, 8,340 runs, 118,539 step rows (115,319 executed, 3,220 skipped), 94,243 selector-memory events, and four representative release dates, with outcomes drawn to match the measured rates. No row corresponds to a customer record. Counts on this page describe the synthetic dataset, not production volume.

Definitions used in every view

Executed step: a step that ran; skipped steps are excluded. Broken step: failed, or passed with drift flagged. Release window: 14 days either side of the date the environment moved to a new vendor release. Verified: expected result checked and met. Memory replay: step executed from stored selector memory with no model call. Engagement: one billed AI resolution unit; four on first resolution of a step, one per replay.

Why the rows are synthetic

The run records sit under customer and partner agreements that do not permit publication, including in anonymized form. Aggregate rates about Spec2RunAI’s own behavior are ours to report; the records behind them are not. Generating rows that reproduce the measured rates lets the distributions be shown without exposing any record.

What will not be published

Customer or carrier names, URLs, configuration details, step text, dataset values, screenshots, actual upgrade dates, or the run records themselves. Where a partner later permits it, a measured edition will replace this page with the same views computed directly from the records.

Common questions

About this page.

Is this real customer data?

No row on this page is a customer record. The rates that shape the charts were measured on live Spec2RunAI runs against partner enterprise environments; customer and partner agreements prevent publishing the records, so the rows were generated to match the measured rates. Rates are measured; counts describe the synthetic dataset.

Why synthetic rows instead of the records?

Because the records belong to the environments they were run on. Aggregate rates about how Spec2RunAI behaves are ours to publish; a run against a partner’s policy administration system is not. Synthetic rows let the distributions be shown without exposing a single record.

Which numbers are measured and which are generated?

Measured: breakage rates before and after a release, the recovery share, the rewrite status mix, verification coverage, the share of steps without an expected result, replay rate, engagements by run number, failure cause mix, and the Assertion Lock rate. Generated: every individual row, and therefore every count (runs, steps, breaks, rewrites). Release dates in the model are representative, not the partners’ actual upgrade dates.

Can I get these numbers for my own application?

Yes. Send us ten of your manual test cases, untouched. We run them against your application and return the Run Evidence Report, which contains verification coverage, failure classification, and the AI provenance appendix for your runs.

Your numbers, not a model

Ten test cases. Untouched. Your application.

We run them as written and send back the Run Evidence Report: verification coverage, failures by cause, and the AI provenance appendix, for your runs.