A city launches a new online form that silently truncates long street names to fit a short database field. What does this scenario primarily illustrate?
Select an answer to reveal the explanation.
Short Explanation
If the form chops off 'Boulevard' without telling anyone, the database quietly invents wrong addresses. System design—not just careless typing—can bake defects in. Silent truncation is a classic system-induced quality failure.
Full Explanation
Application and system design constraints can systematically introduce data quality defects at capture. A city online form that silently truncates long street names to fit a short database field creates correctness and usability failures that users never see, so bad values propagate as if complete. Assuming silent truncation is always harmless because users can retype later ignores that many never notice and that downstream GIS, notices, and routing already consumed the truncated string. Claiming only free-text spelling mistakes create DQ defects, while field length limits never do, falsely narrows cause classes. Treating truncation as proof the data is more unique because shorter strings collide less often misunderstands uniqueness and celebrates information loss. Exam caveat: prevention beats cleansing—adequate field lengths, validation, and visible errors belong in design reviews, not only in warehouse repair jobs. Operational check: compare form max length to database and postal standards, enable user-visible errors on overflow, sample truncated streets against the master address list, and fix the schema before the next release. Municipal permitting and 311 teams should include address-field length in go-live acceptance so truncated streets do not break inspection routing.