When a verified fix lands, what closed-loop remediation practice should the issue workflow enforce?
Select an answer to reveal the explanation.
Short Explanation
Closing the loop means the real record and the ticket both move when the fix is verified. Update the system of record and close the DQ issue together. Fixes that live only in trackers or spreadsheets never finish the job.
Full Explanation
Closed-loop remediation updates the system of record and closes the DQ issue together after verification—so civic truth and ticket state stay aligned. When a verified fix lands, the workflow should write the correction to the authoritative municipal system and then close the issue, not leave one side stale for staff and residents. Closing the ticket without updating the system of record creates false completion while clerks and public portals still display bad data. Updating the system of record but leaving the DQ issue open forever for audit theater pollutes queues and hides true workload from managers. Storing the fix only in a personal spreadsheet so production stays unchanged recreates the shadow-fix anti-pattern that undermines city systems of record. Exam caveat: some fixes need staged verification in a lower environment first; still define the production write-back and issue-closure gate explicitly in the playbook. Operational check: require a linked change or update identifier on issue closure, sample closed tickets for missing system-of-record updates monthly, and report broken-loop rates to the DQ forum. Municipal stewards should be measured on verified system-of-record corrections, not on ticket-closure velocity alone, when reporting program health to the CIO.