A quick-win data catalog launches, but users who spot bad values have no path into the data-quality issue process. What integration is missing?
Select an answer to reveal the explanation.
Short Explanation
A beautiful catalog with no “report a problem” button is a museum map of broken exhibits. Hook discoveries into a real DQ issue path so someone owns the fix.
Full Explanation
A quick-win data catalog that lets users spot bad values but offers no path into the data-quality issue process is missing operational integration: catalog findings must connect to a governed DQ workflow with owners and status. Otherwise civic staff see problems they cannot formally raise, and quality work stays anecdotal. Keeping catalogs as read-only showcases with no operational links fails by treating discovery as an end state rather than an intake to remediation. Emailing quality issues privately and never tying them to catalog assets fails by losing asset context, metrics, and auditability. Replacing the catalog with spreadsheets so issue tracking stays informal fails by abandoning both discoverability and governed workflow. Exam caveat: catalogs enable findability; DQ workflows enable fixability—both are required for operating models. Operational check: add “report issue” linkage from catalog entries to the DQ ticket system, require owner and status fields, and measure closure time for catalog-originated defects. Brief stewards that municipal users should never be left knowing a field is wrong with nowhere official to send that knowledge. Keep verification evidence with the municipal runbook so audits can prove the chosen control was applied as designed and that rejected alternatives would have left city services exposed to the failure modes described above.