When a lawsuit or an investigation begins, each side may have to hand over documents: emails, chat messages, spreadsheets, reports. This is called discovery, and in the digital age it is called eDiscovery. A single matter can involve millions of documents, and every one has to be reviewed before it goes out the door.
AI can help review teams work faster by predicting how a reviewer would label each document. It learns from the decisions lawyers have already made. eDiscovery document review labeling is the work of recording those decisions in a form a model can learn from. This post explains what reviewers are asked to decide, where the judgment is hardest, and why careful, consistent labels matter. It is general information, not legal advice.
For each document, a reviewer typically assigns several codes:
These codes are separate decisions. A document can be responsive and privileged, or responsive and highly confidential, or not responsive at all. A model that mixes them up will be wrong in ways that matter.
No document is relevant in general. It is relevant to a particular matter, defined by particular requests, particular people, and particular dates.
The same email can be responsive in one case and irrelevant in the next. For that reason, every project needs a coding manual written for the matter. It explains what each request covers, which people and periods matter, and gives examples of documents on each side of the line.
Legal document coding data should always carry its matter.
Privilege is where reviewers spend the most care. At its simplest, a communication between a lawyer and a client for the purpose of legal advice is protected. Real documents are messier.
Several questions come up again and again:
Annotators need worked examples of these cases, and a rule for when a document goes to a senior reviewer. Labels should also record the basis for a privilege call, such as who the lawyer was and what the advice concerned, because that information supports the log of withheld documents later.
Documents do not arrive one at a time. An email comes with attachments, and together they form a family. Replies form threads. Many documents appear several times, with small differences.
If a parent email is called privileged and its attachment is not, the project needs a rule that explains why. If two near-identical copies get different labels, one of them is probably wrong.
The data should record which documents are copies of one another, so conflicting calls can be found.
Cases often have an agreement that sets tiers of confidentiality, with rules about who may see each tier. The tiers have names, and the names vary from case to case.
Reviewers should assign a tier based on the agreement and what the document contains, such as trade secrets, financial data, or personal information, not on a general feeling that something is sensitive. The coding manual should list the tiers and give examples.
Review sets contain chat messages, spreadsheets, images, scanned papers, and text in several languages.
Chat messages are especially hard. A single line such as "ok, send it" means nothing alone. Reviewers need the surrounding messages to judge it, so the project must decide how much context each decision uses.
Cases evolve. New requests arrive. A new issue emerges halfway through the review. Documents that were set aside become relevant.
A good process records which version of the coding manual each label followed. When the scope changes, the team can see which decisions were made under the old rules and decide what to review again. Without versions, a dataset ends up mixing decisions made under different definitions.
In litigation, a review process may have to be explained later. Teams want to show that decisions were made consistently, by trained people, under written rules.
Labels support this when they record the reason for key decisions, follow versioned instructions, and pass through a second level of review. These practices also improve the training data. A model learns more from a call with a clear reason than from a bare yes or no.
Litigation attorneys, paralegals, and experienced review managers read documents differently. They know how privilege gets lost, can tell advice from business discussion, and understand why a coding manual needs examples. They also write the rules that keep a large team consistent: the code definitions, the privilege examples, the confidentiality tiers, and the handling of families and threads.
This matches Globik's approach of using verified domain experts for work that depends on judgment. For legal and compliance AI training data, that experience makes labels that attorneys can stand behind. The model helps reviewers, and the lawyers remain responsible for the decisions.
Before an eDiscovery labeling project starts, a team can settle five things:
eDiscovery AI works when labels belong to a specific case, treat privilege with care, respect families and threads, and record which rules each decision followed. If you are working with review data, you can talk to our team about your review data. Strong eDiscovery document review labeling depends on people who know how reviews are run.
eDiscovery document review labeling is the coding of documents for responsiveness, privilege, confidentiality, and issues so AI can learn from reviewer decisions.
Relevance is tied to a specific case because the same document can respond to one set of requests and be irrelevant to another.
Privilege review is difficult because legal and business advice mix, outside recipients can change the answer, and forwarded chains complicate it.
Families and threads need consistent labels because related documents that receive conflicting calls usually signal an error.
Recording the coding manual version shows which decisions followed which rules, so teams know what to re-review when scope changes.
