ZynoviqAI changes. Your quality bar shouldn't.
Every model upgrade, prompt rewrite or knowledge update can fix one thing and quietly break another. Zynoviq re-runs the same professional benchmark after each change, so degradation becomes visible before it becomes a production problem.
Did your AI improve — or silently get worse?
Most AI teams can tell you whether a new release is faster or cheaper. Far fewer can tell you whether it still gets the professional answer right. A model that improves on general benchmarks can still lose an exception it used to handle, and nobody notices until a user does.
Regression testing answers that question with evidence. The cases stay fixed; only your system changes. Any difference in the result is caused by the change you made.
What should trigger a re-test
- Model changes — a new foundation model, version or provider
- Prompt changes — system prompts, instructions and templates
- Retrieval (RAG) changes — new chunking, embeddings or ranking
- Knowledge changes — documents added, removed or updated
- Tool and integration changes — new APIs, connectors or data sources
- Agent and workflow changes — new steps, permissions or autonomy
- Business-rule changes — your policy, approval limits or configuration
- Changes in the law — a new notification, circular or ruling that changes the correct answer
The last trigger is easy to miss: your AI did not change, but the right answer did. Our refresh process updates the benchmark when the rules change, so you learn which answers your AI now gets wrong.
Regulatory Regression Service. Indian indirect tax changes several times a year. We watch the changes, revise the affected cases through the full quality chain, re-run them on your system in your test environment and send you an impact note: not that the law changed, but what it did to your AI. Priced per system per year, quoted. The Regulatory Regression Service.
When we re-run the suite for you:
- for every release you notify us of, on request
- quarterly, on a fixed schedule
- whenever the law changes in a way that affects your cases
Every run is tied to its versions
A score only means something if you know exactly what produced it. Each run records the versions involved, so two runs can be compared fairly and any change can be traced to its cause.
| Version tracked | What it identifies |
|---|---|
| AI version | The model, provider and release of the system under test |
| Prompt version | System prompts, instructions and templates in use for the run |
| Dataset and knowledge version | The documents, retrieval index or knowledge base the AI drew on |
| Test-suite version | Which version of the benchmark was used, with each case's "valid as of" date |
What a regression looks like
Illustrative A simple example of how a regression is detected. The figures are invented to show the method, not taken from any customer.
- 01Version 1Current production release.
- 02Professional benchmarkFixed set of certified cases.
- 0382% correctIllustrative baseline.
- 04Change the modelEverything else held constant.
- 05Same benchmarkSame cases, same scoring.
- 0676% correctIllustrative result.
- 07Regression detectedCases that flipped from right to wrong are listed.
The headline number matters less than what sits behind it. The report lists every case that changed from correct to incorrect — and from incorrect to correct — with the capability affected and the expert rationale, so your team knows exactly what to fix.
Comparing two runs
Illustrative Each re-test report compares the new run with the previous one. The figures below are invented to show the format, not taken from any customer.
| Measure | Run 1 (previous release) | Run 2 (new model) | Change |
|---|---|---|---|
| Overall score | Illustrative 82% | Illustrative 76% | Illustrative −6 points |
| Critical-task accuracy | Illustrative 95% | Illustrative 89% | Illustrative Below the gate you set |
| New failures | — | Illustrative 14 cases | Right in run 1, wrong in run 2 — each listed |
| Recovered failures | — | Illustrative 5 cases | Wrong in run 1, right in run 2 |
| Critical failures | Illustrative 2 | Illustrative 5 | Each with severity and the rule behind it |
| Trend | Illustrative Rising | Illustrative Falling | Direction across the last several runs |
New failures tell you what the change broke. Recovered failures tell you what it fixed. Critical failures tell you whether the change is safe to ship. The trend tells you whether quality is moving in the right direction across releases.
A release gate you define
You decide the bar a release must clear — for example, "do not release if critical-task accuracy falls below X". The threshold is yours: it depends on your workflow, your risk and your users, and Zynoviq does not set it. We report pass or fail against your gate on every run, with the cases that caused a fail.
The gate is a decision aid for your team. It is not a certification or assurance that a release is fit for use.
How results are delivered
Results come as written reports and structured data files — scores, case-level results and run comparisons — that you can load into your own tools or release pipeline. We do not offer a self-service dashboard or portal today.
Ways to buy regression
- Annual subscription — scheduled re-tests and law-change refreshes for one AI system through the year
- Per run — pay for each release re-test when you need it
- Enterprise programme — several teams and AI systems under one agreement
- Managed AI quality programme — we operate the evaluation programme for you: software, professionals and a recurring service
Each is quoted per mission. See packages and how to start for all packages, from the free sample test upwards.
Every failure becomes a permanent test
When an evaluation or red-team exercise finds a failure, the case is not thrown away. It is added to your regression suite with its certified answer, so the same mistake cannot return unnoticed. Over time the suite becomes a record of everything your AI has ever got wrong — and evidence that it no longer does.
For GST, our continuous evaluation service re-tests on a schedule and after rule changes, and shows what improved, what broke and what is newly wrong.
AI regression — FAQ
How often should we re-test?+
After any change that could affect answers — a new model, a prompt rewrite, a retrieval change — and whenever the governing rules change. Many teams also re-test quarterly. Continuous evaluation.
Do we get a dashboard?+
Not today. Results are delivered as written reports and structured data files you can load into your own tools or pipeline. We do not offer a self-service portal.
Can we run the regression suite ourselves?+
Yes. Regression cases are delivered in structured formats you can run in your own pipeline on every release. We can also run them for you and review the results.
What happens to the benchmark when the law changes?+
Affected cases are re-reviewed by professionals, re-versioned with a new "valid as of" date, and the old version is kept so results stay comparable. Evidence and currency. The Regulatory Regression Service re-runs the affected cases on your system.
Is a score drop always a regression?+
Not always. Some changes trade one capability for another. That is why we report results by capability and by case, so you can see exactly what improved and what broke.