Checks pass,
so is it right?
Three kinds of looking
Every change can be checked three ways. The reads the files and tests them against written rules, in seconds, every time. You open the report in Desktop and use it, the way always worked. And someone who knows the business asks whether the numbers make sense, in a .
None of the three catches everything. They catch different things, which is why you need all of them.
Who catches what
Predict first: every validator check passes, all seven hundred of them. Is the report correct?
Check: a measure sums the wrong column. The number looks plausible and every file is valid. Who catches it?
Every find becomes a check
When a person finds a problem the validator missed, fix it, then write the rule that would have caught it. In the sample project, clicking a tile hid its information button. The fix grouped each tile with its button. The new rule checks that every button sits in a group with exactly one tile.
That rule now runs on every build, so the problem can't quietly come back. A problem that returns after it was fixed is a , and catching regressions is the job validators do best.
Check: you found the hidden button by clicking. What's the most useful next step?
The rule, in one breath
A pass means "nothing I wrote down is broken". Look for what isn't written down yet, then write it down.
The validator grows from your finds. The more you look, the less you have to look next time.
Next: the audit trail you already wanted.