Evidence Guide · 18 min read
How to organize text messages into court-ready evidence.
A useful message packet keeps the original export, participant map, timestamps, surrounding context, redactions, and report notes connected. Textimony is built around that workflow.
This guide is for people organizing message records before professional review. It covers source preservation, participant maps, context windows, redaction, timelines, and report handoff.
The short answer
Text messages become easier to review when the packet shows where each message came from, who sent it, when it was sent, what came before and after it, and what changed during redaction or export. A screenshot can help, but it is usually only a view of the record. A stronger handoff keeps the original export, working copy, context window, source manifest, participant map, and report build notes together. Start with preservation. Do not begin by rewriting messages into a summary. Keep the raw export intact, then build review copies from it.
How do I prepare text messages for a U.S. court review?
Start with the most complete record you can lawfully obtain. Save the original export unchanged, record who exported it and when, and keep a separate working copy. Preserve sending and receiving identifiers, source timestamps, surrounding messages, and available attachments. Distinguish federal rules from the state rules and local filing requirements that govern your matter. A family-court packet may need a different format, redaction treatment, or foundation from a federal civil filing. Authentication, completeness, and summaries are separate questions. Federal Rule of Evidence 901 concerns support for what the record is claimed to be. Rule 106 addresses context that fairness requires when a statement is introduced. Rule 1006 addresses qualifying summaries of voluminous admissible materials and access to the underlying originals or duplicates. A software report does not establish these requirements by itself. Ask counsel how the source, witness or certification, excerpt, and proposed use fit the governing rules. Keep the original export, acquisition notes, and source-file inventory together. Confirm participants from source identifiers; a contact nickname alone may need corroboration. Record source and report timezones, including daylight-saving ambiguity. Retain surrounding messages and record missing attachments or date gaps. Make redacted sharing copies while retaining the unmodified originals. Ask counsel about authentication, completeness, hearsay, and local exhibit requirements.
What to save before you review
Save the original conversation export or backup first. Keep the file name, device or account source, export method, date range, timezone clue, media decision, and any error shown during export. If the source is an app screenshot, keep the image files in their original order and avoid cropping away timestamps, contact headers, message tails, attachment labels, or surrounding messages. Original export file, backup, or screenshot set. Date range and timezone assumptions. Device, account, app, or platform where the messages were found. Export method and whether attachments were included. Unedited working copy for review. Redacted copy for sharing. Source manifest listing every file used in the packet.
Build a source map before making claims
A source map is the table that says what was supplied: file, row count, date range, participant clues, export format, media status, and review status. The source map prevents the common mistake of treating a clean PDF as the source. The PDF is the review copy. The export or original capture set is the record that the review copy points back to.
| Field | Why it matters |
|---|---|
| Artifact label | Gives each source a stable public name such as Artifact A instead of leaking file names. |
| File type | Shows whether the record came from CSV, TXT, XML, EML, JSON, screenshot, or another source. |
| Date coverage | Shows gaps, overlaps, or ranges that need review before a timeline is trusted. |
| Row count | Lets reviewers spot missing sections, duplicate exports, and unexpectedly small files. |
| Media choice | Separates text-only exports from exports that include attachments. |
| Review status | Shows whether the source was accepted, skipped, duplicated, corrupted, or needs follow-up. |
Map participants before reading meaning into the thread
Participant mapping comes from structural evidence: sender headers, account direction, phone numbers, email addresses, contact labels, platform fields, and user confirmation. Do not decide who sent a message because the sentence sounds angry, apologetic, masculine, feminine, parent-like, or victim-like. That kind of guessing corrupts every metric after it. Keep raw sender labels separate from normalized participant IDs. Treat Me, You, Sender, Recipient, Person A, and redacted labels as aliases that need evidence. Use UNKNOWN when the record does not support a reliable sender assignment. Do not force a group chat into two people. Ask one focused confirmation question when the system can separate two speakers but cannot tell which speaker is the account owner.
Make the timeline reviewable, not just sorted
A good message timeline keeps source order and resolved order visible. Some exports have missing timestamps, duplicated timestamps, date headers, timezone gaps, copied sections, or reverse chronological order. Sorting everything by timestamp can hide extraction problems. Keep source row numbers, preserve warnings, and state the timezone used for review. When a timestamp is missing or ambiguous, the honest result is an unresolved time—not an invented one.
| Timeline signal | How to treat it |
|---|---|
| Structured row index | Usually stronger than a guessed timestamp. Keep it. |
| Full timestamp | Strong when parseable and consistent with surrounding rows. |
| Date-only header | Useful for grouping, weaker for ordering within the day. |
| Missing timestamp | Keep source order and mark timestamp confidence lower. |
| Duplicate timestamp | Do not remove a message just because time matches another row. |
| Reverse order | Repair only when the evidence is consistent across the file. |
Screenshots and exports do different jobs
Screenshots show what a person saw. Exports are usually better for row-level review because they can carry timestamps, sender fields, attachments, and larger date ranges. When both exist, use screenshots to corroborate visible display and use exports for source-linked organization. Do not let a screenshot replace the source inventory. Screenshots: useful for visible layout, contact headers, bubble sequence, and app display. Exports: useful for searchable text, row counts, timestamps, sender fields, and manifest-backed reports. PDFs: useful as review packets, but only when they point back to the source rows.
Redact the copy, not the source
Redaction protects names, phone numbers, emails, addresses, school labels, child identifiers, file paths, and account handles without changing the underlying source record. Keep a separate note of what kind of information was removed and why. The goal is a safer sharing copy, not a rewritten conversation, and the untouched source should remain available to an authorized reviewer. Keep originals untouched. Create a working copy and a sharing copy. Replace private identifiers with consistent labels. Keep row IDs, dates, and source references intact when safe. Record each redaction category in review notes.
What belongs in a report packet
A review packet should make the record easier to inspect without pretending the software is the decision-maker. Useful sections include source labels, participant assumptions, message counts, candidate issue lanes, selected excerpts, context windows, and the reviewer decisions used for a curated report. Textimony separates direct measurements from review candidates. Direct measurements include row counts, date ranges, sender labels, and timestamps supplied by the record. Candidate labels point to messages that still need human reading in context.
| Packet section | Purpose |
|---|---|
| Control sheet | Identifies the packet, date range, row volume, source count, and review state. |
| Source manifest | Lists source artifacts, accepted rows, skipped rows, and verification IDs. |
| Participant map | Shows labels, aliases, confidence, and unresolved mapping questions. |
| Issue index | Groups candidate messages into review lanes without deciding what they mean. |
| Excerpt queue | Shows selected messages with source references and surrounding context. |
| Review decisions | Records which candidates a reviewer accepted, rejected, or left unresolved. |
| Available exports | Packages the selected material in the formats offered by the current workspace. |
Print checklist
Use this checklist before sharing a review packet. It is deliberately plain because the work is already complicated enough. Original source file is saved and untouched. Working copy is separate from the original. Participant map is confirmed or marked unresolved. Each selected excerpt keeps its available source reference and surrounding context. Timestamps show timezone assumptions where known. Duplicate exports and repeated sections were checked. Redactions in a sharing copy are documented in review notes. The packet says what was skipped and why. The reviewer can reach the underlying source 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.
| Timeline control | Responsible treatment | Limit |
|---|---|---|
| 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. |
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.
Are screenshots enough for text message evidence?
Screenshots can be useful, but they are easier to separate from surrounding context. A stronger packet ties screenshots or PDFs back to source exports, row IDs, timestamps, and a manifest.
What if the sender names are wrong?
Stop and fix the participant map before trusting metrics or summaries. Wrong sender attribution changes harassment counts, custody-interference lanes, response timing, and every participant-specific finding.
Should repeated identical messages be removed?
No. People really do send repeated messages. Treat duplicates as a source question, not a text-only question. Compare sender, timestamp, source artifact, attachment data, and overlapping provenance before marking a row duplicate.
Published by
Textimony. Editorial status: Product and evidence-workflow guide. Human review recommended before case use. Updated: 2026-10-23.
Sources
Federal Rule of Evidence 901 — 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; How to export your chat history — WhatsApp Help Center; Use Messages in iCloud — Apple Support; Federal Rule of Evidence 902 — Legal Information Institute, Cornell Law School; SWGDE Best Practices for Mobile Device Evidence Collection and Preservation — Scientific Working Group on Digital Evidence; Current Federal Rules of Evidence — Administrative Office of the U.S. Courts