Compare like with like
Two exports can differ because of collection scope, folder selection, date filtering, client representation, migration or genuine content changes. A comparison begins with the provenance of each dataset and the meaning of its fields. A count of messages alone cannot establish that the underlying correspondence is equivalent.
Inputs for a meaningful comparison
Supply the preserved datasets, their source descriptions and collection records where available. Explain which messages, custodians or periods are in dispute. Maintain each supplied set separately so that transformations do not obscure its origin.
- Native files or mailbox exports and accompanying attachments.
- Export settings, filters, errors and known exclusions.
- Relevant reference messages and any independent copies.
- The required analysis timezone and the original date values and offsets.
Methods and deliverables
An agreed comparison can reconcile message identifiers, sender and recipient fields, dates, bodies and attachment hashes, with allowances for representation changes. Outputs may include a comparison schedule, a chronology, discrepancy categories and selected exhibits. Derived matching keys should be explained rather than presented as original message properties.
Interpreting gaps and dates
The absence of a match may reflect missing data or an unsuitable matching rule. A different file hash may arise from extra headers or a different export format despite equivalent visible content. Original timestamps and offsets should be retained alongside any normalised display. A sender-supplied date and a server-recorded event answer different questions.
Agree the question and output
A chronology should identify uncertain ordering, clock assumptions and contradictory records. Thread grouping is an analytical aid, not proof that every participant saw every message. Begin with the disputed sequence and the intended audience so that the comparison method and deliverable can be agreed.