Storing the most extreme dimensions found on preview

So, I've got this great idea on checking bit Z-height before running: forum.linuxcnc.org/38-general-linuxcnc-q...hecking-on-top-datum

This hinges on there being a highly reliable way to calc the lowest Z the G-code will go to- one that there's no way around like loading a file in an unusual way, or any method that changes the user offsets that either evaded  recalculation or recalculates wrong.

It seems the best way to do this would be to modify AXIS so whenever it analyzes a g-code file, it saves the lowest Z found in a special .nc file.  Once the rangefinder sees that someone has changed or might have changed the bit, it requires this check of a physical tool touch-off on a fixed sensor.

My current thought is that it won't try to second guess you and set your Z offset to what it thinks you want.  You'd still be in control of that.  Regardless of whether you zeroed the machine on the bed or top of the wood (which you'd want to do for V-carving), it's just going to check how deep the loaded job would go and if it's going to cut more than 0.5mm into the spoilboard, it will not allow running until it's addressed and clears a repeat of the bit check and/or loading a file that doesn't go as deep.

To do this, I figure when AXIS triggers a reevaluation on the Preview (file loading, or the user changes the user offsets, it rewrites that .nc file.  The nc file isn't anything the user interacts with directly.  The system's bit check routine just calls this external ,nc and AXIS would update that every time you load a file so it should be reliable, right? 

Hmm, what's my question?
1.  Am I correct in thinking that the evaluation it does while loading a file is definitive, except perhaps for manually written G-code subroutines/conditionals it can't display in the 3D workbox area? 
2.  And it's definitive in that there's no way it could get out of sync?  That is, there's nothing else that can change the toolpath that doesn't come through that load-and-evaluate code in AXIS?  I see the "Edit G-code" function has to do another load-and-evaluate to change the toolpath, so there's no fooling it that way. 
3.  I know it's Python and thus the source is right there, but if anyone wants to point me to the "right spot", that could be a huge timesaver.