Our team of eDiscovery specialists tackle your frequently asked questions and pressing "in the trenches" legal tech topics.
Tuesday's Tip #5 - Document Families (I got it from my Mama!):
The terms “parent” and “child” in eDiscovery are used to identify electronic documents and their attachments. Generally speaking, this is most common with emails – the email being the parent document and the child(ren) being the attachment(s) to the email. Both the email and attachments together are referred to as a “document family”, and just like human families, they can become more complex when emails contain additional emails with attachments (sometimes referred to as grandchildren documents).
In Summation, document families are identified using the fields ParentID and AttchIDs. However, in many newer review platforms, document families are identified using the BegAttach field or GroupID.
So, what’s the difference?
Many eDiscovery professionals today are either familiar with or are still using the legacy tool Summation. In Summation, parent emails only have the AttchIDs field populated, and it contains all the DocIDs of the corresponding attachment documents. For attachments, only the ParentID is populated and it contains the DocID of the parent email.
Here's an example: In the screenshot below, EML000007 is a parent document, and has two attachments (EML000008 and EML000009). You’ll note that the ParentID field is blank. Both EML000008 and EML000009 have a parent document (EML000007). For those two documents, you’ll note the AttachIDs field are blank.
When you’re working with updated software like Ipro or Relativity, families are identified by using only the parent’s Document Number. It is no longer necessary to have two separate fields for parent and attachments since the BegAttach/GroupID field indicates whether a document is a parent if both the Document Number and the BegAttach/GroupID field are the same.
In the screenshot below, GLO00000018 is a parent document and has three attachments. As a result, the BegAttach for the entire family is populated with “GLO000018”
What about broken families?
A broken family refers to documents where a member of the document family is being withheld from disclosure. For example, where a parent document might be produced but its attachment is not because it isn’t relevant, or where an attachment is produced but its parent is withheld for privilege.
There is no hard and fast rule whether to produce full or broken families; this is usually discussed and agreed upon by the parties prior to document exchange. In some cases, parties will request that productions are in full families because it ensures documents are not “missed” and that the integrity of the data is preserved. Other times, parties may agree to break up families because the data set is too large and too cumbersome to exchange. There are pros and cons to both scenarios and ultimately the decision comes down to legal counsel strategy.
Looking to better understand document families? We can help, contact us for assistance.
Don't forget, if you have a question for our team or a topic you'd like us to cover? Comment or tweet us using #ReDTuesdaysTip.
You may also be interested in...
Padded zeros or leading zeros are the zeros at the beginning of a number. This function can create an annoyance when adding zeros in front of your numbers is needed to manipulate data, whether you’re using it to sort documents or create new numbering.
Native files provide major advantages in a production since they contain additional information like metadata, allow for text-searching, are more compact in file size, and preserve the overall integrity of data.