Regression Validation
Regression Validation Guard
Last updated: 2026-08-07
Regression Validation Guard re-scores your match rules against your existing labeled truth set every time you change a rule or ship a release, so a tuning fix in one place doesn't silently break precision somewhere else. It's billed monthly and runs on inquiry: someone confirms scope with you before it starts, not a Stripe self-checkout. It assumes you already have a truth set from Match Rule Validation or the License; it doesn't build one from scratch.
Match rules drift. Someone tunes a threshold to fix one false positive and quietly opens false negatives somewhere else, and nobody notices until production. Regression Validation Guard exists for teams that have already been through Match Rule Validation or hold a License and want that drift caught on a schedule, not rediscovered at the next gate review. It's continuity, not a first pass at proving anything.
This page covers what a re-score run produces and how the service is scoped. It does not cover how the original truth set is built, or Match Rule Validation scope, which lives on that offer's own page.
Every time your match rules change, or you ship a release that touches the matching pipeline, we re-run the Post-Tune Re-Validation Pass against your existing labeled truth set and hand back an updated Go-Live Precision Scorecard. You see whether precision, recall, and F1 moved, and in which direction, before the change reaches production rather than after a downstream complaint traces back to it.
Drift is easiest to see as two scores on the same truth set. These inputs are illustrative assumptions, not a measured result from any engagement; substitute your own counts.
Say your truth set holds 200 known duplicate pairs. Before a tuning change, your rules return 150 true positives, 30 false positives, and 50 false negatives: precision is 150 / (150 + 30) = 83%, recall is 150 / (150 + 50) = 75%.
Someone then loosens a threshold to catch more duplicates. After the change, the same truth set returns 160 true positives, 60 false positives, and 40 false negatives: precision is 160 / (160 + 60) = 73%, recall is 160 / (160 + 40) = 80%.
Recall went up five points and precision went down ten. Without a re-score against the same truth set, that trade is invisible, and the only signal is a merge complaint after go-live.
Regression Validation Guard follows Match Rule Validation or the Self-Serve Ground Truth License; it doesn't come before them, because it re-scores against a truth set that already exists rather than building one. Triggers are a release cadence, a rule-tuning cycle, or a steering committee that wants continuous proof instead of a gate-review number that's now months old and untested against the current rule set.
There's no self-checkout for this one. You ask about Regression Validation Guard, we confirm which rules and which release cadence it covers, and it runs billed monthly at Pricing unavailable for as long as you keep it active. Pause or cancel it once a delivery phase ends, and start it again on the next one; the cadence is set to match your release schedule, not ours.
Full terms are set out in our Refund Policy.
Frequently asked questions
What triggers a Regression Validation Guard re-score?
Any change that could move match quality, a rule tuning pass, a threshold adjustment, or a release that touches the matching pipeline. Each trigger runs your existing labeled truth set back through the rules and returns an updated Go-Live Precision Scorecard, so you see whether precision, recall, or F1 moved before the change reaches production, not after.
Do we need Match Rule Validation first before Regression Validation Guard?
You need an existing labeled truth set, which comes from either Match Rule Validation or the Self-Serve Ground Truth License. Regression Validation Guard re-scores against a truth set that already exists; it doesn't generate one from scratch. It is the continuity offer, so it starts after one of those two rather than before either of them.
Is Regression Validation Guard self-serve or does someone run it for us?
It's inquiry-based, not self-checkout. You reach out, we confirm which match rules and which release cadence it covers, and it runs on the agreed schedule after that. That conversation exists because scope varies by how often your rules change and how many domains you're tracking.
How is this different from the Self-Serve Ground Truth License?
The License gives you the Match Rule Truth Engine to generate truth sets and run your own checks whenever you want. Regression Validation Guard is an active re-scoring service on a set cadence, we re-run your rules against your existing truth set on every change or release and hand back the scorecard, rather than leaving the running to you.