The problem
Large event logs were difficult to investigate through manual samples and one-off queries. Recognition errors added another complication: the same underlying identifier could appear in slightly different forms, making repeated events harder to connect.
An exact-text comparison could miss those relationships. Reviewers also needed context around the records, rather than a list of possible matches alone.
What I built
I built a dashboard using SQL, Python and Hex to organise the event records for investigation. OCR-aware fuzzy matching supported the review of identifiers that differed because of recognition errors.
The interface grouped records by source, event category, validation status and frequency. These dimensions let reviewers examine both individual discrepancies and patterns across repeated events.
Why matching needed a review interface
Approximate matching is useful when an exact comparison is too restrictive, but similarity is not proof that two records represent the same thing. The purpose of the workflow was to make possible relationships inspectable alongside the surrounding event data.
That distinction shaped the role of the dashboard: it supported investigations into repeated records and mismatches. It was a way to organise evidence for a reviewer, rather than treating every similar identifier as a confirmed match.
Result and scope
The system made event patterns and recognition discrepancies easier to inspect in one structured view. It reduced reliance on scattered samples and ad hoc queries when investigating a sequence of records.
This case describes the technical pattern in general terms. The original application, identifiers, internal categories and matching rules are omitted. The accompanying schematic is illustrative and contains no production records.