HR insists a null middle name is a defect; permitting staff say it is fine. How should the DQ team settle whether the null is defective?
Select an answer to reveal the explanation.
Short Explanation
A blank middle name is only 'wrong' if someone defined that it must be there for a use. Defects live relative to expectations, not relative to whoever yelled loudest. Write the expectation for the element, then judge the null.
Full Explanation
Whether a null is a defect depends on defined expectations for that element's documented uses—not on a universal null dogma applied blindly across city systems. When HR insists a null middle name is a defect while permitting staff say it is fine, the DQ team should tie the decision to each use's requirements in the municipal data dictionary and glossary. Always treating every null as a defect regardless of use over-penalizes optional attributes and creates false emergencies that burn steward credibility. Always treating nulls as acceptable because databases allow them ignores required-for-use fields in payroll, licensing, or benefit determination. Resolving by whichever department filed the ticket first replaces stewardship with ticket racing and yields unstable rules. Exam caveat: the same physical column can be required for one process and optional for another; document use-specific rules clearly or split presentations carefully for each civic consumer. Operational check: list consuming processes for middle name, mark required versus optional per use, update scorecards accordingly, and communicate the shared rule to HR and permitting supervisors. Civic data stewards should record the decision in the glossary with effective date so future tickets do not reopen a settled fitness-for-use judgment without new evidence.