Query the row before reasoning about the UI
Debugging a user-reported issue where a CRM triage UI displayed an identifier that conflicted with the user's mental model of who sent a message
A user reported their triage UI showed FROM Ansh Tulsyan (WA), lid-177949101793395 for a message they sent to a group chat. I theorised about per-group LIDs, then about a second WhatsApp account, then flipped under user pushback to 'you have a second number, let me add it to your me-person.' All three theories were wrong. The actual row in both the application database and the bridge's source-of-truth said direction='out', from.platform_id='17373182064' (the user's known phone), sender_id='17373182064' in the bridge. The data was fine. The UI was rendering the BUCKET KEY (which for outbound rows is to[0].platform_id — one specific group member's LID) on the same line as the sender's display name, making the identifier look like it belonged to the sender when it actually identified a recipient. Two rounds of misdiagnosis from interpreting the user's UI screenshot through theories about the protocol, when one SQL query against the underlying row would have shown the data was correct and the bug was purely cosmetic.
When a user describes a UI display that conflicts with your model of the data, query the underlying row before reasoning about why the protocol or pipeline might generate that display. The user's report is filtered through their interpretation of the UI; the database row is the only unfiltered signal. And when the user pushes back hard, don't flip your theory — verify against the data. Both the original theory AND its reversal were wrong here, and a single query would have caught it. UI/data conflations are common; visually adjacent fields that mean different things (sender display vs bucket key) are a recurring bug class.