Native Format Production in E-Discovery: Metadata, Load Files, and Redaction

Native format production in e-discovery means handing over electronically stored information in the original file type the software created, so spreadsheets arrive as working .xlsx files, presentations as .pptx, and emails as .msg or .eml, with formulas, hidden content, and metadata intact. Federal Rule of Civil Procedure 34(b)(2)(E)(ii) is the baseline: when a discovery request doesn’t specify a format, the producing party must deliver ESI in the form it is ordinarily maintained or in a reasonably usable form.1Legal Information Institute. Federal Rules of Civil Procedure Rule 34 That one rule drives nearly every technical decision that follows, from which files stay native to how the load file is built to how the production is verified on arrival.

Native Files Versus Image Production

A native file is the original document as the software that created it would open it. Produce it natively and the recipient gets a working copy. They can sort columns in a spreadsheet, trace formula dependencies, expand embedded charts, and click through presentation slides exactly as the author did.

The alternative is image production, where files are converted to TIFF images or PDFs. That approach works for ordinary correspondence and simple word-processing documents, where the content is what matters and the layout is straightforward. It falls apart when the file was never designed to live on a printed page. Converting a 47-tab spreadsheet with linked formulas into a stack of page-sized images destroys the very thing that makes the document useful as evidence, and courts routinely reject image-only productions of complex files for that reason.1Legal Information Institute. Federal Rules of Civil Procedure Rule 34

Rule 34(b)(2)(E)(iii) also blocks double-dipping. A party doesn’t have to produce the same ESI in more than one format.1Legal Information Institute. Federal Rules of Civil Procedure Rule 34 If you agree to native production for spreadsheets, you can’t later demand TIFFs of the same files. Decide what you actually need up front.

Which File Types Call for Native Production

Not every document needs to stay native. The EDRM’s production guidance frames the decision around whether the file was created for printing. Word-processing documents and simple PDFs usually convert cleanly to images. Files that were never designed to fit an 8.5-by-11-inch page lose critical information when forced into that box.2EDRM. Production Guide

The usual candidates for native production:

  • Spreadsheets. Formulas, hidden rows, linked tabs, and pivot tables all vanish in an image conversion. Excel files are the most commonly litigated native-format issue.
  • Databases. Small databases and structured data compilations are often only intelligible in their original format, where records can be queried and sorted.
  • Presentations. Speaker notes, animations, and embedded media don’t survive conversion to flat images.
  • Audio and video. These have no meaningful image equivalent. Native production is the only option.
  • Email. Producing email as images strips threading, header data, and attachment relationships. Many protocols call for .msg or .eml with an accompanying load file.

When page-level stamps like Bates numbers, confidentiality designations, or redactions are required, native production alone doesn’t work because there’s no page to stamp. The protocol often calls for a hybrid: the native file is produced alongside a stamped image version, with the load file tying the two together.2EDRM. Production Guide

The Metadata That Rides Along

Metadata is data about the data: timestamps, authorship, edit history, file paths. It lives inside or alongside every digital file. Native production preserves this information automatically because it is part of the file itself. Image-only productions strip most of it unless the producing party separately extracts and loads metadata into the review platform.

Two categories matter. System metadata comes from the operating system: file size, creation date, last-modified date, file path, and extension. Application metadata comes from the software that created the file: the author field in a Word document, tracked changes, hidden comments, speaker notes in a presentation, and the formulas sitting behind displayed values in a spreadsheet.

This layer is often more revealing than the visible content. An author field that doesn’t match the person who claims to have drafted a memo, or a last-modified timestamp that postdates the date a document was supposedly finalized, can reshape an entire case theory. Extracting metadata requires forensic tools that read the file’s internal structure without altering it. Even opening a file in its native application can overwrite the last-accessed timestamp.

Email Headers

Email carries a particularly rich metadata layer in its headers. Beyond the visible From, To, and Date fields, the technical headers record the message’s journey from server to server. Each relay adds a Received header showing which server handled the message, when it arrived, and what protocol was used. Reading these entries bottom to top reconstructs the full transmission path.

The Message-ID header contains a unique identifier generated by the sending server, and the domain in that identifier can reveal which email service actually dispatched the message. That matters when a party claims a message was sent from one system but the headers show it came from somewhere else. State in your production specification whether full headers are included, because stripped headers leave you with just the display fields.

Sanctions for Lost Metadata

Failing to preserve metadata is not a minor procedural problem. Rule 37(e) provides a two-tier framework. If a party failed to take reasonable steps to preserve information and another party is prejudiced by the loss, the court can order measures to cure that prejudice.3Legal Information Institute. Federal Rules of Civil Procedure Rule 37 – Failure to Make Disclosures or to Cooperate in Discovery; Sanctions Those measures are capped at what is necessary to fix the harm.

