Producing JSON in eDiscovery: Why Native Data Alone Isn’t Enough

For decades, electronic discovery revolved primarily around familiar documents: Microsoft Word files, Excel spreadsheets, PDFs, email messages, and their attachments. Although these formats created their own discovery challenges, lawyers generally understood what constituted a document and how it should appear when reviewed or produce.

Modern electronic communications have changed that equation. Slack, Microsoft Teams, Google Chat, messaging applications, cloud platforms, databases, artificial intelligence systems, and countless business applications increasingly store information as structured data rather than traditional documents. JSON—JavaScript Object Notation—has become one of the most common formats for exporting this information.

JSON is excellent for preserving structured electronic evidence. It is compact, machine-readable, and can maintain information that may disappear when data is converted to PDF or another static format.

What does a lawyer actually review and produce?

A raw JSON file may faithfully preserve the underlying information while being nearly incomprehensible to an attorney, witness, judge, or jury. The emerging solution is not to choose between native JSON and a readable document. Instead, sophisticated eDiscovery workflows as provided by Digital WarRoom increasingly preserve the original structured data while creating a human-readable representation.

What Is JSON?

JSON is a structured text format commonly used by software applications and APIs to exchange information.

A Slack message stored in JSON might conceptually resemble:

To software engineers, this is highly useful information. To an attorney conducting document review, however, it immediately raises questions.

1. Who is   U03ABCD12?
2. What was said before this message?
3. What does   thread_ts mean?
4. What "revised version" is being discussed?
5. Who gave the thumbs-up reactions?
6. Was a document attached to the conversation?
7. Was the message subsequently edited or deleted?

Those answers may exist elsewhere in the JSON export, but someone—or some software—must reconstruct them. That is the fundamental difference between preserving JSON and rendering JSON for discovery.

JSON Is Data, Not Necessarily a Document

Traditional eDiscovery processing generally starts with something recognizable as a document. An email has a sender, recipients, subject, body, date, and attachments. A Word document has pages or at least a logical document boundary. JSON does not necessarily have either. A JSON export may contain thousands or millions of interconnected objects. Information needed to understand one record may reside in several other records or files.

Consequently, converting JSON into a readable discovery document is not simply a matter of printing the JSON to PDF. A defensible eDiscovery renderer must interpret the data's structure and reconstruct the relationships that give the communication meaning.

Challenge #1: Determining the Document Boundary

Consider a Slack channel used continuously for three years. What constitutes a "document"? Is every individual message a separate document? Is an entire channel one enormous document? Should conversations be separated by day, week or month? Should threaded conversations remain together regardless of when replies occurred?

There is no universally correct answer.

Many eDiscovery systems divide chat communications into time-based segments. Twenty-four-hour conversations are common, although shorter periods may be appropriate for extremely active channels. Time-based rendering makes large datasets manageable, but it can also create artificial boundaries.

Suppose an employee writes at 11:55 p.m., "Should we disclose this to the customer?"

Another employee responds at 12:10 a.m., "No. Wait until we understand what happened."

A strict midnight cutoff could put those statements into separate documents. Even more complicated situations arise with threaded messaging systems. A response posted Wednesday may belong to a thread that began Monday. An effective renderer therefore needs to balance manageable review units against preservation of conversational context.

Challenge #2: Resolving User IDs

Modern messaging platforms frequently identify people internally using unique identifiers rather than names.

The JSON may say: "user": "U03ABCD12" while another JSON object establishes: U03ABCD12 = Jane Smith

A useful eDiscovery rendering should resolve those relationships automatically.  Instead of forcing an attorney to interpret system identifiers, the rendered communication should identify Jane Smith while preserving the original user ID as metadata when appropriate. This process becomes more complicated when employees change names, accounts are deactivated, guest users participate in conversations, or the same individual has multiple identities across systems. Preserving both the original identifier and its human-readable interpretation can therefore be important.

Challenge #3: Reconstructing Threads

Chronological order and conversational order are not necessarily the same thing. Modern collaboration applications allow users to respond directly to earlier messages. A reply posted hours or days later may logically belong underneath the original message rather than at its chronological location in the channel. Simply sorting JSON records by timestamp can therefore produce a misleading transcript.

A sophisticated rendering process should recognize:

Conversation → Message → Thread → Reply

and visually represent those relationships. The attorney reviewing the communication should be able to understand both when something happened and what message the participant was answering.

Challenge #4: Attachments May Be Separate

Attachments present another significant challenge. The JSON record may not contain the actual document that was exchanged. Instead, it may contain a file identifier, URL, or other pointer to a file stored elsewhere.

The discovery process may therefore need to:

1. identify the referenced attachment;
2. locate or collect the actual file;
3. preserve the file;
4. associate it with the appropriate message;
5. process the attachment for review; and
6. maintain the parent-child relationship during production.

This distinction is important.

Rendering the JSON is not necessarily the same thing as reconstructing the complete communication.

A beautifully formatted conversation that says "see attached" but does not preserve the attachment is incomplete from a discovery perspective. Attachments can also dramatically increase the size of a collection. A relatively small JSON export can reference gigabytes—or even hundreds of gigabytes—of files stored elsewhere.

Challenge #5: Emojis and Reactions May Be Evidence

A thumbs-up icon might seem trivial until it appears beneath a message saying: "Proceed with the transaction even though compliance hasn't approved it." If five executives respond with 👍, those reactions could potentially provide important context.

Modern messaging platforms allow users to communicate through thumbs-up icons, hearts, checkmarks, emojis, acknowledgments, and other reactions. A rendering process that extracts only the text of the messages can therefore eliminate potentially relevant information. The renderer should preserve not only the reaction itself but, where available and appropriate, who made the reaction and when.

