Sorry for the delay getting this review completed. I've now finished looking through the code and have verified that I can run this and get sensible outputs (using DECam only, but I trust the same would work for CFHT). I have not done a detailed comparison of the algorithms used vs those we used for reporting S15 KPMs, but I believe they look plausible. I suggest David Nidever [X] checks to make sure he's happy with them.
The main question you asked was:
Do the plots and stdout put as shown in this ticket match what you'd like to see?
And the answer there is basically yes. The output looks fine for an interested end user who wants to poke at some data, and maybe that's what you're aiming for at the moment. Ultimately, though, I guess this isn't how you want to present the outputs at all – presumably it all gets fed into a database backed, web-based QA system. For now, though, I have no objection to what's here.
One question I would raise is why the validation routine isn't written as a command-line task. I fear the answer might be that they're just too complex to get to grips with, which I think is a fair criticism of the technology but perhaps not ultimately a good reason. Using the existing task framework would buy you command line parsing (including integration with the repository, etc, rather than hard-coding data IDs in defaultData functions), logging, standardized interfaces and so on. I think it should be a real concern to the project if they're dismissed for work outside Science Pipelines.
The code has been much improved by the changes you made since my previous partial review. I've made a number of additional comments on the code on GitHub and would appreciate it if you take a look at them. Very few of them are substantive changes though. (One minor nit I didn't mention but which occurs quite frequently is trailing whitespace. Not a big deal, but drives me nuts!)
I absolutely agree with your comment about the lack of tests: this is probably the single biggest reason why we wouldn't consider merging something like this into Science Pipelines. In general, in pipeline-land we wouldn't mergie to master until we feel a particular feature is "done": it's not just functional, but it's documented, the code is reasonably polished, the test suite is running, and so on. That's what makes me a little leery about giving this a green light. However, I do understand that you're operating in a different regime where the priority is to prototype rather than to roll out production quality code. As long as we're clear that this is just a prototype rather than a finished article, I'll leave it up to you Frossie Economou as to whether this is something SQuaRE wants to support.
With that caveat, and assuming you take another look at the PR (and, in particular, my comment on magNormDiff), this is good to go.