Native file exports and productions — planning for success

Before we get into the topic of native file exports – does the term "native files" strike anyone else as a bit oxymoronic?

To me, "native" denotes original, first, new, beginning – while "files" suggests history, organization, hierarchy. Something "native" shouldn't have files yet! Just one more reason why this subject can be confusing.

As native file exports become more prevalent, we at Nextpoint are getting more questions from our users about how best to handle them. While each situation is unique, we'd like to point out some things to consider.

Understanding native file exports

Why would one want to produce or receive documents in their native format?

It’s important to keep in mind that native productions are not recommended for most document exchanges. When producing (or receiving) all natives, you risk sending over more metadata than necessary, which in some situations may amount to inadvertent disclosures of information (and the messy data clean up to follow).

Also importantly, native files cannot be Bates stamped on the physical face of the document. If a page of a native file gets separated from the body of the document, there is no easy way to map the page back to its original.

With all that said, here are a few instances where exchanging natives may be unavoidable.

You may want to produce and receive documents in their native format if they are specialized file types, such as CAD drawings, medical imagery or proprietary systems. Keeping these documents in their native form rather than having to convert the files to a new format for imaging can save a lot of time and money, and will ensure you maintain full usability in the document exchange.

It is also typical to provide native files for document types that do not image well in a standard 8.5 x 11″ “paper” size format, such as Excel spreadsheets, computer programming code, and PowerPoint slides with builds or animations.

There are certain situations where a native export makes particular sense. If you’re working with opposing counsel that are effectively out of your control – Department of Justice lawyers, for example – or if you’re provided with documents resulting from a subpoena – you might be in a position to receive native production files. These are situations where you can’t lock the other side into a particular production format.

Stamping with native file exports

If you know you have an upcoming native file export you need to execute, consider how the native files will be stamped.

Yep – this might not be at the top of your concerns, but you need to pay attention to it. Native productions can be stamped in two ways – at the document level or at the page level. Nextpoint requires stamping at the page level because it gives you a reference point as to the page count so if something’s off, you’ll know it immediately.

Redactions in a nfative file exports

How are responsive documents that contain redactions being handled in a native file export?

It goes without saying – you don’t want to provide your opposing counsel with a native document where you have made redactions. This can get tricky. Consider a responsive email that contains an attachment. If the redaction occurs in the email itself, that’s not a problem. You can produce a redacted image of the email along with the attachment in native form. But what if the redaction occurs in the attachment? You’ll need to produce an image of the attachment – AND an image of the original email.

These issues and more are covered in this article from the Nextpoint Help Center.

Bottom line

If you’ve got a native production coming up, give us a call. Our experts can help you make sure all the bases are covered before problems creep in down the road.

If you have any questions or comments about the role of native files in litigation, you can download our free eDiscovery guides.