Challenge #6: Edited and Deleted Messages

Messaging applications also challenge the traditional concept of a static document. A message may exist in several states:

Original message → Edited message → Second edit → Deleted message

Depending upon the application's retention settings and collection method, some or all of those states may remain available in the structured data. Which version should appear in the rendering? Displaying only the final text could conceal important information contained in an earlier version. Displaying every version without explanation could confuse reviewers. A well-designed eDiscovery workflow should preserve the available underlying information and clearly indicate edits, deletions, or other message events in the rendered representation.

Microsoft Teams Illustrates the Complexity

Microsoft Teams demonstrates why collaboration data cannot always be treated like email. Teams communications can involve chat messages, channel posts, replies, files, meeting transcripts, recordings, Loop components, reactions, and other objects. Those objects may also reside in different Microsoft 365 repositories. Messages may be associated with Exchange infrastructure, while shared documents may reside in OneDrive or SharePoint.

Microsoft Purview addresses part of this challenge by creating conversation transcripts that aggregate Teams messages and related information into human-readable HTML.

That illustrates an important development in eDiscovery: The "document" being reviewed may actually be a reconstructed representation assembled from multiple electronic objects.

Native Production Alone May Not Solve the Problem

Federal Rule of Civil Procedure 34 requires electronically stored information to be produced in the form in which it is ordinarily maintained or in another reasonably usable form. That concept becomes especially important with structured data. A producing party might argue that native JSON is the most faithful possible production because it preserves the original structure.

Technically, that may be true. Practically, however, handing opposing counsel millions of lines of JSON and saying "that's the native data" may create substantial usability problems. The reverse approach is equally problematic. Producing only PDFs may make the information easy to read while eliminating valuable structured metadata and relationships contained in the original JSON.

The better solution frequently involves preserving both.

An Emerging Three-Part Production Model

Recent eDiscovery commentary increasingly points toward a model involving three components:

1. Native structured data

Preserve the original JSON or other export format so that the underlying electronic evidence and metadata remain available.

2. Human-readable rendering

Create an HTML, PDF, RSMF, or comparable representation that allows attorneys to understand the conversation in context.

3. Associated attachments

Produce the files referenced by the messages while maintaining their relationship to the conversation. Traditional production metadata or load files can then connect these components within the review platform.

This approach recognizes an important principle: The rendering should be a view of the evidence—not a replacement for the evidence.

RSMF and Other Rendering Approaches

Relativity Short Message Format, or RSMF, represents one approach to solving this problem. Instead of pretending that short-message communications are email, RSMF provides a structured format designed for displaying conversations within an eDiscovery review environment. Other platforms use HTML transcripts, PDF conversation reports, or proprietary conversation viewers.

There is no requirement that every eDiscovery platform use the same technical solution. The important objective is preservation of context and relationships. Regardless of output format, a good rendering process should retain or accurately represent information such as:

1. message and event IDs;
2. conversation or channel IDs;
3. thread relationships;
4. sender identity;
5. participants;
6. timestamps and time zones;
7. message text;
8. reactions;
9. edits and deletions;
10. attachment relationships;
11. source application;
12. custodian information; and
13. links back to the original source data.

JSON Is About More Than Slack and Teams

The JSON production issue extends well beyond collaboration platforms. Modern litigation increasingly encounters structured information from AI applications, CRM systems, ticketing platforms, cloud applications, social media, audit systems, mobile applications, APIs, proprietary databases, and other enterprise software.

A production protocol written exclusively around email, Word, Excel, TIFF, and PDF may therefore be inadequate for modern ESI. Parties should consider structured data during the Rule 26(f) conference and address it explicitly in their ESI protocol before production begins.

DWR 12.0: A Better Approach to JSON Rendering

Digital WarRoom believes the goal should not simply be JSON-to-PDF conversion.

The more useful model is:

Native Preservation → Schema-Aware Interpretation → Conversation Reconstruction → Human-Readable Rendering

Digital WarRoom's approach to modern messaging data is designed around making complex electronic communications understandable to reviewers while maintaining the relationships that provide evidentiary context.

For messaging data, that can include converting communications into daily or otherwise logically organized conversation threads rendered in PDF or HTML, while preserving the information needed to understand participants, chronology, threads, reactions, attachments, and other relevant context.

A generic JSON viewer displays fields. An eDiscovery platform needs to understand relationships between those fields and render a readable and producible document. The DWR visual style is based on feedback received from many of our users. It has proven effective for presenting and exchanging information. We can adjust the style in future releases if needed. Below is an example of output generated from an JSON file containing embedded metadata.

Address JSON Before Discovery Begins

Lawyers do not need to become JSON programmers. They do, however, need to understand that producing structured data involves decisions that can materially affect how evidence is interpreted. Before collecting or producing JSON-based evidence, counsel should ask:

1. What constitutes the reviewable document?
2. How will conversations be divided?
3. How will threads be represented?
4. Will user IDs be translated into names?
5. How will attachments remain connected to messages?
6. Will reactions be displayed?
7. How will edits and deletions be handled?
8. Will the original JSON also be preserved or produced?

Those questions are much easier to resolve during an ESI conference than during a production dispute. The future of eDiscovery increasingly involves information that was never created as a traditional document. The challenge is therefore no longer simply converting electronic information into pages.

It is preserving context, relationships, and meaning while making complex electronic evidence reasonably usable for the people who ultimately have to review it.

For JSON and modern messaging data, the most defensible solution may often be the simplest conceptually:

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