Function offset_construction_band 

pub fn offset_construction_band(scale: f64) -> f64

The band an approximate offset construction is judged against: 0.05% of the caller’s local characteristic length, floored at OFFSET_CONSTRUCTION_FLOOR.

This is a fit-accuracy band in this module’s taxonomy — “how closely must committed geometry agree?” — and it is the offset family’s own established answer, not a new number. Three sites hand-roll exactly this expression today: the ruled push’s rim march (edit/direct_edit/face_offset.rs:303, whose comment names it “the in-tree precedent for how far an approximate offset result may be off”), the same file’s hole rebuild (:1343), and the free-form push’s dense residual gate (edit/direct_edit/face_offset_freeform.rs:22). Naming it here gives the MEASURED half of the tolerance model (MeasuredTolerance) the same bar the gated half already uses, so a measurement and a gate on the same construction cannot silently disagree. The three copies are deliberately NOT converted yet: two of those files are being rewritten by the general image-curve work — the planned move to a general image_curve(surface, pcurve) transfer for every pcurve, which retires the four iso-curve refusals at once — and a drive-by edit there would collide for no behavioural gain; the expressions are identical, so converting them later is a rename, not a change.

It is deliberately ~50x TIGHTER than KernelTolerances::pcurve_acceptance, which is where the same edge is judged later by crate::BrepSolid::validate. The two answer different questions: pcurve_acceptance asks “is this edge and this surface the same entity?” and must absorb a vendor import’s independent approximations, while this asks “did OUR fit reproduce what we asked it to?” and has no vendor to forgive. A construction that passes here passes validate with two orders of magnitude to spare; one that fails here is a bad fit even though validate would still accept it, which is precisely the case a measured tolerance exists to surface.