I’ve encountered a number of reviews recently where combining incompatible tags and enforcing (sometimes with automatic propagation) family coding resulted in mass confusion at production time.

For example, responsiveness and privilege are separate logical concepts. Faced with a single-choice field containing Responsive, Non- Responsive, Privileged, Redact, and Unreadable, reviewers are uncertain how to code a non-responsive but privileged document. Should the more important call prevail?  Which call is more important?

In one recent review, that’s exactly what occurred when several associates began second level review. They wanted to make absolutely certain that thousands of privileged (but irrelevant) documents never saw the light of day and, in error, changed a number of non-responsive documents to privileged, pushing them into a workflow that ultimately generated unnecessary work for the priv log team.

Instead of mixing concepts, I prefer to keep responsiveness and privilege as logically separate concepts and require accurate coding for all tags on every document, based on the content and context of the actual document.

Most modern review platforms don’t require family coding in order to properly produce full families. Instead, they are quite capable of allowing each document to be coded individually for responsiveness, privilege, issues and any other coding needs while still making it possible to pull full families into a production set (or any other arbitrary search). I build my searches for doing so like this:

  • Admin 1: All Privileged plus Family
  • Admin 2: All Redaction plus Family
  • Admin 3: All Special Withhold plus Family
  • Production 1: All Responsive plus Family, NOT in Admin 1, 2 or 3

The resulting set will contain only those documents where at least one document is responsive, but no documents are in special categories that should be withheld. I also gain the benefit of having easy access to searches that always contain special document categories for my case, so I can quickly exclude, for instance, the privileged documents from any other search simply by adding an additional criteria to my search.

Note, though, that simply searching for Not Privileged won’t have the same result, since you’re not guaranteed to have a privileged tag in every family member. The safest way is to exclude a search that contains all the privileged documents AND their family members.

By keeping coding on a document level, determining an individual document’s importance is greatly simplified. Now, when searching for a document with a specific tag, you’re not forced to also see every family member. This can greatly improve quality, as you can search for terms on documents with (or without) specific tags, ensuring that your coding accurately reflects the content. Additionally, reviewers aren’t constantly backtracking to make family adjustments based on the content of that fifth attachment.

The increase in complexity of production set assembly is greatly offset by the time savings to the case team.

Redaction image courtesy of Jack Zalium.