data-integrity-investigation

name

data-integrity-investigation

description

Investigate data-integrity / "why does this data look wrong" questions in the Commons codebase (mismatched IDs, orphaned rows, cross-entity divergence, unexpected duplicates, values that don't agree across tables). Use when a ticket or user asks WHY a piece of data is in a surprising state and you must trace it to a root cause through code + production data. Pairs with the commons-sql-query skill for the SQL itself.

Data-Integrity Investigation

A discipline for finding the true root cause of a data anomaly without committing to a wrong one. The failure mode this skill prevents: confidently declaring a hypothesis "confirmed," then having it collapse when one already- knowable fact (a feature-flag mode, a runtime config, the actual patientId on the row) finally arrives. Slow is smooth; smooth is fast.

The method (in order)

1. Pin the symptom precisely

Restate the anomaly as concrete, checkable facts ("row X has patientId = A but patientEnrollmentId resolves to patient B"). Do not paraphrase the ticket — quote the exact IDs/columns. Note what you have not yet proven (e.g. "I have not confirmed which patientId the offending row actually carries").

2. Confirm runtime config BEFORE forming hypotheses

This is the step most often skipped, and the most decisive. Before reasoning about how a value got written, establish the environment it was written in:

• Feature-flag / switch modes. What mode does production run? (e.g. MemberModelV2Switch = OLD_ONLY / DUAL_SUPPORT / NEW_ONLY.) The same code path behaves differently per mode; the wrong assumption invalidates whole hypotheses.
• Which code is even live. A create-time write path is irrelevant if the flag that gates it is off in prod.