A parks department dashboard looks correct until staff learn that 'open work orders' intentionally excludes closed-but-unverified jobs by documented business rule. How should an information manager classify this situation?
Select an answer to reveal the explanation.
Short Explanation
Sometimes the filter is a recipe, not a bug—the kitchen meant to leave those items out. Documented business rules are expectations, not accidental defects. Call it a rule mismatch only if the rule itself is wrong for the decision, not if the data followed the rule.
Full Explanation
Data quality assessment must separate documented business rules from unintended defects. If a parks department dashboard's 'open work orders' metric intentionally excludes closed-but-unverified jobs by a documented rule, the information manager should classify the behavior as an intentional business rule—not automatically as a completeness defect. Forcing every historical job to count as open 'to fix completeness' would violate the documented rule and mislead maintenance planning. Claiming documented rules never affect metric interpretation ignores how civic dashboards encode policy choices. Treating the situation as a uniqueness failure requiring deletion of all verified closures destroys legitimate history. Exam caveat: consumer misunderstanding of a correct rule is a communication and metadata problem; still verify the rule remains appropriate for today's operations. Operational check: publish the metric definition beside the dashboard, confirm the exclusion rule with the parks steward, sample excluded jobs, and decide whether to add a second metric for unverified closures rather than silently changing the original. Municipal operations centers should train supervisors on the documented definition so shift handoffs do not treat rule-compliant counts as system bugs.