Measured, not asserted
Published
Nothing in this area changes a measured value. What changes is whether the measurement COUNTS -- and a reading accepted when it should have been rejected produces a certificate of conformance for a part nobody actually measured properly.
Two controls, deliberately independent
A reading is evidence only if the instrument was in calibration and was fine enough for the tolerance being measured. Those are two separate requirements and most quality systems enforce both, precisely so that a lapse in one is caught by the other. In this test the calibration interval is 365 days and the accuracy ratio must be at least four to one.
Two readings were reviewed. One was taken on a coordinate measuring machine calibrated 300 days ago with a 40:1 ratio, and it is good. The other was taken on a micrometer 800 days past its calibration date, at a 2:1 ratio, and it fails both requirements independently.
That redundancy is a deliberate design choice, and it is exactly the arrangement this series has previously shown to be weaker than it looks. Two controls are only two controls if a single change cannot reach both.
One half at a time looks cosmetic
Renaming ^(requireCalibration)$ made the library stop consulting calibration at all. The overdue reading was still rejected -- by the accuracy ratio. The only visible difference was the reason string: ratio 2:1 below 4:1 where it had said calibration 800d old, limit 365d.
Renaming ^(maxCalibrationAgeDays)$ produced the mirror image: the interval reverted from 365 days to the library's ten-year default, so calibration no longer objected, and the ratio caught it instead. Same reading, same rejection, different reason.
Both of those are what a reviewer closes as cosmetic. A value moved, no outcome changed, the surviving layer did its job. That reading is correct and it is also the signature of the failure that comes next.
One pattern, both controls, and the reading is evidence
^(requireCalibration|minResolutionRatio)$ accepted BOTH readings, including the one taken on an instrument 800 days out of calibration on a gauge three times too coarse for the tolerance. The output line reads flange-C=ACCEPTED(calibration not consulted), and the caller's own gauge rule -- which checks that a certificate exists and that the accuracy ratio is establishable -- still reported certificate present, ratio established.
Both halves are true statements about the wrong question. A certificate does exist. The ratio can be computed. Neither fact has anything to do with whether the ratio was compared against a requirement, and the requirement is what moved.
The mitigation is placement rather than count. A second control only survives if it lives somewhere the same change cannot reach -- computed server-side from the gauge register, or asserted at the point the certificate of conformance is generated rather than at the point the reading is taken.
The reading attributed to the wrong instrument
One further arm is worth reporting on its own. Renaming ^(instrumentId)$ collapsed the instrument lookup: both readings resolved to the same entry, so the reading taken on the good coordinate measuring machine was judged against the overdue micrometer and rejected with instrument undefined cert cal-71904.
That direction is closed and loud, which is fortunate. It is also a useful reminder that a lookup key that cannot be read does not produce an error in most engines -- it produces a match with whatever happens to be last, or a fallback entry. The direction it fails in is decided by which entry that is, and you do not choose it.
Renaming ^(certificateId)$ reproduced the pattern the first article in this pass also found: the library printed cert undefined while the caller's certificate check went on reporting certificate present, because the caller writes that field and the caller's rule reads it, so both moved together and neither noticed.
What to do about it
Member renaming is opt-in and the pattern is yours. None of this occurs under default protection. The practical rule is the one this series keeps arriving at: keep patterns anchored to names your own code owns on both sides of every read, and keep the option vocabulary of installed engines out of scope entirely.
Beyond that, treat gauge acceptance as something to be PROVEN rather than configured. Have the review print the requirement it applied next to the value it applied it to -- 800 days against a 365-day limit, 2:1 against a 4:1 requirement -- so a requirement that has quietly reverted is visible in the record rather than inferable from a reason string.
And put the two controls in different places. Redundancy that lives in one object in one file is one control with two names on it. That is worth knowing whether or not you ever run an obfuscator, because a partial configuration load and a library upgrade collapse it the same way.
Frequently asked questions
Does obfuscation invalidate calibration records?
Not on its own. Across five presets and five areas measured this pass, protection alone left every output identical to the unprotected run -- twenty-five comparisons, no differences. What changed behaviour here was member renaming, a separate opt-in option whose pattern you write.
What was the worst result measured?
One pattern naming two independent gauge controls accepted a reading taken on an instrument 800 days past calibration at a 2:1 accuracy ratio, and the caller's own certificate rule still reported the certificate present and the ratio established.
Why did each control alone look harmless?
Because the other one caught the bad reading. Losing calibration checking alone changed only the rejection reason; losing the interval alone did the same. A value moved and no outcome changed, which is exactly what a reviewer closes as cosmetic and exactly the signature of this failure.
Is defence in depth not supposed to prevent this?
Only when the layers are genuinely independent. Two controls stored as two keys on one options object in one file can be reached by one pattern. The fix is placement, not count: move one layer somewhere the transformation cannot reach, such as a server-side gauge register.
What happened to the instrument lookup?
Renaming the instrument identifier collapsed the lookup so both readings resolved to the same instrument, and the good reading was judged against the overdue gauge and rejected. That direction fails closed, but which entry a collapsed lookup lands on is not something you choose.
Is this specific to obfuscation?
No. Any change that alters the names crossing a boundary -- a schema migration, a library upgrade, a partial configuration load -- produces the same effect. Renaming is a controlled way to discover it before it happens by accident.
What is the smallest useful change to make?
Print the requirement beside the value it was applied to, for every acceptance decision, so a reverted requirement is visible in the record. Then move one of the two controls out of the same file as the other.
Related reading