How it works

Every data source. One neutral, chronological record.

Disputes hide in inboxes, group chats, workplace channels, voice notes, photo libraries and shared docs. We treat all of them as one body of evidence, governed by the same chain of custody.

Hybrid review

Choose the depth that fits the record.

Local rule-based overview

Our own software processes the chat on our server to reconstruct timelines, calculate counts and surface transparent rule-based indicators. This overview does not send chat content to an AI provider.

Deep Fact-Finding Review

For a scoped white-glove Court Bundle matter, the full record is divided into overlapping, gap-aware context windows so exchanges are not assessed as isolated lines. An AI provider produces structured findings; our pipeline then deterministically deduplicates and synthesises them, classifies direction and directedness, and verifies every quotation exactly against the source record.

The output is neutral and two-sided. This service is not currently self-serve or fully automated. Before any chat is sent, we disclose the provider, data flow and estimated provider cost and obtain your explicit opt-in.

The pipelines

Each data source has its own ingest path and its own quirks. Here's what we do with each.

01 WhatsApp

Group + individual chats, iOS + Android.

  • Accept original .txt exports and safe ZIPs containing the conversation text.
  • Handle common iOS/Android, 12/24-hour and UK/US date ordering, including BOM and directional marks.
  • Preserve multiline text, sender and timestamps; explicit deleted-message placeholders remain visible rather than being silently removed.
  • Preserve the original export privately with a SHA-256 hash and analyse a separate canonical derivative.
  • Media files inside WhatsApp archives are not yet cross-linked automatically; upload important media separately to the evidence vault.

02 Email

One or many .eml files and standard .mbox exports.

  • Parse RFC email dates, encoded headers, plain-text and HTML alternatives; quoted reply blocks are removed from the analysis copy to reduce duplication.
  • Preserve every original .eml/.mbox byte-for-byte with its SHA-256 hash, so headers and MIME structure remain available for audit.
  • Normalise timezone-aware dates to UTC for the combined chronology.
  • Emails copied to other people are imported as they are, and every person in the record is named after the import, so nothing is merged in unnoticed.
  • Attachments remain in the original email and can be added separately to the evidence vault when they need individual analysis.

03 SMS / iMessage

Apple Messages chat.db with conversation picker, iMazing CSV, Android SMS Backup & Restore XML, Telegram HTML/JSON, Snapchat and LinkedIn.

  • Read iMazing-style CSV and generic CSV/TSV with sender or sent/received direction fields.
  • Read Android SMS and MMS text from SMS Backup & Restore XML using UTC epoch timestamps and sent/received direction.
  • Read Apple sms.db/chat.db directly, including the modern attributed-body records that hold the text of recent iOS messages. A database containing several conversations prompts you to choose which one belongs to the case, so unrelated correspondents are never imported. Tapbacks, reactions and attachment-only records are reported as skipped rather than guessed.
  • Use the uploader's chosen self-label for outgoing messages, and refuse a whole-phone backup that holds conversations with several people until one conversation is chosen.

04 Social and workplace messaging

Messenger, Instagram and Telegram official JSON exports, and workplace exports from Slack, Microsoft Teams, Skype, Google Chat, Discord and Viva Engage.

  • Read Meta Messenger/Instagram message JSON directly or from a ZIP containing one conversation folder.
  • Read Telegram Desktop machine-readable JSON, including rich-text arrays and attachment markers.
  • Use Unix timestamps for chronology, repair known historical Meta encoding corruption and retain explicit unsent markers.
  • Read workplace exports as one batch per workspace: Slack export ZIPs (per-day channel JSON merged in order, member IDs resolved from users.json), Microsoft Teams Graph JSON, data export tool ZIPs and PowerShell CSVs, Skype and Teams personal messages.json, Google Chat Takeout, Discord data packages and DiscordChatExporter JSON, and Viva Engage Messages.csv. Every message keeps its channel and its thread; joins, topic changes, deletions and calls become labelled system records; UTC timestamps are converted to UK time and the batch says so. A Discord data package is labelled as the requester’s own messages only.
  • Reject ZIPs containing several different conversations instead of silently mixing them. Native encrypted Signal backups are not supported; a provenance-labelled CSV/JSON export is required.

05 Audio recordings

