Searching by Date? Be Very, Very Careful…

Migrated from eDJGroupInc.com. Author: Greg Buckles. Published: 2010-04-20 10:09:39  During a recent software testing engagement, I ran into an interesting issue with date based searches that could impact your discovery search results. The root of the issue is based in the different ways of representing communication attachments or other multipart items such as Sharepoint/wiki page attachments. In the dark ages of eDiscovery, our software was designed to simulate the myriad physical attachment levels of scanned paper documents. I am not ashamed to recall coding levels of staple, clip and binder groupings back in IPRO ver. 1.5. The system enabled an attorney to determine the exact hierarchical relationship of that individual document to all the others scanned from that box retrieved from Iron Mountain. Newcomers to our field cannot imagine the labor required to manually code in Author, Recipients, Subject and other fields that are now extracted from ESI during processing.But even in the dark ages of discovery, we knew that assigning a date to a ‘document’ was not always a straightforward proposition. Experienced paralegals managing a large review would give coders a date ‘trumping’ order for the known document types. For example, the contract signature date might beat out the draft date or effective date on a contract. These general rules would have to be constantly updated as new document types or attachment types surfaced. That works when you have a dedicated, experienced project manager actively looking at documents with the ability to succinctly describe handling options and potential consequences to counsel. The review or preview of 100,000 documents once required weeks of team labor and human eyes on every ‘page’. The crop of new ECA software and appliances like Clearwell, Stratify eVantage, Nuix and archiving platforms with discovery interfaces enables a single counsel to dig into the ESI without having to think about all these choices. That does not mean that the choices are not being made, it just means that the product development team made the default document handling decisions based on their concept of the broadest review scenario. Those of us who actually do discovery have learned the hard way that any case can break the rules based on the issues, parties and ESI profiles.There has always been room for argument on both sides of the ‘item granularity’ battle that dictates whether child attachments get separate records within a review platform or are consolidated into the parent record. In the example below, you can see that we have three potential dates associated with our email.On a simple level, you can see how the dates could break out in the record fields.Depending on how we decide to handle this, our search for terms in items from 2009 may or may not get a hit, even if they are located inside a document that was created inside the search date range. This same problem can occur within single items depending on the default date that the search acts on. As a sharp client pointed out, a mythical email to the CEO of Toyota containing a one year old accelerator problem analysis might be missed. Timing can be everything in a case and the context of an item may not always be the key date if you do not know it exists.I am not saying that every system should break emails, Sharepoint sites and wiki pages into hundreds of individual review items. That could explode the review effort and cost for a minimal benefit. Reviewing an attachment without knowing the context opens the doors to all kinds of misinterpretation, especially when it comes to privilege calls. The concern is that a simple search interface lends itself to potential incomplete or inappropriate search results if the user cannot easily understand what fields that date range covers. Many systems will create an artificial ‘Document Date’ based on rules that try to normalize multiple dates into the ‘best’ date. That is fine if the associate conducting the ECA drill really wants the earliest possible date between the various file and OS metadata fields. Most users do not get that deep in the software and just accept the defaults without questioning what they mean. They demand a single, simple search field without understanding the potential impact on their results. So when it comes to ESI, especially email attachments, it is worth the time to read the sparse documentation and then test for yourself what ‘Date’ really means on your system.