Parent-child email productions explained
One email with three attachments is four documents, not one. That single sentence is the whole concept, and nearly every attachment problem in a production comes from a workflow that quietly treated it as one.
The email is the parent. Each attachment is a child. They are produced as separate documents with separate Bates ranges, and the relationship between them has to be carried explicitly — because once the documents are separated into a review platform, nothing about a spreadsheet says which email transmitted it.
Why the relationship needs stating
Inside a mailbox the relationship is obvious: the attachment is on the message, and you can see it there. A production destroys that context by design. The documents are separated, numbered individually, and loaded into a system that sees a set of documents rather than a set of mailboxes.
At that point a spreadsheet is just a spreadsheet. Nothing inside it records which email carried it, who sent it, or when. A reviewer looking at the spreadsheet has no way to reach the covering message, and a reviewer looking at the message has no way to reach the file it transmitted — unless the production carries the relationship explicitly.
That is why parent-child fields exist, and why “produce the attachments too” is insufficient as an instruction.
The integrity problem, first
Before any of the structural questions, there is one that is irreversible.
An attachment’s evidentiary value frequently rests on it being byte-identical to what was sent. That is what makes a hash comparison meaningful, and it is what lets you demonstrate that the file was not altered in handling.
Two common conversion behaviours destroy it:
Dropping attachments. Some email-to-PDF tools convert the body and discard everything else. The output looks complete. It is not, and the omission is invisible in the result.
Flattening attachments into the body PDF. Others render the attachment into pages appended to the message. This is worse than dropping them, because it looks thorough. Re-encoding produces a file with a different hash, and it flattens live content — a spreadsheet’s formulas, a document’s tracked changes — that may itself be discoverable.
The correct behaviour is extraction: the attachment written out in its original bytes as its original file type, never re-encoded, never watermarked. See converting EML with attachments.
Structure at small-production scale
For a production going out as PDFs rather than into a platform, the folder structure carries the relationship adequately:
JONES_001_message_0001.pdf
JONES_001_message_0001_attachments/
Q3 forecast.xlsx
signed change order.pdf
JONES_001_message_0002.pdf
Combined with adjacent Bates ranges — the message, then its attachments, then the next message — a reader can reconstruct what belonged to what. For a few hundred documents going to opposing counsel who will read them, this is enough.
Structure at platform scale
Once the production is being ingested, folder structure means nothing. The load file carries the relationship in explicit fields, conventionally something like:
- BEGBATES / ENDBATES — the document’s own range.
- BEGATTACH / ENDATTACH — the range spanning the whole family, parent plus all children, identical on every member of the family.
- PARENTID or ATTACHIDS — direct pointers between parent and children.
The exact field names and structure are specified by the protocol and vary. What is universal is that these values are derived from the original messages, not from the images. This is the concrete reason natives are retained through an imaged production: the metadata that describes the images comes out of the files the images were made from.
Imaged, native, or both
Whether attachments are imaged alongside the parent or produced natively is a protocol question, and the usual answer is “it depends on the file type”.
Imaged with the parent — documents that render sensibly as pages, so the receiving party sees the family as a continuous set of stamped images.
Produced natively — spreadsheets above all, because an imaged spreadsheet loses its formulas, loses hidden rows and additional sheets, and typically runs off the page into unreadable fragments. Presentations for similar reasons.
Both — some protocols require a placeholder image bearing the Bates number in the image set, with the native delivered separately under that number. This keeps the image set continuous while preserving the working file.
Settle the carve-outs at meet-and-confer. Discovering after imaging that spreadsheets should have gone native means re-running the family and re-stamping it.
Deduplication without losing the links
Deduplication is where parent-child relationships get accidentally destroyed.
The same attachment travels on many messages. Deduplicating at the document level means producing one copy of that spreadsheet rather than twenty — a large and legitimate saving. But the twenty relationships are themselves information: they show who received the document and when.
The standard handling is to deduplicate the document while preserving every family link, so the produced set contains one spreadsheet with a record of all twenty parents. A deduplication that keeps one parent and discards the other nineteen relationships has removed evidence, and it does it silently.
At small-firm scale, where deduplication is manual or absent, the practical version is simpler: do not delete a message just because you have already seen its attachment.
Withholding one but not the other
A privileged attachment on a non-privileged cover message is routine. The handling is straightforward and worth stating because it is where families break:
Produce the parent. Withhold the attachment. Log the attachment in the privilege log by its own Bates number, with its own basis. The family record still shows that the parent had a child; the child is accounted for as withheld rather than as absent.
What causes disputes is a family where a child simply is not there and nothing explains it. That reads as an incomplete production whether or not it was one, and the fix — a log entry — costs a line.
Doing it in EML Exhibit
-
Extract attachments as their original files
Attachments come out of the message in their original bytes, written as separate files. Never rendered into the body PDF — re-encoding changes the file and destroys the hash that made it verifiable.
-
Keep the association visible in the output
One folder per message holding its attachments, sitting beside the message PDF. On a small production, this folder structure is the parent-child relationship.
-
Number parent and children in adjacent ranges
Parent message first, then its attachments, then the next message. Adjacency is what lets a reader reconstruct the relationship from the numbers alone.
-
Decide what gets imaged and what goes native
Spreadsheets and presentations are conventionally produced natively because imaging destroys formulas and speaker notes. Confirm which types the protocol carves out before imaging anything.
-
Express the relationship in the load file
On a platform production, adjacency is not enough. The load file carries explicit parent-child fields, and they are built from the original messages rather than from the images.
Can we produce the parent without the attachment, or the other way round?
Producing a message while withholding an attachment is normal where the attachment is privileged and the cover message is not — the attachment is logged separately. What causes trouble is producing a parent and simply omitting a non-privileged attachment, which reads as an incomplete production. If a document is withheld, log it; do not let it silently disappear.
Is an email attached to another email a parent-child relationship?
Yes, and it nests. A forwarded message carried as an attachment is a child of the forwarding message, and anything attached to that inner message is a child of it. Most protocols flatten this to one level in the load file. EML Exhibit extracts an attached message as the file it is; it does not recursively convert it into its own PDF.
What if the same attachment appears on twenty emails?
That is what deduplication handles, and it is a decision rather than a given. Most protocols deduplicate at the document level while preserving every parent-child link, so one copy of the spreadsheet is produced but the record still shows all twenty messages that carried it. Deduplicating away the relationships is a common and consequential mistake.
Why does flattening an attachment into the PDF matter so much?
Because it changes the file. Rendering a document into PDF pages re-encodes the content, so the result has a different hash from the original. If anyone later asks whether the attachment you produced is the attachment that was sent, a hash match is the clean answer, and re-encoding throws that answer away permanently. See native production.
Does EML Exhibit build the parent-child fields?
No. It preserves the relationship structurally — attachments extracted
byte-for-byte into a folder tied to their message — but the
BEGATTACH / ENDATTACH style fields a review platform expects are
built during the load-file step, from the original .eml files.