Voicemails, handover recordings, mediation sessions.

  • AI draft transcription of audio and video, clearly labelled as a draft: certified human transcripts remain required for court use and we say so alongside every transcript.
  • Time-aligned highlight clips: jump straight to the relevant 12-second segment.
  • Background noise and silence trimming for a cleaner courtroom playback.
  • Cross-reference recorded statements with chat messages from the same window.

06 Video

Doorbell camera, dashcam, mobile-phone clips.

  • Audio extraction → transcription pipeline (same as audio recordings).
  • Frame-level OCR for any on-screen text or timestamps burned into the footage.
  • Object/scene detection: handover scenes, vehicle plates, presence of children, surfaced as evidence tags.
  • Stamp metadata preservation: original timezone, device, GPS, codec, all retained for authenticity.

07 Photos

Camera roll exports, shared albums, forwarded screenshots.

  • EXIF: date, time, GPS, device, edited/not-edited. Critical for "when and where was this taken".
  • OCR for any text in the image: handwritten notes, receipts, screenshots of websites.
  • Reverse-lookup against the chat timeline: was this photo sent or just stored?
  • Optional facial detection (consented use only) for "who appears in which photos".

What happens after ingest

Local overview processing is separate from the optional Deep Fact-Finding Review. AI review of chat content occurs only after the consent and scoping step described above.

Cross-source linking

The same event often appears in WhatsApp ("running late"), SMS ("on my way"), and a dashcam timestamp. We collapse them into one timeline node so the court sees one clear, chronological picture instead of the chaos.

Pattern detection

"Late handovers": automatically flagged when promised and actual times diverge by more than 15 minutes across multiple events. Same for missed payments, ignored medical decisions, school-pickup failures.

Bundle export

Where commissioned, a page-numbered PDF is indexed and paginated to the relevant bundle conventions. It carries an exhibit list, chronology and source manifest, with SHA-256 hashes supporting integrity checks. The separate Deep Fact-Finding Review is an aid to review, not itself evidence or a court document.

The output

What makes a document “court-ready”

Download a sample fact-finding review (PDF, fictional parties) →

A court-ready document isn’t just a tidy PDF. In UK proceedings it has to satisfy the court’s rules on bundles, authenticity and disclosure, and withstand scrutiny from every party and the court. Here is the anatomy LegallyHeard builds into every export.

Anatomy of a court-ready bundle

  • Front sheet & case heading: court, case number, parties, and what the document is.
  • Paginated throughout: continuous page numbers so any line can be cited as “p. 47, line 12”, aligned to the court’s bundle expectations (e.g. Family PD 27A).
  • Index / table of contents: every section and exhibit listed with its page.
  • Chronology: a dated, neutral sequence of events with a source reference for each entry.
  • Exhibit list & labelling: each piece of evidence given a reference (e.g. “Exhibit JS-1”) and cross-referenced from the statement.
  • Source manifest: what was ingested, from which device/export, when, and its original file hash.
  • Message extracts in context: clusters, not cherry-picked single lines, each with a full timestamp (date and time).
  • Statement of truth block: the wording a witness signs to verify the facts, ready to complete.
  • Integrity / authenticity: SHA-256 hashes recorded at intake, so any party can verify nothing was altered between intake and export.
  • Redaction layer: irrelevant third parties, minors and sensitive data removed on a controlled, logged pass.

LegallyHeard formats the document to these conventions. Whether a specific document is admitted in a specific hearing is always a matter for the court, and LegallyHeard does not provide legal advice.

IN THE FAMILY COURT SITTING AT [•]
Case No: [••••••]
BETWEEN:
[Applicant]: Applicant
and
[Respondent]: Respondent
EXHIBIT “JS-1”. CHRONOLOGY OF MESSAGES
28 Feb 2025 18:33Respondent“don’t make this about me”
28 Feb 2025 18:37Respondent“keep it up and I’ll make sure you never see her again”
28 Feb 2025 18:39Applicant“That’s a threat. I’m keeping this message.”
SHA-256: 9f2c…a71e Page 47 of 112
Statement of truth

“I believe that the facts stated in this document are true. I understand that proceedings for contempt of court may be brought against anyone who makes, or causes to be made, a false statement in a document verified by a statement of truth without an honest belief in its truth.”

Signed ……………… · Dated ………………

Illustrative sample. Placeholders shown in [brackets].

Want to see the pipeline run?

Our in-browser demo runs the WhatsApp leg of the pipeline live on your machine, with nothing uploaded.