Establish Continuous Checks and Quarterly Audits

GTM Lab's nightly duplicate scan fails halfway through, after completing the Lead detection pass but before the Contact pass finishes. The dashboard keeps showing last night's result as “current,” because nothing distinguished a partial run from a complete one. Nobody notices the run failed. The Contact-level duplicates that accumulated that day go undetected for a week.

Two different questions, two different cadences

A continuous check catches a known problem recurring: a nightly scan catching new duplicates, a validation rule catching a bad phone format the moment it's entered. A string of passing continuous checks doesn't prove the program is healthy; it proves the specific things being checked haven't recurred. A quarterly audit asks whether the operating system itself still works: has a rule drifted, has a trigger silently stopped firing, has a new record type started accumulating the exact problem the continuous check was built to catch.

Split the cadence, and give a scan four states, not two

List at least two continuous checks and what each catches, and at least one quarterly audit and what it catches that continuous checks can't. Adopt a four-state scan model of running, last successful, stale, and partial failure, plus the rule that matters most: a failed or partial run must never silently overwrite the last successful snapshot. The failed-partial-scan fixture confirms the partial run is labeled partial failure, the previous last-successful snapshot stays current, and the run routes to its owner.

Carry this into your business

A scan that can only say pass or fail will eventually lie to you by omission. Give it a partial-failure state, and never let a broken run quietly become the new truth.