I'm all for shrinking the existing threshold for declaring failures.

I'm less certain that adding a mag cut right now is a good idea - it seems safe, but we have a feature freeze precisely because lots of things that seem safe aren't.

I'm also not certain we need DM-32128 now, unless there examples where the existing logic (with the new threshold) would not have caught a catastrophic failure but the one proposed there would have; I get that it'd be nice to use the same definitions in various places, but again, I want to aim for minimal possible changes for DP0.2 at this point. I am quite skeptical that giving the fitter additional iterations will ever allow it to recover; it's a greedy optimizer, so once it starts down into a bad local minimum, it's very hard for it to get out.

Thanks, Jim.  I agree that the mag cut on the reference catalog may be a tad risky at this point as it should really undergo reasonably substantial testing to calibrate what band/threshold should be set.
 
As for DM-32129 (I think that’s what you meant to refer to above), I have no problem with abandoning it if that’s what you think is best, but with a bit of a caveat. While I would feel very comfortable with the proposal there, based largely on the fact that I have a significant sample of actual data — simulations and real — providing general (“math”-confirmed!) justification as well as explicit guidelines for the selected threshold and what its effect will be per dataset, I have no such comfort level for the existing intra-fitter threshold config (that doesn’t actually exist in all of our fitters, e.g. fitAffineWcs). While I am almost certain all you say above is absolutely true, the “almost” qualifier is a sticking point for someone as paranoid as myself...I would need to actually see the numbers that come out and their distributions (and possible changes with iteration) to feel confident on the consequences of setting a number (especially for edgy-cases, which is sort of what brought this on). Since that stat is never persisted anywhere, obtaining the above dataset would require a fair amount of special purposed processing, and I just don’t have the cycles for that at the moment (i.e. on the timescales of DP0.2).

To summarize, I’m a-ok with whatever path you feel is best, but if it’s not DM-32129, then I’ll leave it to you/others to find a more suitable (prolly just less paranoid!) candidate to set the numbers press the buttons!

Yes, DM-32129 is what I meant, and the piece that was missing in my mind was the fact that you know what the threshold should be in that new logic but don't know what it should be with the existing logic. Please proceed with that ticket; no more objection from me.

Ok, great!  Thanks again.

I think this is cleared up now, but an additional relevant point is that maxScatterArcsec is an internal configuration of the particular wcs fitter we are using (fitTanSipWcs), while the change we're talking about here is a general and reproducible check on the final output of whatever astrometry matcher and fitter we are configured to use.
Lauren noted this above ("the existing intra-fitter threshold config (that doesn’t actually exist in all of our fitters, e.g. fitAffineWcs)"), but I wanted to pull this out as what I see as the primary reason why this check is necessary.