Aglet

Triage Duplicate Records Without Losing Context

Duplicate-looking records may be retries, legitimate revisions, repeated business events, or separate entities with similar attributes. Triage should define the suspected identity, compare key fields, and bound the affected source and time window. Preserve all examples before any cleanup or consolidation decision.

Establish what is happening

  1. Define logical identity

    List the fields that are expected to identify one logical record and distinguish them from mutable attributes. Compare exact keys, source references, event times, versions, and payload fingerprints. If no identity rule exists, mark that as a contract gap rather than choosing a convenient field.

  2. Classify repeated shapes

    Group examples into exact repeats, retries with changed metadata, revisions with new state, and similar but distinct records. Compare creation order, delivery markers, source sequence, and business context. Keep one example of each class so a count does not erase important differences.

  3. Measure downstream effect

    Count suspected duplicates by source, identity pattern, time window, and processing path. Recalculate affected totals, latest-state views, joins, and exports using both raw and grouped records. Note whether duplicates are increasing, isolated to one release, or present throughout historical data.

What to carry forward

Produce a duplicate scope brief with identity evidence, classified record shapes, affected outputs, and cohort boundaries. Triage stops when the team can distinguish repeated delivery from legitimate repetition. Keep cleanup undecided for ambiguous groups and preserve the original records and comparison queries.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow