At the start of Brett Kavanaugh's Supreme Court confirmation hearing on Tuesday, Sen. Kamala Harris suggested that the hearing should be delayed because of the inability to review some 42,000 pages of documents released the night before. “We can not possibly move forward with this hearing,” Harris, D-California, said.

The documents, released by a lawyer overseeing the Bush White House records, were related to Kavanaugh's time in the George W. Bush administration. Senate Minority Leader Chuck Schumer, D-New York, tweeted at 7:13 p.m. the night of the document dump that “Not a single senator will be able to review these records before tomorrow.”

Less than three hours after that Schumer tweet, the Senate Judiciary Committee tweeted at 9:50 p.m. that the Majority staff had completed its review of “each and every one of these pages.”

So who's right? Were those documents impossible to review? Was the Majority able to effectively search all of those documents in half the time it would take to binge watch “Mindhunter” on Netflix?

According to document review experts who regularly deal with large quantities of documents in litigation, the answer is: It depends. It depends on the objective, type of documents, and whether it's known whatexactlythe reviewers want to find within them.

John Rosenthal, partner and chair of the e-discovery and information governance practice at Winston & Strawn, says that a skilled document reviewer can look at about 60 documents per hour, with each document averaging two to four pages, for a total of 120-240 pages per hour per person.

“I don't know what the Senate staff looks like and I don't know who is looking at those documents. Even without a tool set this is not an insurmountable amount of documents,” he said.

If that still seems a little sluggish, Rosenthal said the process can move even faster when search tools are introduced.

“[The Senate Judiciary staff] are trying to find documents of interest to them so they can ask questions about them to get the witness' perspective on them,” he said. “I would be shocked if they are going to review [everything]. You wouldn't necessarily review all those documents, what you're going to do is figure out what issues are more important to you then prioritize the documents according to those issues and probably look at the stuff that is more relevant to what you are looking for.”

But Gareth Evans, a Redgrave partner who deals with large quantities of documents in his practicepages numbering the tens of thousandscautions against the limitations of search terms.

“It seems to assume you're looking for documents on a particular subject and it may be presumptuous to limit yourself to a particular topic by using keywords because the keyword search will obviously only identify documents with those terms in them,” he said. “If you're using keywords that miss entire topics then the search is not an effective one.”

Turning back to the Kavanaugh hearing, is it possible that all those documents were reviewed in those short few hours? According to the Washington Post, there were 5,148 documents totaling 42,390 pages related to Kavanaugh's service in the Bush administration. Rosenthal said that the 60 documents per hour standard involves documents that average two to four pages. The Kavanaugh documents average eight pages per document. Using Rosenthal's calculations at a rate of 240 pages an hour per staff member, and generously spotting a well-orchestrated review strategy at the outset, that would clock in at 11.75 hours for a team of 15 to sift through 42,390 pages. 11.75 hours is nearly double the time the Majority in the Senate Judiciary claims to have completed the task, but still well within the span of the four-day confirmation hearing. So while it's not ideal, and questions about thoroughness can be raised, it's not necessarily the impossible task that Harris and Schumer made it out to be.

For a better understanding of how reviewers undertake a project of this magnitude, here's Rosenthal's breakdown of the approach used to cull through large quantities of documents:

|

The Technical Breakdown

Hashing

“[To review large data sets] the first thing you do, in litigation context, is you would put this through a processing engine which is going to generate a fingerprint for each document. … And it basically is going to calculate what would be a unique document number for each document.

If you run the data set through the hashing algorithm it will tell you immediately if two documents have the same has number, then that means they are 100 percent identical. There are also technologies that can show near duplication, so it may be a draft of the same document,” Rosenthal said.

Email Threading

“Then on the email side we have email threading tools [that show email chains]. With email threading technology, you press a button and it brings all the thread together in one place that are related and it will tell you out of these all of emails these two are the most inclusive. They are going to have the entire conversations, so you only need to look at these two instead of the entire thread set,” Rosenthal said.

Keyword Search / Clustering

“The next one you would use is really looking at search terms and running search terms to try to identify through keywords those documents that are important. The next set of tools you would use is a clustering engine. You take your data set, press a button and it's going to put everything into related categories. So for example, let's use 'Thanksgiving,' the clustering engine is then going to give me a bucket of things related to Thanksgiving, like turkey, cranberries, green beans, football, etc,” Rosenthal said.

Predictive Coding

“Then the next tool in the arsenal is predicting coding engine where you are training the engine. You use 2 or 3 percent of the document set and you train the algorithm as to what you are looking for and once the algorithm is trained you run the rest of the 97 percent of the data through a classifier and it will put categorized things into different buckets for you. On a 24-hours basis it would be pretty tough to run a predictive coding exercise,” Rosenthal said.