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.
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 current intake accepts supported CSV message tables, Android SMS XML, timestamped plain-text chat exports, line-delimited JSON message records, and a single EML email record. The upload screen remains the source of truth for current file extensions. Compatibility depends on the structure inside the file: one two-participant conversation, repeatable message boundaries, sender information, timestamps, and message text. A PDF, screenshot, raw app database, archive, or nested platform JSON export is not silently converted; the workspace asks for a supported export instead.
| 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. |
| Line-delimited JSON | One message object per line with supported sender, timestamp, and text fields. | Uses the message objects supplied; nested platform export bundles require conversion first. |
| 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, archives, raw app databases, several threads, or missing structure. | Returns a specific correction 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.
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-07-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