Technical Guide · 20 min read
How to verify the integrity and provenance of a message record.
Textimony records an intake checksum, parses supported exports into a working record, preserves available source fields, and reports structural problems without claiming to inspect a device or recover facts the export never contained.
This guide explains what can be verified from the supported file received by Textimony, what the parser keeps, and which questions remain outside the product: pre-upload custody, device ownership, deleted records, carrier data, and authorship.
Start with the limits
Textimony can calculate a checksum for the supplied file and later compare another file to that intake value. It cannot certify that the export was complete at its source, prove that no message was deleted before collection, or reconstruct undocumented custody before upload. Participant mapping uses fields in the supported export and user confirmation. It cannot prove who physically held a device, who controlled a shared account at a particular moment, or whether a display name was accurate. These are not fine-print exceptions; they define the boundary of an export-level analysis.
Repeatable controls and run-bound results
A retry should rebuild results for the run rather than append a second copy of the same analysis. That control reduces accidental count inflation. The run record also identifies relevant configuration and component availability needed to interpret which analysis path completed. Direct calculations should repeat when the normalized messages, participant map, case timezone, date range, and definition remain unchanged. Model-backed candidates still depend on the recorded model and configuration and remain candidates even when they repeat. Reproducibility describes a process; it does not turn a result into a fact or legal finding.
Textimony’s source history begins at intake
When a supported export is uploaded, Textimony calculates a SHA-256 checksum and parses a separate working representation. Parsed rows retain the source artifact reference and available identifiers such as sender label, timestamp, row, or message ID when the format supplies them. This records what Textimony received and how analysis output relates to parsed input. It does not document who possessed the file before upload, provide a raw byte offset for every format, or answer an authenticity challenge by itself. A complete custody account may require testimony and records outside the product.
Participant orientation before analysis
The current workflow accepts one conversation with two participants. It uses raw sender labels, direction fields, addresses, and user confirmation to orient those lanes. A group or mixed-participant record is rejected rather than flattened into two people. When sender evidence conflicts or remains incomplete, a row can stay UNKNOWN and analysis can pause for participant confirmation. Tone, pronouns, anger, apology, or an apparent relationship role are not identity evidence. Downstream directional counts should be read with the participant map and unknown-row count.
Sensitive-data handling is separate from evidentiary meaning
Message records can contain names, phone numbers, children’s information, health details, addresses, account data, and allegations. Diagnostic and analytics systems should minimize exposure of message bodies and direct identifiers. Current operational commitments belong in the privacy and trust policies, not in an evidentiary claim. Public-site examples must be clearly labeled as illustrative, as the homepage sample is. Actual case messages belong only in authenticated case workflows. A privacy control protects information; it does not prove the record is accurate or admissible.
Duplicate handling uses parsed record fields
Legitimate repetition and duplicate data are different. Two rows with the same words may represent two messages. A safe parser compares available identifiers, sender direction, timestamp, text, and other stable fields under its supported format rather than deleting text matches indiscriminately. Textimony prevents the same supported parsed record from being counted repeatedly under its working-record rules. It does not sequence-match screenshot folders, reconcile multiple PDF packets, or produce a ledger of every overlapping backup location. Preserve overlapping source files and document any external reconciliation separately. Duplicate handling protects arithmetic only when the duplicate definition is explicit. It must not erase messages a person actually sent more than once.
Timeline ordering does not repair a device clock
Supported exports can contain missing timestamps, duplicate timestamps, inconsistent formatting, reverse order, or date-only headers. Textimony parses supported values, keeps source order available, and uses one frozen IANA case timezone for daily views. The product does not inspect raw database write logs, compare network timestamps, calibrate clock drift, use cell-tower history, or certify a “true” device sequence. A timestamp problem should remain a warning or unresolved fact unless independent evidence supports a correction. Keep the supplied row order and raw timestamp value. State the frozen case timezone used for calendar days. Flag missing, malformed, or conflicting timestamp fields. Do not infer device location or clock accuracy from the export alone. Escalate disputed timing to a qualified examiner with the relevant source material.
Validate supported exports without pretending to inspect a database
The intake checks the declared extension, readability, and required conversation fields for supported CSV, XML, timestamped text, line-delimited JSON, and EML formats. A file can be syntactically readable and still be unusable because it lacks message boundaries, timestamps, sender structure, or one two-person thread. Textimony does not validate raw SQLite schemas for iMessage, WhatsApp, Telegram, Facebook Messenger, or another app. It also does not prove forgery when a file fails. Unsupported, corrupt, mislabeled, or ambiguous records return a correction state so the user can provide a supported export.
What a SHA-256 checksum proves—and what it does not
SHA-256 converts file bytes into a fixed-length value. If two available files produce the same value, they can be treated as byte-for-byte identical for practical comparison. If one byte changes, the value is expected to change. Textimony calculates the checksum at upload. The value therefore speaks from intake forward, not from original collection. It does not show who authored a message, whether the export included the complete account, whether the device was altered, or whether a court will admit the file. Intake comparison — This available file matches the bytes received at upload. — Completeness or original-device status. Later verification — A recalculated checksum matches or differs from the stored intake value. — Authorship or sender identity. Working-copy separation — Analysis uses parsed working data distinct from the supplied file. — A downstream redaction-hash ledger that the product does not create.
Participant mapping records an attribution basis, not identity proof
A display name, phone number, email address, or account handle can support attribution, but none necessarily proves who typed a message. Shared accounts, changed contacts, forwarded content, spoofing, and unsaved numbers may require corroboration outside the export. Textimony keeps raw sender labels and the reviewed two-participant orientation used by the analysis. It does not cross-examine carrier records, contact databases, IMEI values, or device ownership. Call the result a participant map, state who confirmed it, and preserve UNKNOWN where the source does not justify more. Never assign a sender from tone or story meaning. Use available structural fields and record the remaining uncertainty.
Provenance is a documented path, not “ultimate proof”
Within Textimony, provenance connects the supplied supported file, its intake checksum, the parsed working record, an analysis run, and available source references for candidate or selected messages. That path helps explain how an output was produced. The parser does not extract carrier identifiers, device serials, application write logs, cell locations, raw database pages, or deleted records. Physical-device origin, account control, collection history, and authorship require evidence outside this workflow. State those limits beside any provenance claim.
Published by
Textimony. Editorial status: Technical description of current export-level controls. It is not a forensic-device examination or authenticity certification. 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