Emulator Error Control
A surrogate is only useful if its own error is bounded and propagated; emulator error control keeps the approximation honest.
The surrogate has error too
Replacing an expensive model with an emulator introduces a new error source: the emulator approximates the model imperfectly. If this error is ignored, downstream statistics inherit a hidden bias and appear more certain than they are. Emulator error control means estimating, bounding, and propagating the surrogate's error alongside the physical uncertainties.
Estimating emulator error
- Cross-validation (see Leave-One-Out CV) for held-out error estimates
- Native predictive variance from a Gaussian process or Bayesian model
- Held-out test sets from independent runs
- Residual analysis against the true model at check points
Propagating it
For a Gaussian-process emulator the predictive variance is available at every point and can be added to the uncertainty budget or sampled over. For deterministic surrogates without native variance, an error model must be fitted separately. The goal is that a reported output interval includes both physical variability and emulator ignorance.
Controlling it
Emulator error is reduced by adding training points where the surrogate is least certain, an active-learning loop that concentrates effort where it improves predictions most. Refinement continues until the emulator error is small relative to the physical uncertainty of interest, at which point further refinement is wasted effort.
Verification against truth
No error estimate substitutes for occasionally checking the emulator against the true model, especially near decision boundaries and at extrapolation edges. A surrogate that reports low variance in a region it has never seen is dangerous. Kronos design practice reserves full high-fidelity runs to verify surrogate predictions near the frozen operating point rather than trusting the emulator alone.