Parked Content Looked Like Corruption to the First Diagnostic

Several rows came back flagged as broken, and a bulk cleanup was right there to run. The preview of that cleanup changed what we did next.

The tool’s first version had found rows that did not match the structure it expected. Some of them really were inconsistent. Others were valid content deliberately waiting outside the active structure. A repair would have deleted or moved good records because they were not where the tool expected them to be.

A report is a hypothesis

Many issues arrive with an explanation already attached: “the record is missing,” “the data is corrupt,” “the login is broken,” or “the page failed to save.” Those are useful starting points, but they are not evidence.

The strongest work in this group of issues was a set of small diagnostics rather than a code patch. Each one asked a narrower question: what does the system actually know, and which parts of that state disagree?

That question saved us from two expensive mistakes. A complaint that sounded like missing data was a mismatch between the account model and the person trying to use it. The repair tool’s flagged rows were mostly valid records in a state the tool had not yet learned to recognize.

A user describes the symptom they can see. The system stores facts at several layers: identity, permissions, contact methods, relationships, configuration, content and lifecycle state. Those layers do not always line up with the words in a support request.

So before changing data, build or reuse a read-only view that lets an authorized reviewer see the relevant relationships together. It should answer the smallest useful question without exposing more personal or operational detail than necessary.

For an access problem, that means comparing the person, their permitted identity, the login path and the role that governs access. For a layout or configuration problem, it means comparing the visible structure with the stored references and the state that explains why an item is intentionally unplaced. We did not need everything. We needed enough evidence to tell a defect from an expected exception, a data-model gap or a misunderstanding of the product.

Why the preview mattered

A diagnostic that only returns “bad” and “good” can do its own damage. The preview made the distinction the first version could not: inconsistent records on one side, deliberately parked content on the other.

The workflow we settled on has four stages:

1. Read and classify. Inspect the authoritative state without mutation and explain why each item was flagged.
2. Preview the proposed change. Show what would change, what will remain untouched, and why.
3. Require authorized confirmation. For consequential changes, an accountable person reviews scope, customer impact and recovery before the write occurs.
4. Verify the result. Confirm the intended inconsistency is resolved, valid exceptions remain intact, and audit records support later investigation or reversal.

The preview is a boundary that separates a diagnostic that informs judgment from an automation that can turn a false assumption into a destructive action.

When the data is clean and the model is wrong

A clean data record can still reveal a product assumption that no longer fits reality.

A system may assume that the person who owns an account is the person who uses it, that every item belongs in the active view, or that an empty relationship always indicates an error. Those assumptions hold until a legitimate case falls outside them. Forcing the data back into the old shape is not automatically the right response. It may be better to clarify ownership, support a valid alternate relationship, make the workflow understandable, or limit a feature to the cases it was designed to serve.

That is why we count the diagnostics as durable product work. They find bad rows, and they show where the software’s mental model differs from the people and work it is supposed to support.

Before approving a data repair, get a read-only report of what is wrong, what is valid and what will change. Then require a preview, an accountable approver, and a check of the outcome with a recovery path preserved. A repair that cannot tell a real inconsistency from a valid exception will destroy good records.

dxdev LESSON · paste into your AI agent

LESSON: Apply the Lesson: Before you repair data, build the diagnostic

WHAT TO SHARE:
A short description of the work, the problem you are seeing, the constraints that matter, and any de-identified examples or notes you want reviewed.

ASK YOUR AGENT TO:
1. Restate the problem in plain language and identify the assumption that needs checking.
2. Separate observations from guesses and list the evidence that is still missing.
3. Suggest a small, reversible next step or review plan that fits the situation.
4. Identify the decisions, approvals, and safeguards that should remain with a person.

RETURN:
A concise table with the problem, evidence to check, safe next step, human owner, and questions to resolve.

BOUNDARY: Analyze and recommend only. Do not alter code, records, files, permissions, settings, external systems, or published content. A responsible person must review and approve any action.