Preparing Text-Message Exhibits from an RSMF Export

Text-message and chat evidence increasingly arrives as an RSMF file — Relativity Short Message Format — rather than as screenshots. Relativity and Reveal export it; collection tools such as Hearsay, iMazing, Message Crawler and ChatExport write it from a phone or an account. ExhibitPrep reads that file in your browser and renders each conversation as a dated, searchable transcript that is then stamped like any exhibit. Nothing is uploaded: the file is parsed, hashed and rendered on your device.

What an RSMF file is

An .rsmf file is an email-shaped wrapper (RFC 5322) around a zip archive named rsmf.zip. The archive holds rsmf_manifest.json — the participants, the conversations, and every event (messages, joins, leaves, disclaimers, history) with its timestamp, sender, text, reactions, edits, attachments and, in RSMF 2.0, direction and read receipts — plus the attachment and avatar files. The wrapper's headers record the generator, the application the messages came from, the custodian, the date range and the event count. ExhibitPrep accepts RSMF 1.0 and 2.0 and a bare rsmf.zip.

What happens when you add one

Add the file with your PDFs. Instead of becoming a document straight away it opens the message intake panel:

• Validation. The file is checked against the RSMF specification the way Relativity's validator checks it: passed, passed with warnings, or failed. A failed file is still rendered, with each problem stated — a missing attachment, an undeclared participant, a timestamp that is not ISO 8601, a reply whose parent is not in the file.
• The export's facts. Generator, application, custodian, begin and end dates, collection id — as the file states them.
• Conversations. Each conversation with its platform, participants, event count, date range and an estimated page count. Choose the ones to render; each becomes one PDF.
• Date range. An optional slice in UTC. Every transcript states how many of the conversation's events it carries and the range applied, so a slice can never pass as the whole conversation. Events without a timestamp are kept in every slice because they cannot be placed.
• What is shown. Reactions (with who reacted), edit history, read and delivery receipts, message direction. Deleted and edited messages are always kept and marked.
• Attachments. Every attachment is listed with its size and SHA-256; PNG, JPG and GIF images can be shown in place.

The panel estimates pages against the 500-page bundle limit before anything renders, so a 10,000-event export is sliced here rather than refused later.

What each transcript contains

Page 1 is a source record: the export's SHA-256 and the SHA-256 of the rsmf.zip inside it, every X-RSMF header, the manifest version, the participants the file declares (with account identifiers and email addresses as declared), how many of the conversation's events are rendered and the filter applied, the rendering settings, the validation outcome and findings, and the typography disclosure. Then the ledger: every event in time order (ties in file order; undated events first, as Relativity's viewer shows them), each row carrying a citable number, the full timestamp in UTC (an asterisk marks a timestamp that carried no time zone), the sender's display name and account identifier, INCOMING or OUTGOING and HIGH IMPORTANCE as words, the manifest's event id, the thread parent, the message text, DELETED and EDITED markers with the earlier text, reactions, receipts and attachments with their hashes. Last, an attachments appendix. Every page's footer names the source file and the event count.

Characters the fonts cannot show

Transcripts are set in Noto Sans, with Space Mono for identifiers and hashes and Noto Emoji for emoji. Chinese, Japanese, Korean, Arabic, Hebrew and Indic text is shown as [U+XXXX] codes — set without shaping, it would render wrong rather than missing — and the first page says how many characters were shown that way. The original text is unchanged in the source file.

Questions the evidence rules ask

ExhibitPrep records what the export contains and how it was rendered. It does not collect messages, does not review them and does not decide what they establish. Before offering a transcript, the proponent typically has to answer questions like these; read the rule that applies in your court:

• Who sent it, and is the exhibit what it claims to be? Federal Rule of Evidence 901(a) requires evidence sufficient to support a finding that the item is what the proponent claims; 901(b)(4) allows distinctive characteristics and circumstances. A collection tool's process record, a witness who knows the exchange, and the account identifiers in the transcript are the usual materials. Rule 902(13) and (14) describe certified records of an electronic process and certified data copied from a device, each with its own notice requirement — those certifications come from the person who ran the process or made the copy, not from ExhibitPrep.
• Is the whole exchange there? Rule 106 lets an adverse party require that any other part of a statement that in fairness ought to be considered be introduced at the same time; the transcript's "rendered N of M events" line and the date range exist so that a slice is disclosed as a slice.
• What is each message offered for? A text whose source is settled can still be hearsay. Rule 801(d)(2) (an opposing party's statement), Rule 803 (present sense impression, state of mind, business records) and non-hearsay purposes (notice, effect on the listener) are the routes most often argued for messages.
• Is a rendered transcript an acceptable copy? Rules 1001–1003 treat an accurate printout of electronically stored information as an original; keep the RSMF file, whose hash the first page records.

ExhibitPrep formats documents. It does not provide legal advice, submit filings, or determine whether evidence is admissible or a filing meets court requirements. Some guidance has not been verified against current official sources. A citation supports only its stated claim and scope.

What this is not

ExhibitPrep records how a file was prepared and lets you confirm later that a file is byte-for-byte the one it produced. It does not authenticate the underlying document, prove who created it, or establish that it is what it purports to be — that remains the proponent’s burden under the applicable evidence rules. It is not an electronic signature, not a timestamp from any authority (times come from the preparing device’s own clock), and not a certification by ExhibitPrep. A matching hash shows the file has not changed since the record was made; it cannot show that the record itself was kept safely, so keep the record with the matter file.

See RSMF validation findings when a file will not open or the panel lists problems, Supported file types for every other format, and Checking a prepared file for the record that goes with the download.