Methodology · 20 min read
How Textimony turns raw message exports into reviewable evidence.
Textimony checks the supplied record, keeps original values, asks for participant confirmation when needed, and connects each surfaced item to its source window and report trail.
This page explains the review contract buyers can verify: source handling, participant review, uncertainty, issue queues, reports, and privacy controls.
How does Textimony analyze message exports?
Textimony organizes a user-supplied message export into a reviewable record. It checks the file, retains available source fields, asks users to confirm participants and time handling, and connects surfaced items to message context. Direct counts, software candidates, and reviewer decisions have different meanings and remain separate.
The workflow
Textimony treats an uploaded conversation as a record before treating it as a story. The first job is to determine what was supplied, whether the conversation structure is usable, and which facts still need confirmation. The public workflow is intake, source inventory, message preparation, participant review, timeline review, issue organization, report assembly, and export. Each stage leaves enough context for the next reviewer to understand what changed. Inventory each source before creating a working copy. Keep original message text, sender labels, dates, and source order available. Separate group threads and mixed conversations from two-speaker records. Leave sender identity unresolved when the source does not support a reliable choice. Pause issue review when the record needs correction or participant confirmation. Tie report excerpts back to source rows and surrounding context.
Intake checks before message review
A filename alone does not establish what a file contains. Textimony checks whether the upload is readable, whether its structure matches a supported message record, and whether sender and timestamp fields can be parsed without guessing. Files that do not support a reliable two-participant record are returned with a correction state. Textimony does not turn arbitrary text, image files, or a multi-person thread into a polished conversation simply because some words are visible.
| Step | What Textimony does |
|---|---|
| File integrity | Checks that the supplied record is readable and consistent with its declared type. |
| Conversation structure | Looks for repeatable message boundaries, sender fields, dates, and thread context. |
| Source preservation | Keeps the owner-preserved file separate from normalized working data. |
| Thread scope | Stops group or mixed-participant records from entering the two-speaker analysis workflow. |
| Visual records | Returns an OCR-required state for PDFs and images so the user can provide a supported structured export. |
| Correction path | Returns a focused next step when the supplied record needs a clearer export or participant confirmation. |
Records Textimony can organize
The web intake prepares compatible CSV, WhatsApp TXT, HTML, JSON and JSONL exports, Android SMS XML, and EML email. JSON support includes message arrays and supported Google Chat exports. Compatible chat files can also arrive in ZIP or GZ archives; packaging alone does not establish compatibility. Preparation identifies conversations before import. Choose the conversation and confirm both people, date handling, and timezone. Group threads, unresolved speakers, missing dates, and unsupported structures need review or correction. PDFs, screenshots, and raw app databases are not automatically converted into reliable message rows.
| Record family | Useful source facts | Review treatment |
|---|---|---|
| Message CSV | Named columns for message text, date, sender, recipient, or direction. | Parses supported iMessage, Android SMS, and generic two-participant tables while retaining supplied labels. |
| Android SMS XML | SMS records with sender or address, timestamp, direction, and body fields. | Reads supported SMS rows and preserves their source order and supplied values. |
| Timestamped chat text | Repeatable timestamp and sender headers with multiline bodies kept together. | Parses supported two-person plain-text exports; weak or mixed structures are rejected. |
| JSON and JSONL | Supported message objects, JSON message arrays, or a Google Chat messages export with creator and text fields. | Prepares supported records while retaining available source identifiers and timestamp provenance; not every nested JSON structure is supported. |
| Compatible HTML exports | Recognizable conversation boundaries, sender fields, timestamps, and message text. | Prepares supported chat records; a generic web page is not a conversation export. |
| ZIP or GZ packaging | Compatible chat files inside the archive. | Prepares supported contents, then requires conversation selection and participant confirmation; an archive is not a merged conversation. |
| Single EML record | From, To, Date, Subject, body, and message identifiers when present. | Keeps available email fields separate from chat-specific assumptions. |
| Unsupported or visual records | PDFs, screenshots, raw app databases, or unrecognizable message structure. | Returns a correction or unsupported state instead of inventing message rows. |
Participant mapping
Textimony maps participants from structural evidence, not tone or story meaning. Sender headers, platform direction fields, phone numbers, email addresses, contact labels, From/To markers, and user confirmation carry the weight. Participant labels are normalized for matching, but raw values are kept. That lets a report show that a normalized speaker came from multiple labels without pretending the labels were identical in the original file. Keep each raw sender label available beside the reviewed participant name. Use account IDs, phone numbers, emails, handles, direction fields, and user confirmation as identity evidence. Treat short labels such as Me, You, A, and B as unresolved until the record gives them context. Do not merge different people because their display names look similar. Do not use tone, pronouns, relationship role, or message meaning to choose a sender. Record who confirmed a participant orientation and when.
UNKNOWN is a real state
The mapper is allowed to abstain. When sender and direction disagree, or when a record lacks enough sender evidence, the message can stay UNKNOWN. That is safer than assigning the wrong participant to make the thread look complete. UNKNOWN rows matter because downstream metrics are participant-sensitive. Harassment counts, custody-interference windows, threats, boundary responses, and response latency all change when the sender is wrong.
| Situation | Current behavior |
|---|---|
| Missing sender in structured JSON | Keeps the sender UNKNOWN and records a warning. |
| Sender/direction conflict in CSV or JSON | Keeps the sender UNKNOWN and records conflict evidence. |
| Incoming row with missing sender but confirmed participant map | Can assign from direction and mapping with lower confidence plus a warning. |
| Two speakers but unclear owner orientation | Requires participant review instead of silently choosing the account owner. |
Analysis gates
Issue review begins only after the record has enough message, participant, and timeline structure to support it. Empty files, unreadable records, group conversations, mixed threads, and materially unresolved sender maps are returned for correction or confirmation. This keeps a clean-looking report from hiding a weak source record. The workspace shows the question that needs attention before the user proceeds. No usable messages: request a different source. Several real participants: keep the record out of a two-speaker workflow. Unresolved sender identity: request participant review. Mixed conversations or duplicate sections: separate and compare the sources. Weak message boundaries or dates: preserve source order and request correction.
Issue lanes Textimony can surface
Textimony separates direct record measurements from issue queues. Direct measurements include source counts, message counts, date coverage, participants, and timestamps. Issue queues group excerpts that a reviewer may need to read closely. Issue lanes are review queues. They help a person find relevant stretches of the record faster, then read the source window before deciding what belongs in a final packet.
| Lane | What it looks for |
|---|---|
| Harassment and repeated contact | Repeated unwanted contact, bypassing blocks, high-volume contact after a boundary, and stalking-adjacent contact patterns. |
| Custody interference | Parenting-time obstruction, exchange sabotage, withheld child-related information, non-return language, and blocked access patterns. |
| Threats and intimidation | Physical, property, reputation, authority, proximity, surveillance, and retaliation pressure. |
| Coercion and leverage | Demands tied to money, passwords, access, court actions, deletion, statements, or exposure. |
| Boundary violations | Ignored contact, access, account, family, workplace, location, and professional boundaries. |
| Insults and degradation | Demeaning labels, role attacks, parent-character attacks, and repeated verbal aggression. |
| Escalation | Changes in issue density, severity, timing, and clustering across the timeline. |
| Record integrity | Deletion pressure, missing sections, duplicate sections, conflicting sender evidence, and source gaps. |
How to read counts
A count states how many rows entered a named review queue in the current report. The same page should also show the participant map, date range, skipped records, duplicate handling, and source windows behind that number. Report language stays concrete. “12 rows were queued for repeated-contact review” is measurable. The underlying messages and surrounding exchange remain available so the reviewer can decide what the count means for the matter. Count rows, not feelings. Keep row IDs and timestamps beside every counted excerpt. De-duplicate repeated export sections before treating counts as volume. Do not remove legitimately repeated messages just because the text matches. Show skipped rows and unresolved sender rows near the metric summary.
Reports and packet output
The workspace assembles analysis output from the signed-in case record: source details, participant orientation, direct counts, candidate issue lanes, excerpts, and surrounding context. An automatically generated report reflects the completed run; a reviewer can then use decisions and selections to rebuild a curated report. A curated report is only as careful as the review behind it. Accepting, rejecting, or leaving a candidate unresolved should remain visible in the case workflow instead of being converted into an implied legal conclusion.
| Report field | Why it is included |
|---|---|
| Packet ID | Lets a reviewer refer to one report build. |
| Source artifact labels | Keeps private filenames out of the public-facing review copy. |
| Participant map | Shows sender assumptions and unresolved mapping questions. |
| Issue queue | Keeps software candidates separate from reviewer decisions. |
| Context windows | Lets a reviewer inspect surrounding messages before selecting an excerpt. |
| Review state | Shows whether a candidate was accepted, rejected, or remains unresolved. |
| Available exports | Uses the formats and fields offered by the current signed-in workspace. |
What readers can check
The homepage includes a clearly labeled illustrative sample so readers can understand the chart and review stages without mistaking example messages for case data. The methodology explains the same workflow in plain language. The signed-in case workflow is where a user can verify upload validation, unresolved-sender handling, group-record rejection, analysis candidates, review decisions, and the reports available for an actual case. Source provenance: enabled control. Accepted records keep source labels, original values, working-copy notes, and report references connected. Ambiguous sender handling: enabled control. Sender identity can remain unresolved when the supplied record does not support a reliable assignment. Group conversation handling: enabled control. Group records are kept out of workflows that require a confirmed two-speaker conversation.
Long messages and model windows
Long messages can exceed the input window of a configured classifier. Where a component supports windowing, the message can be evaluated in overlapping token segments and the resulting candidate stays attached to the original message rather than becoming a detached quotation. Window size and overlap affect what a model can see. They are implementation settings, not measures of truth. A reviewer should still read the complete message and the surrounding exchange because a phrase that looks significant inside one window may read differently in the full conversation.
What changes with record size
An empty or structurally unusable upload should stop with a clear reason. A short record may not provide enough examples for every analyzer, so an abstention or zero-candidate result must not be rewritten as proof that a behavior did or did not occur. A larger record takes more time and computing resources. The workspace reports run stages and failure states, but Textimony does not promise that an arbitrary file size will complete on every configuration. The review contract remains the same: software output is a route into the record, and the underlying messages remain the material a person must inspect.
Rules, models, and assistant features do different jobs
Deterministic checks look for defined language or structural conditions. Their strength is inspectability; their weakness is literalness. Configured classifiers can surface paraphrases and related wording, but their scores are probabilistic and can be wrong. Neither type of output determines intent or legal significance. Assistant-style exploration is separate from the classification pipeline. Generated language should be evaluated through its cited messages and should never be treated as a substitute for reading the record. If an analyzer is unavailable or has too little usable text, the honest result is an abstention or failure state, not a fabricated answer. Direct counts describe rows, dates, sender direction, or other fields in the supplied record. Rule candidates identify messages that met a documented language or structure check. Model candidates identify messages that crossed a configured model threshold. Reviewer decisions record what a person accepted, rejected, reclassified, or left unresolved.
Source references and checksums
At intake, Textimony records a SHA-256 checksum for the supplied file. Recalculating that checksum later can show whether another file is byte-for-byte identical to the uploaded file. It does not prove who created the file, whether the export was complete before upload, or whether a message was deleted before collection. Parsed messages keep available source identifiers such as a row label, message identifier, sender value, timestamp, and source artifact reference. Not every export provides every field, and Textimony does not invent a byte offset, device identifier, or delivery fact that the source does not contain.
| Record control | What it can show | What it cannot show |
|---|---|---|
| Upload checksum | Whether two available files contain the same bytes. | Authorship, completeness before upload, or legal admissibility. |
| Source reference | Which supplied record and available row or message identifier produced an item. | Facts the export never contained. |
| Context view | Messages around a selected candidate for human reading. | A fixed amount of context that is sufficient in every dispute. |
Message-level span candidates
When configured and available, a token-level span tagger can propose a character range inside one message. That range helps a reviewer see which words contributed to a candidate without replacing the complete message. A highlighted phrase is not a diagnosis, a finding of harassment, or proof of a multi-message campaign. Some span classes may not have a verified human-readable semantic mapping. In that situation, the class should remain generic, and a reviewer should rely on the source text rather than an invented label.
Thresholds, abstention, and limitations
A confidence score describes a model’s output under one configuration; it is not the probability that an allegation is true. Thresholds control which candidates surface, and changing a threshold changes the tradeoff between missed candidates and false positives. Textimony does not publish a universal accuracy guarantee across every category, export style, language, and conversation. Components can misread sarcasm, quotations, shared accounts, coded language, and context outside the record. When a component cannot run, its status should say so. “Could not analyze” and “analyzed but found no candidate” are different results.
Does Textimony force every upload into a two-person conversation?
No. The current analysis workflow is for a single two-participant conversation. Group records, mixed conversations, unsupported files, and weak conversation structures are rejected with a correction state rather than squeezed into two people.
Does Textimony decide which party is telling the truth?
No. Textimony organizes source records, measurements, issue queues, context windows, and reports. Case decisions belong with the people reviewing the record.
What can a buyer verify publicly?
The labeled homepage sample, participant-review explanation, privacy policy, trust page, evidence guide, and methodology page explain the product contract without presenting illustrative messages as real case data.
Published by
Textimony. Editorial status: Current public product methodology maintained by Textimony. 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; 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; Federal Rule of Evidence 106 — Legal Information Institute, Cornell Law School; SWGDE Best Practices for Mobile Device Evidence Collection and Preservation — Scientific Working Group on Digital Evidence