The severe sanctions are reserved for intentional conduct. Only when a court finds a party acted with the intent to deprive another party of the information’s use can it presume the lost information was unfavorable, instruct the jury to draw that inference, or dismiss the case or enter a default judgment.3Legal Information Institute. Federal Rules of Civil Procedure Rule 37 – Failure to Make Disclosures or to Cooperate in Discovery; Sanctions Negligent loss gets remedial measures. Intentional spoliation can end the case.

Settling the Format Before Collection Starts

Before anyone exports a single file, the parties are required to talk about how ESI will be handled. Rule 26(f) mandates a conference where both sides discuss preservation and develop a discovery plan that addresses the forms in which ESI should be produced.4Legal Information Institute. Rule 26 – Duty to Disclose; General Provisions Governing Discovery That is where you decide whether spreadsheets come over as native Excel or flattened images, whether email headers are included, and which metadata fields the load file will contain.

Skipping the detail at this stage is where most production disputes start. Walk away without a written protocol and you’ll be arguing about formatting three months later when the deadline is a week out. Each side should come to the conference with a concrete proposal listing preferred file formats, metadata fields, Bates numbering conventions, and how privilege documents will be logged. The goal is a signed ESI protocol, sometimes called a production specification, that eliminates ambiguity before collection begins.

Unresolved issues go to the court at the earliest opportunity. Judges increasingly expect cooperation on ESI matters, and showing up without having made a genuine effort to negotiate will not play well. Many districts have standing ESI orders or model protocols that fill the gaps when the parties’ agreement is silent.

What the Production Specification Should Cover

The specification is the technical contract between the parties. It should address:

  • Metadata fields. List every field the load file will include. At minimum, expect custodian, file path, author, creation date, last-modified date, email-specific fields, file size, file extension, and hash value. Spell them out.
  • Bates numbering. Define the prefix, number of digits, and separator. Use leading zeros and avoid spaces to prevent sorting problems. A format like DEF-00000001 is standard.
  • Native handling. State which file types are produced natively, how redacted natives are treated, and whether a corresponding image set is required.
  • Text files. Specify whether full text is delivered as separate .txt files keyed to Bates numbers, embedded in the load file, or both. For native files, text should be software-extracted rather than generated through OCR, since extracted text is an exact copy of the file’s content while OCR introduces recognition errors.
  • File naming. Individual production files should be named by Bates number with the appropriate extension, not by the original file name. The original name lives in the metadata.
  • Delivery. Specify the medium, encryption requirements, and folder structure.

Templates are available through local court standing orders and industry organizations like the EDRM and The Sedona Conference. Starting from a template reduces the chance of missing a critical field.

Load Files: What Connects the Pieces

A production set without a load file is a folder full of files with no context. The load file is what connects each document to its metadata, its Bates range, and its position in the review platform’s database.

Two file types do most of the work. A .DAT file (sometimes a .CSV) is a delimited text file where each row represents a document and each column holds a metadata field. The industry-standard .DAT format uses unusual delimiter characters, the pilcrow (¶) to separate fields and the thorn (þ) to qualify text, specifically because those characters almost never appear in document content, which prevents the data from breaking during import. A typical header row includes beginning and ending Bates numbers, custodian, sender, recipients, subject, dates, file name, hash value, and a native file link.

An .OPT file handles the image side. It is a comma-delimited file with one row per page, mapping each page-level image to its Bates number and file path. A flag in the fourth field marks the first page of each new document so the review platform knows where one document ends and the next begins. The Federal Trade Commission’s production guide specifies this structure, and it has become the de facto standard across federal practice.5Federal Trade Commission. Bureau of Competition Production Guide

When native files are included alongside images, the .DAT file contains a NATIVELINK field with the relative path pointing to the native document on the production media.5Federal Trade Commission. Bureau of Competition Production Guide Getting those paths wrong is one of the most common production errors. The receiving platform can’t locate files that are sitting right there on the drive.

Redaction Is the Hard Problem

Redaction is where native production gets genuinely difficult. Blacking out a paragraph in a TIFF is straightforward because the underlying data is just pixels. Redacting a cell in a live Excel spreadsheet is a different problem, because formulas in other cells may depend on the redacted value. Remove one number and the chain reaction ripples through the workbook, changing totals and breaking references in ways that make the file unreliable.6EDRM. The Reality of Native Format Production and Redaction

No widely accepted commercial tool handles native spreadsheet redaction automatically. The work is typically done by hand inside the application, deleting rows or columns while trying to preserve the document’s overall integrity. It is slow and risky. One common workaround is producing unredacted spreadsheets natively while converting redacted ones to images, with the native available for in-camera review if needed.

