Evidence Guide · 25 min read
How to preserve and authenticate text message evidence.
Preserve the best available source, document how it was collected, keep participant assumptions visible, and make summaries traceable to the supplied record. Textimony supports that organization from upload onward.
This guide explains practical record controls and selected Federal Rules of Evidence. Requirements vary by court, jurisdiction, claim, and collection method; consult the appropriate lawyer or qualified examiner for the matter.
Screenshots and structured exports answer different questions
A screenshot can show how a conversation appeared on a screen, including visible contact labels, bubbles, timestamps, and surrounding layout. It can also omit material outside the frame, lose machine-readable fields, or be difficult to place in a complete sequence. Those limits do not make every screenshot false; they define what additional support a reviewer may need. A structured export can be searched, counted, and connected to supplied sender and timestamp fields. Textimony’s automated workflow uses currently supported CSV, XML, timestamped text, line-delimited JSON, and EML records. It does not ingest screenshots, PDFs, raw app databases, or archives as message rows. Preserve those materials separately if they matter to the broader record.
Timezone integrity starts with one stated calendar
Message timestamps may be UTC, device-local, offset-aware, or missing an explicit timezone. A parser cannot recover a timezone that was never supplied without relying on an assumption. That assumption should be visible and testable. Textimony freezes one IANA case timezone for its daily timeline. That choice defines local midnight and daylight-saving transitions for run-bound aggregates. It does not repair a wrong device clock or prove where a device was physically located. If the chosen timezone is disputed, record the dispute and compare the source fields rather than presenting the chart as certainty.
Duplicate handling must not erase real repetition
Duplicate-looking text is not automatically duplicate data. A person can send the same sentence several times, and those repeated messages may be part of the record. Safe duplicate handling compares the fields available to the parser rather than deleting rows because their wording matches. Textimony’s working record uses stable parsed fields to avoid counting the same supported input row more than once, and a rerun rebuilds run-bound results rather than appending another result set. It does not claim to reconcile every overlapping backup or fragmented collection. When two sources overlap, preserve both and document the comparison.
Federal Rule of Evidence 901: what authentication asks
Federal Rule of Evidence 901(a) asks for evidence sufficient to support a finding that an item is what its proponent claims it is. Rule 901(b) provides examples, including witness knowledge, distinctive characteristics, and evidence describing a process or system. The appropriate route depends on the claim being made and the available record. Authentication is not the same as admissibility, and a checksum is not the same as sender identification. A party may rely on testimony, surrounding facts, account information, device records, business records, or other corroboration. Textimony can organize a supplied export and its source references; it cannot testify about collection or decide whether the burden has been met. Describe the item precisely. “This file matches the upload received on this date” is a different claim from “this person authored every message in it.”
Document source history without filling in gaps
Source history records who collected a file, from which account or device, by what method, when it changed hands, and which copy was later reviewed. Missing documentation may affect weight or admissibility, but the consequence is a matter-specific legal question rather than an automatic outcome. Textimony begins its verifiable handling at upload by calculating a SHA-256 checksum for the supplied supported file. The checksum can later identify an identical copy. Textimony does not create a forensic image, inspect a raw SQLite database, write-block a device, or certify custody before upload. Record the account or device from which the export was created. Record the export steps, date, apparent timezone, and date range. Keep the first available copy untouched in appropriately controlled storage. Record later transfers and the purpose of each working or sharing copy. Retain Textimony’s intake checksum and state that it begins at upload. Ask a qualified examiner about device acquisition when an ordinary export is not enough.
Read the metadata the export actually supplies
Metadata means fields about a record, such as an available timestamp, sender label, recipient or direction field, message identifier, attachment reference, or source row. Different export methods expose different fields, and many ordinary exports omit delivery status, read receipts, account identifiers, or timezone offsets. Do not describe an absent field as preserved. An IMEI identifies device equipment rather than the human author of a message, and ordinary chat exports generally do not provide one. Textimony retains supported fields it parses and marks ambiguity; it does not enrich the export with carrier, device, or database metadata from another source.
Build an honest timeline from supplied timestamps
A usable timeline retains source order and parses supported timestamps under one stated case timezone. Missing times, duplicate times, and malformed values should remain visible as data-quality limits. Sorting can organize a record; it cannot prove that a device clock was accurate. Textimony does not synchronize two devices, consult NTP or cell-tower records, correct clock drift, or merge opposing-party databases. If independent records disagree, preserve the discrepancy and obtain appropriate technical review instead of forcing one “true” time. Source order — Retain the order supplied by the supported export. — Source order may itself reflect an export choice. Frozen IANA timezone — Use one named case timezone for daily buckets. — Does not establish the device’s physical location or original clock setting. Timestamp warning — Flag missing, malformed, or conflicting time information. — A warning identifies uncertainty; it does not prove editing or deletion.
Preserve first, then create working copies
If a dispute is foreseeable, preserve the best available source before editing, annotating, or redacting a copy. Record how the export was made and keep ordinary use, account synchronization, retention settings, and backup behavior in mind because they can change what remains available. Do not apply a universal device-isolation recipe without understanding the device and matter. Airplane mode, power changes, remote access, encryption, and Faraday isolation can each have consequences. When physical acquisition, deleted data, or a live account is important, ask a qualified forensic professional and counsel for a matter-specific plan. Textimony is an analysis workspace for supported exports. It is not a device-seizure, forensic-imaging, deleted-data-recovery, or carrier-record collection tool.
Context and Federal Rule of Evidence 106
Federal Rule of Evidence 106 allows an adverse party to require another part of a writing or recorded statement—and in some circumstances another statement—that fairness requires to be considered at the same time. The rule does not prescribe a fixed number of messages around an excerpt. A useful context window is therefore adjustable. Sometimes two adjacent messages explain a scheduling reply; sometimes days of earlier discussion matter. Textimony helps a reviewer inspect surrounding messages, but the reviewer must decide what context is fair and material for the question being addressed.
Integrity checks identify questions, not tampering
A supported parser can identify unreadable rows, missing required fields, conflicting sender information, group participants, unsupported structure, and timestamp ambiguity. Those conditions matter because they affect what can be counted or attributed reliably. The same conditions can arise from ordinary export behavior, incomplete collection, copying mistakes, or manual editing. Textimony does not detect every edit, infer continuous network synchronization, or prove why a gap exists. Preserve the warning, inspect the supplied source, compare independent records when available, and escalate disputed integrity questions to an appropriate examiner.
Published by
Textimony. Editorial status: Educational preservation and review guidance. It is not legal advice, forensic collection, or an admissibility opinion. Updated: 2026-07-23.
Sources
Federal Rule of Evidence 901 — Legal Information Institute, Cornell Law School; Federal Rule of Evidence 902 — Legal Information Institute, Cornell Law School; Federal Rule of Evidence 1006 — Legal Information Institute, Cornell Law School; Federal Rule of Evidence 106 — Legal Information Institute, Cornell Law School; Guidelines on Mobile Device Forensics — National Institute of Standards and Technology; SWGDE Best Practices for Mobile Device Evidence Collection and Preservation — Scientific Working Group on Digital Evidence