Production Formats in a Nutshell (from 6/11/2016)

There is some confusion in the profession about how productions should be formatted. I propose to provide a simplified outline to introduce novices to the subject, and to enunciate one basic rule: Production format controversy is best avoided, if possible, by including a meaningful discussion as early as possible in the litigation. Talking about production formats after disclosure is like agreeing on a course correction after your ship has sunk.


The traditional approach mirrors the paper-based approach that is still enshrined in most court rules. You produce COPIES of the documents themselves, either hard copies or soft copies (e.g. TIFF or PDF image files, either one file per page or one file per document). If the original source documents were electronic, they are converted to copies by printing (to a printer, or to a file). If the original source documents are paper they are photocopied (or scanned and printed, which amounts to the same thing.)

Unless the parties agree, providing copies alone – either in hard copy or soft copy – does not satisfy the rules. (The leading case in Ontario is Wilson v. Servier Canada Inc., 2002 CanLII 3615 (ON SC), and a more recent example is Gamble v. MGI Securities, 2011 ONSC 2705(CanLII). Together with the copies, parties are supposed to serve a detailed list of the documents produced. Traditionally this list was typed or prepared as a word processed document. Each document is described in the list and numbered, like so:

Tab 31. Email from Green to Brown re contract negotiations dated February 12, 2006.
Tab 32. Signed service contract between Green and Brown, March 1, 2006.
Tab 33. Monthly TD bank statements for account #43-0888765, June-December, 2008.

The parties must have some way of using the numbered list to reference the copies. In a paper production, the copies are usually placed in a binder organized with numbered tabs, each tab corresponding to the serial number on the document list. So a complete paper production must have the following elements:

1. Copies of each document identified with a serial document number (usually indicated on a tab)
2. A numbered list of the documents where each number corresponds to the proper binder tab.

Where the productions are made by way of soft copies, the “tab” approach doesn’t work because there is no physical binder. Instead, the image files can be saved with file names that match a serial number on the list, for example:

Production #31. Letter from Green to Brown re contract negotiations dated February 12, 2006. (The corresponding image file could be named “00000031.pdf”)

Manually referring to a list and then browsing through a collection of named image files is slow and clumsy, and completely unnecessary, because if the documents are provided in digital form, and the list is itself in word processing format, we can use the simple concept of hypertext linking to make it very easy for the reader to browse through the list of documents and view the corresponding image by clicking.

An entry in the list of documents would then look like this:

31. Letter from Green to Brown re contract negotiations dated February 12, 2006. Click here: n:\documents\clients\green\productions\00000031.pdf.

Note that the actual file path (i.e. location of the file on a hard drive) is variable depending on where the produced files are saved. Note as well, that there are may be performance limits to how many files can exist in a single folder, so in many production sets, the soft copies are arranged in folders and subfolders.

So a complete production of soft copies must have the following elements:

1. Image files of the documents, each one named with a unique serial number.
2. A soft copy list of the document image files with hypertext links from each document reference to the corresponding path (location) and filename for each image file representing the document.

Remember I mentioned that the location (path) of each file is variable? You saved your productions on your C:\ drive, and I copied them to my F:\ drive. Your hypertext links pointing to C:\ won’t work for me.

To make it easy to modify these links, the standard approach  is to provide two related files: one list of documents with a document reference number, and another list linking the document reference number with the corresponding file image name(s) and location. These are called LOAD FILES. While preparing two such files sounds like more work than preparing one, it is actually easier because this is the way litigation support software does it by default.So for a complete production between parties using litigation support software rather than a word processor, a complete production requires:

1. Image files saved in a folder with unique serial number filenames
2. A structured file (like a spreadsheet) listing the documents with reference to corresponding image file references
3. Another structured file linking each image reference to the location and file name of the corresponding file.

For example:

Document Image file: 


First structured file:

This file links the key elements of the document (author, title, recipient, date), to the unique document production number.

PRODNO#: 00000031
Type: Email
From: Green
To: Brown
Re: Contract Negotiations
Date: 2006-02-12

Second structured file:

This file links the document production number to the path and filename of the document image file.

PRODNO#: 00000031
FILEPATH: \productions\green\0001\
NAME: 00000031.pdf


The traditional approach described above, though it progresses to the exchange of soft copies and structured files (no paper), is still quite oriented to the paper-based system from which it originates. Most productions today do not involve paper, and producing hard copies or images of emails, spreadsheets and text files is not always a good practice. For example, it ignores the sometimes crucial metadata that must be preserved and sometimes produced. It also can add cost to the processing of data, if every email page and attachment must be “printed” – even if printed digitally. A digital image is not searchable unless it is subject to further processing, which again adds cost and time to the whole discovery process. Why take a searchable file, convert it to an image, and then convert the image back to a searchable file? There may be times when that approach works, but the trend is now towards “native file production.”

Native file production, like all things digital, entirely changes the production process. First, native files already have filenames, and those filenames are important, so they should not be renamed with a serial number. Instead of working with a file called “00000031.pdf”, we now have files with such names as “LB_contract_rev03.docx”, and files with the same name may exist in different folders on the custodian’s hard drive.

As the volume of producible documents increases, especially emails, the concept of preparing a traditional list is daunting. Who can afford to type up a list of every email? Manually preparing a list is not necessary because emails have their own “metadata” or header information. While it may not look pretty, it is available for free. So the structured file listing emails might look like this:

PRODNO#: 00000031
RE: FW:Available for lunch today?
DATE SENT: 2/12/2006 10:05:36 GMT-5
DATE RECEIVED: 2/12/2006 10:23:15 GMT-5

Note that the email header provides more information than is normally entered manually. Note also, that the MSG file format has been extracted from an Outlook container file. An MSG file contains the email message, metadata about the message, and all attachments. (In this post I am not including a discussion of how to handle attachments, to keep things a little simpler.)

The structured file linking the document list to the native files would look like this:

PRODNO#: 00000031
FILE PATH: \productions\green\email\inbox\FW:Available for lunch today?.msg

So a complete production in native format would include these elements:

1. Copies of the native files in their originally mapped folders (green\email\inbox\)
2. A structured file containing the relevant metadata extracted from the emails, with a unique document production number
3. A structured file linking the unique document production number to the filename and folder location (path) of the native file.

Leave a Reply

Your email address will not be published. Required fields are marked *