How is a Teams conversation produced in a "reasonably usable form"?

Modern electronic communications have changed what a "document" means in discovery.

Slack, Microsoft Teams, Google Chat, messaging applications, AI systems, and cloud platforms increasingly store communications as structured data rather than traditional documents. JSON and Relativity Short Message Format (RSMF) can preserve this information remarkably well—but neither necessarily provides a practical disclosure format for lawyers

This raises an important question under Federal Rule of Civil Procedure 34: When is structured electronic data produced in a "reasonably usable form"?

FRCP 34(b)(2)(E) provides important guidance for electronically stored information ("ESI"). Unless otherwise stipulated or ordered:

A party must produce documents as they are kept in the usual course of business or organize and label them to correspond to the categories in the request.

For ESI specifically, Rule 34(b)(2)(E)(ii) provides that: "If a request does not specify a form for producing electronically stored information, a party must produce it in a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms."

Rule 34 also provides that a party need not produce the same ESI in more than one form.

Those principles become complicated when the "native" information consists of JSON, databases, Slack exports, Teams conversations, or RSMF files.

A production can preserve the native data perfectly yet still present significant usability problems.

The Digital WarRoom eDiscovery solution

DWR now supports reading the internal metadata expressed as JSON with RSMF files. DWR will now show all participants and their associated “display” names, include inline images, and correctly formatted timestamps in a running chat-style presentation. The output format is HTML for maximum portability. RSMF messages without supporting metadata will continue to be displayed as “email” messages with attachments -- exactly as they do today.

The visual style is based on feedback received from some of our users. While it may not suit everyone's preferences or tastes, it has proven effective for information presentation and exchange. The style can be adjusted in future releases if necessary. Below is an example of output generated from an RSMF file containing embedded metadata.

The JSON Problem

JSON is an excellent machine-readable format. A Slack message might resemble:

{

"user":"U03ABCD12",

"ts":"1719258422.419299",

"thread_ts":"1719258001.112233",

"text":"I agree. Let's use the revised version."

}

The information is preserved, but an attorney immediately needs additional context.

Who is U03ABCD12?

What message is being answered?

What was in the revised version?

Were there reactions or attachments?

Was the message subsequently edited?

Producing thousands or millions of JSON records may therefore preserve the evidence without necessarily making it readily understandable.

Rendering solves this problem by reconstructing relationships among users, messages, threads, timestamps, reactions, edits, and attachments.

RSMF Solves One Problem—and Creates Another

RSMF was developed specifically to normalize short-message communications for eDiscovery. Instead of treating every Slack or Teams message as an independent document, RSMF can preserve conversations, participants, messages, reactions, attachments, and other information within a structured container.

That makes RSMF extremely useful for review. But production presents another question:

How should an RSMF conversation be disclosed to someone who may not have the same review platform?

RSMF generally contains a structured manifest describing individual messages and events. A specialized viewer interprets that information and reconstructs the conversation.

Consequently:

RSMF → PDF

is not equivalent to:

Word → PDF.

It is closer to:

Structured Data → Interpret Relationships → Reconstruct Conversation → Render Conversation

That distinction matters when determining whether a production is reasonably usable under FRCP 34.

Rendering Should Preserve Context

A defensible JSON or RSMF rendering process should preserve or accurately represent:

• participants;
• timestamps;
• conversation and thread relationships;
• message text;
• reactions;
• edits and deletions where available;
• attachment relationships; and
• identifiers linking the rendering to the underlying source data.

The objective should not simply be to make structured information printable.

It should be to make it understandable without changing its meaning.

Digital WarRoom's Approach

Digital WarRoom approaches messaging data as a reconstruction problem rather than simply a file-conversion problem.

The workflow can be summarized as:

Native Preservation → Structured Data Interpretation → Conversation Reconstruction → Human-Readable Rendering

JSON and RSMF communications can be converted into logically organized conversation threads and rendered in PDF or HTML while maintaining the information necessary to understand participants, chronology, threads, reactions, attachments, and other relevant context.

This provides a practical bridge between the structured data used by modern communication platforms and the reasonably usable production contemplated by FRCP 34(b)(2)(E).

The distinction is important:

A generic viewer displays data. An eDiscovery renderer reconstructs the conversation.

FRCP 34(b)(1)(C) expressly permits a requesting party to specify the form or forms in which ESI is to be produced, while Rule 34(b)(2)(D) requires the responding party to state any objection to the requested form.

That makes JSON, RSMF, and collaboration data appropriate topics for the Rule 26(f) conference and ESI protocol.

Before production begins, parties should consider:

• whether native JSON or RSMF will be produced;
• whether a human-readable rendering will accompany it;
• how conversations will be divided;
• how threads will be maintained;
• how attachments will be associated;
• whether reactions and edits will appear; and
• what metadata will connect rendered documents to their structured sources.

Resolving these questions before processing and production can reduce later disputes over whether technically complete data was actually produced in a reasonably usable form.

Modern eDiscovery increasingly involves information that was never created as a traditional document.

The challenge is no longer simply turning electronic information into pages.

It is preserving content, context, relationships, and meaning while providing ESI in a form lawyers can actually use.

Preserve the data. Reconstruct the context. Render it for humans.