A validation method controls risk as AI analysts change
Lifetime-valid decisions by continually evolving AI analysts · arXiv:2610.30562
In plain words
An AI analyst can change its instructions, tools, or decision rules over time. Even if its parts seem reliable, the changing analyst might start making too many false discoveries or product launches.
Continual validation checks each proposed version on newly simulated cases where there should be no discovery. In a product-launch example, none of the 20 runs using this check deployed a version whose estimated false-launch rate exceeded the target of 0.05. The result applies to the tested scenarios, not every possible case.
The research
If an AI analyst changes after learning from earlier analyses, how can researchers tell whether its decisions still keep false discoveries or false launches within an acceptable rate?
Checking a fixed test once may not answer that question, because later versions can make different decisions and updates can be selected using past feedback.
Continual validation checks frozen analyst updates on new simulated null cases and limits the lifetime risk of approving versions with excessive false rejections.
The authors introduce continual validation, which freezes each proposed analyst version and checks it against a fixed reference analysis on new simulated data under the null hypothesis.
It approves an update only when an upper confidence bound on its false-rejection rate meets the validation threshold in every checked scenario.
In product-launch trials, continual validation kept every deployed version below the 0.05 target across 20 runs, while methods without an error check often exceeded it. This supports the method’s value in the tested setting; a theorem bounds the lifetime risk over checked scenarios.
The formal lifetime guarantee covers only null scenarios tested for each version, and relies on valid reference bounds and updates being frozen before new validation data are drawn. The off-grid results are finite empirical evidence, not a guarantee for every untested data pattern.
What the evidence shows
- The analyst can keep changing
An AI analyst can plan and run analyses that end in decisions such as declaring a discovery or launching a product feature. A false rejection happens when it rejects a true null hypothesis, such as concluding that a feature works when it does not.
Because an analyst can be randomized and updated using earlier feedback, error control for one fixed test does not automatically carry over to the evolving analyst.
- The whole decision matters
Checking each test separately may miss the risk of combining them into one decision. In a bioequivalence example, two tests each controlled the false-rejection rate near 0.05, but applying the second when the first failed raised the combined rate to 0.0587. The example shows why the whole decision process needs validation.
- Check updates before use
Continual validation freezes each proposed analyst version before checking it. The validator runs that version and a fixed reference analysis on the same newly simulated datasets under each null scenario, then approves the update only if an upper confidence bound on its false-rejection rate is below the validation level in every scenario.
- Bound risk over updates
The method assigns part of a lifetime risk budget to each update attempt. Its theorem bounds the chance that validation ever passes an update whose Type I error rate is too high in a scenario checked for that update, even when updates are chosen adaptively.
It also allows sufficiently low-error updates to pass with high probability under stated conditions.
- Compare deployment methods
In the product-launch example, continual validation had no run with a deployed version above the 0.05 target, among 20 runs of 10 rounds each. Without validation, 12 runs exceeded the target; an improvement test that checked for increased power but not Type I error exceeded it in 19 runs. These are results for the tested analyst and scenarios.
- Check beyond the grid
The product analyst also stayed at or below an estimated false-launch rate of 0.044 on 116 null scenarios outside the validation set. That finite check supports performance beyond the grid in this example, while the mathematical guarantee itself remains limited to scenarios covered by validation.
Deep
- Original paper authors
- Xiaojing Sun, Yuhan Zeng, Xiao Wang
- Submitted to arXiv
- License
- arXiv non-exclusive