Bit length checking on top datum

I work with a larger community makerspace and people missetting the z and gouging the spoilboard is the bane of our existence,

I would like to implement this:
1.  there's a wireless toolsetter you use as normal to set your top datum jobs.  This is the "User Offset" (UO).  I only mention this to make it clear that the tool offset test is a different thing.
2. a ToF rangefinger on the head.  NOT to try to distance the work, bed, or bit.  Rather, it's mounted above the spindle and if it is not running and senses hands in the area needed to undo the collet nut, it assumes the bit has been changed strobes a "safety touch off required" (STOR) signal that linuxcnc latches.  STOR is basically "tool offset is now unknown, don't run until the tool offset is checked"
3. The safety touch-off is a second toolsetter located in a fixed place on the machine, with a known fixed Z-height above the bed.  The STO cycle finds the z height of the bit tip and scans the loaded file for the lowest Z-coord, applies the current UO, and if it goes below the bed in machine coords, sets Z Safety Lock Out (ZSLO) which locks out the Run mode.  STO test never reorients the job, it only locks out run mode until the user corrects it
4.  Loading a new file, rerunning the wireless toolsetter for a new UO, manually entering a new UO, or running a new STO cycle triggers a reevaluation which could reset the ZSLO.  
5.  STOR is only set upon power-up or the ToF rangefinder detects that the bit  may have been changed.  False triggering the rangefinder and setting STOR is acceptable as it is just a small nuisance, but it should be impossible to interact the with collet nut without triggering STOR.  The corrective measures in #4 do not set STOR since the tool offset is already known.  It is not tested every time you press RUN.  
6.  STO can be initiated manually, or, pressing "RUN" will always trigger an  STO before running, which will either continue on into the RUN mode, or trigger ZSLO and enter the STOP state.

I know this will not protect against bit slippage.  I have wondered about how to do that for awhile, but can't see a solution other than conductive spoilboard.  Conductive spoilboard could actually work, it could still allow shallow excursions into it.  When the spoilboard is grounded by bit contact, the distance from the current Z and the lowest Z in the loaded file cannot be >2mm or we retract Z and stop.

Only problems there are you can't use conductive stock (bypass mode possible), but the main issue would be a cost-effective way to make spoilboard conductive enough.  Then again, if the spoilboard isn't getting consumed regularly, a high-effort way to make it conductive could still be practical.
 

I'm not worried about detecting a manual bit change. ToF sensor on ModBus sounds good.

Does the HAL have access to the lowest Z in the loaded file? I know AXIS parses what you load and displays it in the workbox. That will tell you if the loaded job with the current offsets will go outside the boundaries (such as lower Z limit)

But AXIS and LinuxCNC are not the same thing. Isn't that parsing something AXIS does? Does the HAL get that info?

The real benefit would be in protecting against the bit slipping.  Again, this is a makerspace- you and I know how to tighten a bit and inspect collets for damage like prior interior galling that would make it slip.  But in a makerspace, you don't have that much control and threatening users with consequences tends to intimidate them into not wanting to use the equipment at all more than actually reducing spoilboard gouging. 

So far the only viable thing I could picture would be making the spoilboard conductive, putting a 10k pullup on it, and watch to see if the bit contacts and grounds it (you still get conductivity through the spindle bearings in my experience).  But a) it's a vacuum bed, so gluing on tinfoil would defeat the vacuum function.  Conductive paint or even glue can seal off the vac too.  And b) it's a large bed, it might take a whole gallon or more of conductive paint even if we find a type that won't impede the vac flow.  Hmmm.... not only will salt water swell the MDF grain apart, once it dries, a pile of dry salt isn't conductive so that path is not going to work.

I thought of metal window screen mesh, like to keep out bugs.  Still kind of expensive, and gluing may seal the vac.  Also it's allowable- actually necessary- to cut into the spoilboard by a very small amount.  You'd either glue a 1mm layer of shaved MDF on top of the detection mesh- which gets pretty tough to handle spoil board replacement-  or code it so it only checks for a problem when it starts and stops making contact by calculating how much deeper the file would travel into the Z if allowed to continue.  But that would not detect bit slippage until it Z lifts into a new cut, because we said it's allowed to contact and ground the spoilboard surface during a cut, not knowing how deep it actually is.

Can't keep touching off between cuts.  Well, you could, but it would be an extremely annoying waste of time and, again, would still fail to see bit slippage until gouging has already happened.

It's not essential to have a solid detection layer.  If there were a grid of conductive traces spaced 3" apart, 1mm below the surface, that would still  work, generally.  Not effective at accidentally drilling holes too far, but the touch-off usually detects that prob.  Deep drill marks are not that bad for leaking vac in later use, and you can fill them with a putty of MDF dust and wood glue too

So, is there a way to get the lowest Z the loaded file will go to?

I don't see anything like that in numbered params. AXIS shows it did a full sim of all the g-code upon loading, but AXIS is not G-code. Could AXIS evaluation be storedand made available to g-code somehow?