What a chat record shows

How to read this

This entry reviews evidence published by other people. The author did not test any tool or examine any device for it. Blocks marked with an evidence class quote or summarize a source; sentences beginning “we” describe what the author did with those sources, which was to read them. Anything DEVI could not confirm is marked as such and left as an open question rather than written up as a finding. Sources change without notice, which is why the verification date is stated.

A chat, as a person reads it, is a conversation: who took part, what was said or attached, and when. That is the shape on the screen. It is not, by itself, a description of the file the app wrote.

What the record shows

The screen groups messages into a conversation. A tool that parses a phone often shows the same shape: a thread, the parties, the text, the attachments, and the times. Two different files can feed that screen.

The message database is the conversation. The usage database is a log that the app was used, and sometimes a hint of the activity. They are not substitutes.

Where it lives

There is no single path for "chats." Each app chooses its own files. The two stores this center documents are Messages and KnowledgeC. Their paths, tables, and limits are on the paired pages, not repeated here as if they covered every app.

Other messaging apps are not described on this page. A path or a column from Messages does not transfer to them.

How to read it

Read the native file the claim depends on, not only the thread a tool drew. For Messages, that is the SQLite database named on the iMessage page. For a question about when the app was on screen, that is KnowledgeC, with the limits on that page.

A parsed transcript can drop rows the database still has, and it can add a label the database does not use. When the transcript and the file disagree, the file is the thing to explain.

What the fields mean

A conversation on screen has a few parts an examiner can name without picking an app:

• Parties: the addresses or accounts in the thread.
• Body: text, or a pointer at an attachment, or both.
• Time: when the app recorded the message, which is not always when a person saw it.
• Status: sent, delivered, read, edited, or removed, when the app stored that status.

Which column holds each part depends on the app and the version. The Messages page lists the columns a cited note actually names. This page does not invent a shared schema.

Pitfalls

A usage row is not the message. Seeing Messages in a focus log does not show the text, and it does not show that a message was sent.

A tool's thread can merge services. The Messages note says one conversation can mix iMessage, SMS, and RCS. The service is a property of the row, not of the thread title.

Counts that include reactions will be high if the app stores a reaction as its own row. The Messages note says tapbacks are rows in the same table as messages.

How it holds up in court

Nothing on this page is a ruling, and nothing here is legal advice. A row in an app database is not self-explanatory in front of a court. What the row shows, how the file was obtained, and whether the law allowed that step are separate questions.

The review is The Legal Questions Around Mobile Device Extraction Are Not One Question.