You Can't Have Your Cake and Eat It, Too!
Saturday, March 30, 2013
In many cases, an entire document family must be produced if only one of the documents in that family contains responsive material. With that fact in mind in many reviews counsel asks that coding be consistent throughout the family. In the same vein, counsel also wants to see identical documents coded consistently.
Most of the current review platforms allow for propagation of coding to duplicates, families or both. When families should be coded consistently, then the family propagation feature is used. When duplicates should be coded consistently, the duplicate propagation feature is used. Occasionally, counsel wants consistency for duplicates and families and asks that both propagation features be used. It is at that point the train starts running off the rails.
When coding propagates to both duplicates and families, it causes coding changes that cascade throughout a database. Consider an obviously non-responsive spreadsheet that has 50 duplicates in 50 non-identical families. Assume that the first 49 families are properly coded as non-responsive because all family members are non-responsive. However, in the 50th family there is a responsive Powerpoint presentation. The responsiveness coding from the Powerpoint propagates to the spreadsheet. When the reviewer arrives at the spreadsheet it is already coded responsive because of the Powerpoint. When the reviewer and saves the coding, the responsiveness coding propagates to the spreadsheets in the 49 previously not responsive families. This would potentially result in the production of 49 wholly non-responsive families. The problem becomes worse when both privilege and responsiveness coding propagate to families and duplicate.
Using coding propagation for families and duplicates is like trying to have your cake and eat it too. It sounds like a great idea but is not practical.