Machine Learning · 14 min read
How Textimony uses machine learning on message evidence.
Textimony combines deterministic rule checks with configured classifier and retrieval components. Model output is presented as a candidate linked to source messages, not as a finding about intent, credibility, or law.
This document describes the configured analysis components Textimony can run, the output they produce, their failure states, and why model output must be treated as a review candidate rather than a conclusion.
Pipeline Overview: Three Layers, Kept Separate
When an analysis run starts, the message record moves through staged work that can include loading and ordering, deterministic language-pattern checks, configured model components, aggregation, timeline generation, and report assembly. The workspace reports stage status so a user can distinguish queued, running, completed, and failed work. The review contract keeps different kinds of output identifiable. Direct record measurements, rule-based candidates, model candidates, and reviewer decisions do not mean the same thing. A curated report should reflect the reviewer’s selections without turning an automated candidate into a human conclusion. This separation matters because the layers have different failure modes. Rules are literal and can miss paraphrase; models generalize and can misfire on sarcasm or context; human selections reflect judgment that software cannot audit. Keeping analyzer origin and available source references visible lets another reviewer weigh each item on its actual basis.
Why This Is Not a Chatbot
Textimony does not ask a general-purpose chatbot to decide what a conversation means. The classification pipeline uses versioned components and recorded settings. Deterministic checks can be repeated from the same normalized input, while model-backed output must still be reviewed because version, configuration, and runtime availability affect what runs. General-purpose assistants are built to produce an answer. An evidence pipeline needs a visible failure state: when a component cannot run—a model file is missing, text is too sparse to embed, or no score crosses a threshold—the analyzer should abstain and record why. An explained abstention is more useful than a fluent guess. Where Textimony offers assistant-style exploration, it is a separate interface and should be evaluated through the citations it returns. It does not convert generated language into a verified finding.
The Issue Candidate Classifier
When configured and available, the issue classifier uses a fine-tuned DeBERTa-v3 encoder to score eligible messages against a focused set of issue types: custody-interference denial, financial coercion, harassment and unwanted contact, legal-process coercion, and threat or intimidation. Each score remains a model output, not a factual determination. The classifier is multi-label: issue types are scored independently, and a message becomes a candidate only when a score clears the configured threshold. Messages beyond the component window can be evaluated in overlapping token segments. Windowing improves coverage, but the reviewer still needs the complete message and conversation context. A small label set is a design choice, not a shortcut. Every label the classifier can emit corresponds to a category a reviewer can actually verify against the source message. Textimony does not ship hundreds of speculative behavioral labels that no reviewer could confirm or falsify.
Token-Level Span Tagging
When configured and available, the span tagger uses token-level heads to propose behavior and entity spans. Instead of only scoring a whole message, it can return a character range associated with a candidate so the workspace can highlight the phrase beside the complete message. Overlapping spans of the same type are merged, spans that reduce to whitespace are discarded, and a per-message cap can limit output to the highest-confidence spans. Span boundaries are clamped to the actual text so a highlight can never point outside the message it came from. Some span labels are still generic class identifiers rather than verified semantic names. Where that is true, the output records it explicitly — the run metadata carries a label contract stating that class identifiers do not yet have a verified semantic label map. That caveat travels with the data instead of being silently dropped.
Evidence Retrieval & Reranking
When configured retrieval components are available, Textimony can combine semantic, lexical, and existing signal scores with recorded weights to order messages for review. An anchor boost can give additional ranking weight to messages already associated with review material. When the configured reranker is available, it can re-order top candidates against category-specific relevance queries. Run metadata identifies configured components and relevant settings so a reviewer can understand why one item appeared before another; an unavailable component should be reported as unavailable, not silently simulated. Retrieval ordering is a reading aid, not a finding. It changes what a reviewer sees first; it never adds a message to a report by itself.
Deterministic Rule Checks
Alongside the models, a family of deterministic analyzers scans the record for direct language patterns: threat phrasing, harassment and repeated-contact patterns, coercive leverage tied to money or legal process, boundary statements, custody-exchange obstruction, and repair attempts such as apologies. These checks are literal. Their output should identify the category, the source message, and the matching phrase when the analyzer provides one. Literal rules can be inspected, but they still miss paraphrase and can overread words whose meaning changes in context. Deterministic checks also provide a stable comparison point. If a model and a rule disagree, the reviewer should read the source message and surrounding exchange rather than treating either score as the answer.
Thresholds, Abstention, and Refusing to Guess
Configured model components use thresholds to decide which candidates to emit. The issue classifier, span tagger, and semantic marker analyzers can use different category or component settings. Run output should be read with the settings and availability metadata it actually records, rather than assuming one threshold applies everywhere. When a component cannot do its job, it abstains with a recorded reason: model unavailable, insufficient text, embedding failure, no matches above threshold. An abstention is a first-class result — it appears in the run record rather than being papered over. Textimony does not publish accuracy guarantees for these models, because no single accuracy number is honest across every record type, conversation style, and category balance. What it publishes instead is the design: high thresholds, recorded parameters, source-linked outputs, and a review step that assumes the model can be wrong.
The Human-Review Requirement
A completed run can create an automatic analysis report before a reviewer has decided each candidate. That report should be read as analysis output, not as a set of verified incidents. The review queue lets a person accept, reclassify, reject, or leave candidates unresolved and then rebuild a curated report from those decisions. The software organizes possible patterns and connects them to source messages; it does not establish intent, credibility, a diagnosis, or a legal conclusion. A reviewer remains responsible for reading context and deciding what, if anything, should be relied on. A model candidate is a reading suggestion with coordinates — never a finding on its own.
Provenance & Reproducibility
Run metadata records the analysis configuration and component availability needed to interpret the output. Where model identifiers, configuration fingerprints, build information, or retrieval settings are recorded, they describe the run that occurred; they do not certify the model’s conclusions. Re-running analysis rebuilds run-bound results rather than treating a retry as additional messages. Daily charts use the case’s frozen IANA timezone, so the same completed run uses one stated calendar boundary across its daily aggregates.
Known Limitations
Models misread sarcasm, in-jokes, reclaimed language, and context that lives outside the record. A message that reads as threatening in isolation may be benign in context, and vice versa, which is why an excerpt should be reviewed with the surrounding exchange. The issue label set is narrow by design and will not cover every pattern a reviewer cares about; the finder and manual review tools exist for everything the models do not attempt. Span labels without a verified semantic map are surfaced generically rather than given invented names. Classifier performance varies by category and record type, and rare categories are harder than common ones. Treat every count in a report as a count of flagged candidates — the messages behind it, not the number, are the evidence.
Does Textimony use GPT-4 or another chatbot to analyze my messages?
No. The classification pipeline runs transformer models that Textimony hosts and versions, alongside deterministic rule checks. Assistant-style features for exploring evidence are separate, clearly labeled, and grounded to specific citations.
How accurate are the models?
Textimony does not publish one headline accuracy number across unrelated categories and record types. Model output remains a candidate because confidence scores do not replace validation on the user’s record. Review the source message, surrounding exchange, analyzer availability, and category definition before relying on a flag.
Are my messages used to train the models?
Uploaded case records are not intended to become training examples. The current handling commitment and any processor details belong in the privacy policy, which should be reviewed alongside this technical description.
What happens when the models are not confident?
Nothing is flagged. Components abstain below their thresholds and record the reason — insufficient text, no matches, or an unavailable model. The run output distinguishes “nothing found” from “could not look,” which matters if the analysis is ever examined.
Published by
Textimony. Editorial status: Technical description of configured analysis components and the current review contract. 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 106 — 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; DeBERTa: Decoding-enhanced BERT with Disentangled Attention — He, Liu, Gao, Chen (arXiv:2006.03654)