Decision page

eDiscovery document classification stack for Legal

What should a legal team use for first-pass eDiscovery document classification?

ZBS editorial starting point. Start with Docling for conversion, Claude Message Batches for asynchronous classification and LangGraph for sampling and reviewer decisions.

Review teams receive labelled batches with preserved source identity and measurable review samples.

Editorial starting point

Batch classification with review sampling

A concrete starting configuration that keeps source facts, model output and operational authority separate.

Choose this when: The corpus is large, answers need not be immediate and sampling is defensible.

Ingestion Docling observed

Convert supported files reproducibly. The public quickstart documents local conversion and structured export.

Limit: Scans, unusual tables, annotations and source metadata require a representative parsing test.

Evidence: source 1
Classification Claude Message Batches observed

Process independent labels asynchronously. The official batch API is designed for high-volume work that does not need an immediate response.

Limit: Completion, expiry, result retention and review still need an explicit operating path.

Evidence: source 1
Review LangGraph observed

Route samples and disagreements. Stateful workflow steps keep model output separate from acceptance and operational action.

Limit: Policy, persistence, access control and recovery remain application responsibilities.

Evidence: source 1

Private / local

Controlled reasoning path

Keep parsing, retrieval or model inference in controlled infrastructure while retaining the same source-of-truth and approval rules.

Choose this when: Sensitive inputs cannot be sent to an external model API and the team can operate the additional infrastructure.

Ingestion Docling source backed inference

Convert material locally. The public quickstart documents local conversion and structured export.

Limit: Scans, unusual tables, annotations and source metadata require a representative parsing test.

Evidence: source 1
Similarity pgvector source backed inference

Find similarity candidates. It keeps vector search beside relational metadata and access filters in PostgreSQL.

Limit: Approximate retrieval can miss results and needs recall measurement against an exact baseline.

Evidence: source 1
Classification vLLM source backed inference

Serve a local classifier. It provides a documented self-operated model-serving layer.

Limit: Serving a model does not prove its task accuracy, safe tool use or secure operation.

Evidence: source 1
Review LangGraph source backed inference

Record overrides and samples. Stateful workflow steps keep model output separate from acceptance and operational action.

Limit: Policy, persistence, access control and recovery remain application responsibilities.

Evidence: source 1

Budget alternative

Lower-cost external model path

Keep the workflow and source integration explicit while evaluating a lower-cost model candidate on the same acceptance set.

Choose this when: External processing is acceptable and measured model spend is a leading constraint.

Ingestion Docling source backed inference

Prepare identical inputs. The public quickstart documents local conversion and structured export.

Limit: Scans, unusual tables, annotations and source metadata require a representative parsing test.

Evidence: source 1
Classification DeepSeek API source backed inference

Produce candidate labels. It is a concrete lower-cost external model candidate for the same acceptance set.

Limit: Price alone is not task fitness; output structure, languages, availability and data terms need testing.

Evidence: source 1
Review LangGraph source backed inference

Run sampling and override. Stateful workflow steps keep model output separate from acceptance and operational action.

Limit: Policy, persistence, access control and recovery remain application responsibilities.

Evidence: source 1

Community check

Do you agree with this starting stack?

This is a reader opinion about the whole editorial recommendation, not evidence that the stack is objectively good. Votes never change it automatically.

Loading reader votes…

Voting needs JavaScript. The recommendation and every source above remain available without it.

How the stack fits together

eDiscovery document classification workflow for Legal, showing the primary stack components in order. — ZBS Index functional diagram generated from the cited stack revision; no third-party interface or private data is reproduced. Source, captured 2026-08-14.

Trade-offs that change the choice

Constraint	Primary	Private / local	Budget
Data boundary	The named managed APIs receive only the fields explicitly sent to them	Reasoning stays controlled; source systems may remain external	Lower cost does not make external processing private
Operational load	Lower: managed components with explicit integration points	Highest: serving, retrieval and recovery are yours	Moderate: custom workflow plus external APIs
Decision authority	Risky writes and low-confidence cases require a deterministic or human gate	The same gate is required regardless of hosting	Lower model price does not relax the approval rule

Implementation path

1. Preserve hashes and matter metadata.

2. Define labels and a blind validation sample.

3. Measure rare classes and disagreements separately.

4. Keep labels provisional until review acceptance.

Known limits

This does not replace legal hold or chain of custody.

Lower cost is not defensibility evidence.

No product on this page is a universal winner; the configuration still needs a task-specific acceptance test.

EU and US routes stay consolidated with Global until evidence changes the answer.

Validate this stack on your data

A recommendation is a starting point. Practice Lab can test the same workflow on representative inputs, constraints and failure cases.

Request a real-data evaluation