I audited a new build of our VPS “Help Me Choose” tool against the live production version — comparing the two tag by tag with Claude in Chrome. The verdict was clean. Then it flagged two things my own standard would have me “fix,” and I overrode both.
The parity was total: 25 production tags, all matched exactly in the new build. Same question schema, same nav, same close-modal event, same nine product values. On structure, the two were identical.
But the audit surfaced two issues that technically violate our tagging standard. data-element-type was NULL on every production tag, and the trigger button used data-element-label="body" instead of "cta". By the letter of the SOP, both are wrong.
I overrode both — on purpose.
Why “fixing” them would have broken everything
The analytics dashboards on this page were calibrated to those exact values months ago. Click-tracking events, segment definitions, trended reports — all keyed off the NULL element-type and the "body" label. “Correcting” them to match the SOP would have silently broken every dashboard depending on them. No error. No warning. Just numbers that quietly stop adding up.
The net-new tags I added on the result page are SOP-compliant — because they’re new. There’s no historical data behind them to break. That’s the distinction that matters: compliance is free on greenfield, and expensive on anything your reporting layer already trusts.
An audit tool can tell you what doesn’t match the spec. It can’t tell you what downstream systems are calibrated to. That judgment still belongs to a human who knows the history.
SOP is the floor. Dashboard continuity is the ceiling.
Has anyone else hit this — a “compliance fix” that would have quietly broken your reporting layer?