By 6pm on a Saturday we had five tickets stacked in the production app: layout-grid weirdness, duplicate standings headers, a broken photo link, a customer who swore the member search was lying about a person’s email, and a name appearing twice in one group. The instinct was to start at the top and patch down the list.

That was wrong.

The first ticket was a customer reporting that a page on their site was rendering blank slots where modules should be. We could have grepped the layout save code, found a recent change, guessed at a regression, shipped a patch, and moved on. In a legacy application that path can give you a plausible patch without ever establishing whether the rendered symptom came from the code. The same complaint then comes back, because nobody looked at the underlying state.

We stopped fixing the ticket and built a diagnostic

We built a layout structure diagnostic instead. A small admin page. It walks a page’s saved layout structure and reports what is in the database: orphaned modules with no parent, broken parent references pointing at deleted containers, and parent/content drift where the layout tree disagrees with itself about who owns what.

After a focused implementation pass, we ran the access-controlled diagnostic against the affected page.

The page was dirty. Three modules had parent IDs pointing at containers that no longer existed. Two more had content rows whose parent references had drifted during an earlier save. The diagnostic was barely more than this:

-- Layout structure diagnostic: what is ACTUALLY in the DB for one page
SELECT m.module_id, m.parent_id, m.module_type,
       CASE
         WHEN m.parent_id IS NOT NULL AND p.module_id IS NULL
           THEN 'ORPHAN: parent missing'
         WHEN m.parent_id = m.module_id
           THEN 'DRIFT: self-referencing parent'
         ELSE 'ok'
       END AS health
FROM   page_modules m
LEFT JOIN page_modules p ON p.module_id = m.parent_id
WHERE  m.page_id = @pageId
ORDER BY health DESC, m.parent_id;


-- Run this only through an authorized diagnostic path. Flags are evidence
-- for investigation, not an automatic conclusion or delete instruction.
-- A clean result narrows the next hypothesis; it does not prove the code is correct.

That evidence did not support a rendering-code fix as the first move. The input state needed investigation, and no existing UI surface made the integrity issue visible.

So the work changed from “patch the renderer” to “identify the source of the inconsistent records, preserve the evidence, and plan a reversible repair with an audit of the write flow.” It was a different problem, with a smaller and more controlled remediation surface.

The second ticket was a customer insisting the member search could not find a person by email. We could have started by re-reading the search SQL, dumping query plans, and second-guessing the LIKE pattern.

Instead we used a purpose-built, access-controlled person-lookup view. Given an authorized support case, it showed the minimum identity and membership evidence needed to investigate a matching problem. It logged access, and it was never a general-purpose personal-data search surface.

We ran it on the customer’s email. The email was there. Three Person records owned it, two of them merged into the third six months ago, and the search was hitting a fourth Person record that had the same name but a different stored email. The customer’s complaint translated cleanly: the search found someone else with the same name, not the customer. That was not a missing-data bug. It was an identity-mismatch bug, and it only became visible once we could see the records.

The evidence narrowed the next change. We avoided a search-code rewrite until we had confirmed what the records represented.

The rest of the night went faster

Once those two diagnostic tools existed, the remaining tickets stopped being mysteries. The second layout ticket turned out to be the same corruption class as the first, on a different page, caught by the same diagnostic. The third was a clean render bug, isolated in fifteen minutes because the diagnostic had told us up front that the data was fine. The fifth was data again.

Across the remaining tickets, the diagnostics separated the repeated data-state patterns from the one issue that needed a rendering-code change. That cut the speculative work and made each remaining repair easier to justify.

Why this keeps working in old code

Old code has accumulated state that you cannot see from the UI. Bad rows from migrations three platforms ago. Identity merges that left dangling references. Layout structures that were valid under older rules and not under today’s. The application keeps running because the rendering code is defensive, and the bug reports keep coming because the data has been wrong for years.

Source inspection alone may never reveal that. The next step is an evidence path that makes the relevant state observable without expanding access unnecessarily.

Not every legacy ticket warrants a new tool. But when a complaint class repeats and its critical state is invisible, a small, access-controlled diagnostic can be a better investment than another round of speculative patches. It should show records and never change them.

The next time a similar layout-integrity report arrives, the first step is to read the diagnostic evidence, protect the affected data, and choose the repair only after the cause is clear.