If the production specification doesn’t address how redacted native files will be handled, you are setting up a dispute that one paragraph in the ESI protocol would have prevented. Spell out whether redacted spreadsheets go out as images, as modified natives, or in some hybrid arrangement before anyone starts processing.

Deduplication Before Review

Before documents reach the review platform, the raw data goes through processing: extraction, deduplication, indexing, and text generation. Deduplication alone can dramatically reduce the volume that needs review.

Global deduplication removes all duplicate files across the entire collection, regardless of which custodian held them. Custodian-level deduplication removes duplicates only within each person’s data set, preserving the fact that multiple people had the same document. Custodian-level dedup keeps the evidence trail showing who had what. Global dedup cuts volume more aggressively. The ESI protocol should specify which method applies.

Hash values drive the process. Each file gets a unique digital fingerprint from a hash algorithm. Identical hashes mean identical files, and the processing platform uses those values to flag and suppress copies. The same values later serve as integrity checks on delivery.

Protecting Privilege With a 502(d) Order

Large-scale native productions make accidental privilege disclosures nearly inevitable. When you are producing hundreds of thousands of files, some privileged documents will slip through review. Federal Rule of Evidence 502(d) exists for that reality. A court can order that any disclosure connected to the litigation, inadvertent or otherwise, does not waive the attorney-client privilege or work-product protection, and that protection extends to every other federal or state proceeding.7Legal Information Institute. Rule 502 – Attorney-Client Privilege and Work Product; Limitations on Waiver

Entering a 502(d) order early is one of the single most protective steps you can take. Without one, you fall back on Rule 502(b), which only prevents waiver if the disclosure was inadvertent, you took reasonable steps to prevent it, and you promptly tried to fix the error after discovering it.7Legal Information Institute. Rule 502 – Attorney-Client Privilege and Work Product; Limitations on Waiver That “reasonable steps” test invites expensive satellite litigation about whether your review was thorough enough. A 502(d) order avoids the fight entirely.

Even with a clawback order, you still need a privilege log for documents you are intentionally withholding. The log should identify the document type, author, date, recipients, and the specific privilege or protection claimed. Redaction is often preferable to full withholding because the face of the email or memo provides most of what the other side needs to evaluate the claim. Privilege log formatting varies across jurisdictions and judges, so negotiate it as part of the ESI protocol.

Cost, Proportionality, and Pushing Back

Native production is more cost-effective than image production in many cases because it eliminates the conversion step. But processing, hosting, and reviewing large volumes is never cheap. When costs become disproportionate to the stakes, Rule 26 provides two safety valves.

The proportionality requirement built into Rule 26(b)(1) limits discovery to what is proportional to the needs of the case. Courts weigh the importance of the issues, the amount in controversy, each party’s relative access to information, the parties’ resources, the importance of the discovery to resolving the case, and whether the burden outweighs the likely benefit.4Legal Information Institute. Rule 26 – Duty to Disclose; General Provisions Governing Discovery

Rule 26(b)(2)(B) also provides that a party doesn’t have to produce ESI from sources that aren’t reasonably accessible because of undue burden or cost. Think disaster recovery tapes or decommissioned legacy systems. The party resisting production bears the burden of showing inaccessibility, but if the requesting party shows good cause, the court can still order the production and impose conditions like cost-shifting.4Legal Information Institute. Rule 26 – Duty to Disclose; General Provisions Governing Discovery If your requests are broad and the data lives on backup tapes that will cost six figures to restore, expect to share in that expense.

Delivery and Verification

Delivery usually happens through secure file transfer or encrypted cloud-sharing links. Very large data sets sometimes ship on encrypted hard drives by tracked courier, though that is becoming less common as transfer speeds improve.

The receiving party’s first job is verification, not review. Each file carries a hash value, a digital fingerprint generated by a cryptographic algorithm like SHA-256. Comparing the hash values in the load file against freshly computed hashes of the received files confirms that nothing was corrupted or altered in transit. If every hash matches, the files are clean and ready for ingestion. If any don’t, flag them immediately and request replacements before touching the rest of the data.

Ingestion populates the review database with documents, metadata, and full text, all linked through the load file’s structure. A well-built load file makes ingestion seamless. A poorly built one means broken native links, mismatched Bates numbers, or metadata in the wrong fields, problems that can take days to diagnose and fix.

Delivery receipts and transfer logs document that the production was completed by the court-ordered deadline. Keep those records. If the other side later claims they never received certain documents, your delivery log with confirmed transfer timestamps is the proof that the files left your control on time and intact. The chain of custody from collection through processing to final delivery is what makes a production defensible if it is ever challenged.