Glossary · 12 min read
A plain-language glossary of text-message evidence terms.
A count, a model candidate, a reviewer decision, and a legal finding are not interchangeable. These definitions keep the measurement, source, uncertainty, and human judgment separate.
This glossary defines terms used in Textimony and in general message-record review. A definition explains a measurement or workflow state; it does not determine intent, authenticity, admissibility, or legal significance.
Export and format terms
A file extension describes a container, not the quality or meaning of the record inside it. Textimony currently accepts supported message CSV files, Android SMS XML, timestamped two-person chat text, line-delimited message JSON, and a single EML record. The parser still needs recognizable sender, time, and message structure. PDFs, screenshots, archives, raw application databases, nested platform export bundles, and group conversations are outside the current automated analysis path. They may matter to a broader evidence collection, but they are not converted into Textimony message rows.
| Term | Definition | Why it matters |
|---|---|---|
| Supported message table | A CSV with recognizable message text, date, and sender or direction fields. | Structured columns reduce the number of assumptions needed during parsing. |
| Timestamped chat text | A plain-text export with repeatable date, sender, and message boundaries. | Portable and readable, but limited to fields included by the exporting app. |
| Line-delimited JSON | One supported message object per line rather than a nested platform archive. | Stable object fields can preserve source labels without implying support for every JSON export. |
| Normalized working record | The parsed representation used by the analysis workflow. | It supports consistent review while remaining distinct from the supplied file. |
Retrieval and ranking terms
Retrieval changes reading order; it does not change the source record. A highly ranked message may be relevant to the search or category and still be misleading outside its context. An ordinary-looking message may matter even when no automated component ranks it highly. Configured retrieval components can be unavailable or can return no result above a threshold. Those states should remain visible so a user can tell the difference between no candidate and no completed search.
| Term | Definition | Why it matters |
|---|---|---|
| Hybrid retrieval | A ranking that can combine semantic, lexical, and existing signal scores with configured weights. | Balances different notions of relevance without making any one score a verdict. |
| Reranker | A configured model that can re-order a limited candidate set against a query. | Affects what appears first, not whether the message is true or important to the matter. |
| Anchor boost | Additional ranking weight for messages already associated with a review item. | Can keep related material visible, but can also reinforce an early selection. |
| Top-K | The number of candidates retained for another ranking step. | Limits computation and review volume; items outside the cutoff are not necessarily irrelevant. |
Provenance and integrity terms
Provenance describes where a record came from and what happened to it. Textimony begins its verifiable history at upload. It cannot reconstruct undocumented custody before upload or certify that the exporting account contained every message. A checksum is useful because it is precise: it answers whether two files have the same bytes. It should not be stretched into an answer about authorship, identity, completeness, or admissibility.
| Term | Definition | Why it matters |
|---|---|---|
| Source checksum | A SHA-256 value calculated from the bytes of the supplied file at intake. | Supports later byte-for-byte comparison from the moment Textimony received the file. |
| Run metadata | Configuration, component availability, and identifiers recorded for an analysis run. | Helps explain which processing path produced the stored output. |
| Idempotent rebuild | Replacing run-bound results during a retry instead of appending them as new messages. | Reduces count inflation caused by repeated processing. |
| Frozen case timezone | The IANA timezone selected and retained for the case timeline. | Defines which local calendar day receives a timestamp, including daylight-saving rules. |
Review and confidence terms
Review terms identify who or what produced an item. An automatic report can summarize a completed analysis before a person has decided every candidate. A curated report is a later build based on recorded reviewer decisions and selections. Neither report type decides a disputed fact. The distinction tells the reader whether an item is direct record data, software output, or a human choice.
| Term | Definition | Why it matters |
|---|---|---|
| Software candidate | A rule- or model-generated suggestion that points to source material for review. | Distinguishes automated triage from a reviewer’s conclusion. |
| Abstention | A component declining to emit output, with a reason when available. | Separates “no candidate” from “component could not complete.” |
| Threshold | A configured score boundary above which a model emits a candidate. | Controls output volume; it does not convert a score into certainty. |
| Reviewer decision | A human acceptance, rejection, reclassification, note, or unresolved state. | Makes the curated report’s human choices inspectable. |
Communication metrics
Communication metrics describe observable structure: volume, timing, direction, and grouping. The arithmetic can be objective even when the interpretation is not. Work schedules, device access, health, shared responsibilities, and missing records can all change the same measurement. Use a metric to locate a period worth reading. Do not use it by itself to label a relationship healthy, abusive, avoidant, obsessive, cooperative, or unsafe.
| Metric | Operational definition | Responsible use |
|---|---|---|
| Conversation density | Message or character volume within a stated time window. | Compare periods and then read the messages; density alone does not establish harassment. |
| Response latency | Elapsed time between a message and a following reply under a stated pairing rule. | Describe timing without inferring deliberate delay, fear, or urgency. |
| Direction balance | Sent and received message or character totals for the confirmed participants. | Shows asymmetry in the supplied record, not why that asymmetry exists. |
| Conversation episode | Messages grouped under a documented inactivity rule. | Creates navigable reading units; the boundary is analytical rather than a fact supplied by the app. |
| Topic persistence | Consecutive turns assigned to a topic under a stated method. | Can guide review when available; it does not prove fixation or refusal. |
Observable review indicators
An indicator is a reason to inspect a message or period, not a conclusion about a person. Textimony may surface candidate language involving threats, repeated contact, financial leverage, custody logistics, or a stated boundary. The reviewer must decide whether the category fits after reading context. Avoid diagnostic labels for hidden motives. Message text can document what was written and when; it rarely establishes a complete psychological explanation for why it was written.
| Indicator | Observable definition | Review question |
|---|---|---|
| Volume change | A visible increase or decrease in message counts over a stated period. | What events and ordinary messages surround the change? |
| Context window | Messages before and after a selected excerpt. | How much context is needed for a fair reading in this matter? |
| Candidate span | A character range inside one message proposed by an available analyzer. | Does the full message support, contradict, quote, or neutralize the highlighted phrase? |
| Boundary statement | Language asking that a kind of contact or topic stop or change. | What exactly was requested, and what messages followed within the stated scope? |
| No-reply period | A period in the supplied record without a reply under a defined pairing rule. | Is the record complete, and what alternative explanations remain? |
| De-escalation language | Words that may redirect, pause, apologize, or narrow a dispute. | How did the surrounding exchange develop without assigning motive? |
Technical record terms
Technical controls help a reviewer describe the supplied record accurately. They do not transform an export into a forensic image, recover deleted records, identify a physical device user, or guarantee that a court will admit the result. Textimony works from the supported export the user supplies. Collection from a live device, raw database examination, carrier records, and forensic imaging require separate tools and qualified procedures.
| Term | Technical definition | Limit |
|---|---|---|
| Participant mapping | Orienting two participants from supplied sender fields, direction, and user confirmation. | Does not prove who physically used an account or device. |
| Source manifest | A record of supplied source artifacts and available identifiers or checksums. | Documents Textimony intake, not undocumented custody before intake. |
| Automatic report | A report assembled from a completed analysis run before all candidate decisions are necessarily made. | Contains software output that still needs review. |
| Curated report | A rebuilt report reflecting recorded reviewer decisions and selections. | Records judgment; it does not certify that the judgment is legally correct. |
| Structural warning | A parser or workflow notice about missing, conflicting, unsupported, or ambiguous input. | Signals a review need; it does not prove tampering. |
| Source reference | An available artifact, row, message identifier, sender label, or timestamp connected to parsed output. | Cannot supply metadata absent from the export. |
| Conversation normalization | Converting a supported two-person export into a consistent working record. | Does not recover deleted data or merge unsupported platform databases. |
Four questions for a reviewable record
These four questions are a Textimony review framework, not a universal forensic standard. They help a user see what is known, what is assumed, what the software produced, and what a person decided. The applicable court and jurisdiction determine evidentiary requirements. A reviewer may need additional testimony, device records, certified business records, or forensic collection that Textimony does not provide.
| Question | What to document | Why it helps |
|---|---|---|
| What was supplied? | File type, export method, date range, checksum, and known omissions. | Prevents a review copy from being confused with the original source. |
| Who are the participants? | Raw sender labels, direction fields, unresolved aliases, and user confirmation. | Keeps identity assumptions visible and prevents tone-based assignment. |
| What did the software do? | Direct counts, rule candidates, model candidates, settings, abstentions, and failures. | Lets another reviewer distinguish arithmetic from probabilistic suggestions. |
| What did the reviewer decide? | Accepted, rejected, reclassified, unresolved, and selected items with context. | Shows the human choices behind a curated report. |
Published by
Textimony. Editorial status: Product and review terminology maintained by Textimony. Legal and forensic terms retain their ordinary professional meaning. 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