Native production

What survives that imaging destroys

Everything that makes a file a working document rather than a picture of one:

• Formulas. An imaged spreadsheet shows the numbers. The native shows how they were calculated, which is frequently the disputed part.
• Tracked changes and comments. Who edited what, and what the earlier wording was.
• Application metadata. Author, creation and modification dates, and editing history embedded by the application.
• Structure. Hidden rows, additional sheets, speaker notes — content that exists in the file and does not appear on a rendered page at all.

For email specifically, the native carries the full transport header chain, which a rendered PDF does not print, and the attachments in their original bytes.

The trade

Natives are more useful and harder to control. A native file cannot carry a Bates number stamped on its face, so productions handle this by assigning a number to the document and delivering the native under that number as a filename — a placeholder image bearing the number is often produced alongside it.

Natives can also be altered after delivery, deliberately or by simply opening them, and they can carry live links and macros. Those are the risks imaging was adopted to eliminate.

The usual compromise

Most protocols land in the same place: image most things, produce spreadsheets and presentations natively, and deliver extracted text alongside. Where a document’s native form is specifically in dispute, it is produced natively on request even if the rest of the set is imaged.

Why it matters for attachments

An email attachment’s evidentiary value often depends on it being byte-identical to what was sent — that is what makes a hash comparison meaningful. Extracting an attachment without re-encoding it preserves that; rendering it into a PDF destroys it irreversibly. Which is why attachments should come out of a message as their original files whatever the eventual production format turns out to be. See converting EML with attachments.