eDiscovery software: what you are actually buying

“eDiscovery software” describes several different products sold under one label. A processing engine ingests, normalizes, deduplicates, and indexes electronically stored information. A review interface gives reviewers search, coding, privilege, redaction, and production tools. A hosting-plus-services wrapper supplies the environment, support, and often personnel needed to operate the system and move data through discovery.

Those layers can be bought separately, combined in one platform, or supplied as a managed service. Comparing them as though they were interchangeable categories creates mismatched expectations about price, staffing, performance, and control. A buyer may compare a processing engine with a reviewer-facing platform, or assume that a hosted platform includes the same configuration, data model, and production options available to a self-hosted installation.

For counsel and litigation-support managers, the practical question is not whether a product has a dashboard or a TAR label. It is whether the system can handle the organization’s data, produce defensible work, and return usable results without creating an unexpected dependency on the vendor.

Separate the engine, the interface, and the operating model#

A processing engine does work that should be measurable before data reaches reviewers. It identifies source material, extracts text and metadata, assigns document identifiers, groups related items, removes duplicate content, and prepares records for search and review. The processing layer should also preserve the relationships needed later to explain what was collected, how items were grouped, and what was produced.

A review interface is a separate product concern. Reviewers need to formulate searches, examine documents in context, assign codes, flag privilege, create redactions, and build productions. The interface may sit on a processing engine, but a capable engine does not necessarily provide an efficient or auditable review workflow. Conversely, a well-designed review environment cannot compensate for source data that was never ingested or indexed correctly.

Hosting and services add another layer. Hosting concerns where data is stored, how access is controlled, and how the environment is maintained. Services may include collection, preservation support, user administration, data migration, review staffing, production processing, and continuing technology support. The distinction matters because an operated service can supply expertise that the software itself does not encode.

Buyers should document which layer each quoted component belongs to. The contract should identify the software modules, hosting responsibilities, implementation work, support services, managed-service tasks, and any charges for changes to the environment. Otherwise, a dispute can emerge over whether a requested capability is a product limitation, an implementation choice, or an extra service.

Start with ingestion, because downstream recovery cannot exceed it#

Ingestion breadth is the first substantive platform test. The source inventory should identify the file types and repositories involved, including structured data, images, email, chats, collaboration platforms, and other commonly encountered sources. For each source, the buyer needs to know whether the platform can collect it natively, what metadata it preserves, and what limitations apply.

“Supports PDF” is not an ingestion strategy. A platform may accept a PDF as an attachment while failing to collect the surrounding custodial, folder, or message metadata needed to establish context. The same distinction applies to collaboration content: the presence of an export function does not answer whether the platform can reconstruct threads, preserve relationships, or distinguish source material from platform-generated records.

Where a source requires conversion or an external collection step, the process should preserve both the source and the resulting load file. The parties need a clear record of how identifiers were assigned and how metadata was normalized. That record supports later quality control and helps explain production decisions.

Ask for a source-specific processing test using representative material. The test should cover ordinary business records, unusually large files, structured exports, rich-media attachments, duplicate families, and truncated or encrypted content where those conditions arise. The relevant question is not whether a demonstration succeeds on curated examples. It is whether the ingestion path is complete and the resulting metadata remains intelligible.

Processing throughput and the cost of changing your mind#

Throughput claims are difficult to interpret without the processing configuration. A number may assume particular hardware, a defined set of enrichment steps, limited metadata extraction, or the exclusion of difficult content. A meaningful evaluation should identify the data volume, file characteristics, processing options, and environment used for the test.

Reprocessing is equally important. Discovery plans change when custodians are adjusted, a new source appears, search results expose a metadata problem, or a production specification changes. Some platforms treat these activities as normal operations. Others charge for reruns, reprocessing, or new load files. The commercial model should be checked against the organization’s realistic need to revisit earlier stages.

The data flow also matters. The buyer should determine whether processing can begin during collection, whether data must be staged first, and whether each movement creates a transfer, storage, or service charge. A fast platform can still have an expensive operating model if every rerun, extraction, or export triggers a new billable event.

Performance testing should use the organization’s own file types and metadata profile. A generic test may omit the very conditions that create delay. Where appropriate, the test should also examine how the platform handles errors, reports exceptions, and resumes an interrupted job without forcing the entire population to be processed again.

De-duplication and threading affect both cost and meaning#

De-duplication reduces repeated content across custodians and sources, but the method defines the result. Exact duplicates, document families, near-duplicates, and email threads are related concepts with different purposes. The buyer should examine whether the platform treats each separately and how it records the decision to group, retain, or remove an item.

Email threading can improve review efficiency by presenting a conversation as a unit. It can also affect privilege analysis and production because a thread may contain both responsive and nonresponsive content. Near-duplicate detection is useful for records that vary by metadata or minor formatting. It should not silently collapse records that differ in legally meaningful text.

Review the audit information behind these features. The platform should show which items belong to a family or thread, whether a group can be expanded, and whether a reviewer can identify the basis for deduplication. If the platform removes content before review, the organization needs confidence that the method preserves the context required for production and challenge.

The relevant output is not merely a lower document count. It is a reproducible relationship between the collected population, the reviewed population, and the produced population. Those layers may be defensible even when their totals differ, but only if the organization can explain the transformation.

Search is more than a keyword box#

Boolean or keyword search provides control over terms, fields, operators, and exclusions. A platform should also disclose how it handles stemming, capitalization, punctuation, and phrase construction. More advanced buyers need proximity and regular-expression support, along with clear rules for searching structured fields and indexing extracted attachment text.

Attachment search deserves a direct test. A term may appear in an attachment but not in the parent email. The search engine must determine whether the attachment text is indexed, how that result is associated with the parent, and whether the parent can be retrieved and reviewed without losing its relationship to the message.

Search results should also be explainable enough for an audit. Reviewers need to understand why a document was returned and whether the result set was limited by metadata, filters, coding, privilege status, date ranges, or result-ranking behavior. Saved searches and their filters should remain identifiable as review progresses.

Powerful syntax does not eliminate the need for controlled review workflows. Search can identify candidates, but it does not by itself establish responsiveness, privilege, or the defensibility of exclusions. A platform that makes broad searches easy while obscuring the resulting population can create more risk than a simpler interface with disciplined validation.

TAR and CAL require an auditable workflow#

TAR encompasses technology-assisted methods for identifying material for review; predictive coding is one such method. CAL uses reviewer decisions to continue ranking and refining the population. The commercial labels are less important than the mechanism: how the system is trained, how its rankings are validated, and how reviewers intervene.

An auditable workflow should preserve the training set, reviewer coding decisions, version history, changes to the model or ranking configuration, and the population presented for review. It should support quality control and allow the organization to reproduce or defend the selection process. Black-box relevance judgments may be embedded in the workflow, but the governance around them should remain visible.

Judicial treatment is relevant without dictating a universal procurement rule. In Da Silva Moore v. Publicis Groupe, Magistrate Judge Andrew Peck held that computer-assisted review was an acceptable way to search for relevant ESI in appropriate cases; the parties’ agreement to use it mattered, and District Judge Andrew Carter affirmed in April 2012. The opinion is widely described as the first judicial opinion approving predictive coding.

In Rio Tinto PLC v. Vale S.A., Judge Peck described the permissibility of technology-assisted review where the producing party wants to use it as black-letter law, and Maura Grossman was later appointed special master to resolve TAR disputes. In Hyles v. City of New York, Judge Peck held that a court would not force a producing party to use TAR when it prefers keyword searching, consistent with Sedona Principle 6, which places the responding party in the best position to decide how to search and produce its own ESI. Some language in Rio Tinto and Hyles is dicta rather than holding, so it signals judicial attitude rather than a binding rule.

Redaction, privilege logging, and production require different controls#

Redaction at volume involves more than applying a black box to a page. Reviewers need to verify the redaction against the document image, move or resize it where appropriate, and distinguish it from an annotation. The system should preserve the unredacted material securely while presenting a redacted derivative for production. The workflow should also record who approved the action and when.

Privilege logging should reflect the platform’s data model. A log can describe each withheld item, identify the basis for the claim, and connect the log entry to the produced document. The buyer should test how the system handles families, attachments, partial redactions, and redactions applied across multiple images. A log generated from the same production population is easier to reconcile than one assembled separately.

Production formats—native, TIFF, or PDF, with or without load files—shape later use. A native production can preserve additional functionality but requires compatible review software. PDF or TIFF productions may simplify distribution while changing the review experience. Load files can carry metadata, production identifiers, and relationships needed for later analysis. The procurement record should identify the exact format rather than treating “export” as sufficient.

Testing should compare a sample against the intended production specification. The reviewer should verify page order, image quality, redactions, metadata, load-file fields, Bates-style identifiers, and the relationship between produced documents and privilege-log entries. The goal is to know how the platform performs the transformation, not merely whether it creates an archive.

The data model determines what can be defended later#

How a platform stores families, attachments, and metadata determines what the organization can defensibly say about a production. Those relationships are more consequential than a polished user interface because they connect the source population to each review and production decision.

A family or thread should remain recognizable after processing. Attachments should remain associated with their parents. Metadata should identify source, custodian, dates, and processing relationships without losing the distinction between original values and system-generated fields. The load file should describe the produced population in a form that can be reconciled with the platform.

This structure also affects later analysis. If the platform flattens a family, removes an attachment, or replaces source metadata with a generalized field, the organization may be unable to explain the production without returning to a separate record. A defensible workflow does not require every source field to be produced, but it does require the organization to know what it retained, transformed, and omitted.

Procurement tests should follow one record from collection through processing, review, redaction, logging, production, and export. If the relationships break at any stage, that defect will appear later during reconciliation or challenge.

Export is part of the product, not an afterthought#

The exit package deserves equal attention to the search interface. The buyer should determine exactly what leaves the platform: documents, metadata, families, review codes, privilege entries, redactions, audit history, images, load files, and search or coding information. Some exports preserve these relationships. Others return flattened files that require reconstruction elsewhere.

Ownership questions extend beyond the raw documents. The contract should address access after termination, retention of exported data, availability of audit logs, and whether the organization can retain a complete production package if it changes platforms. Any restriction on extraction can affect litigation support, internal investigations, and long-lived matters.

A trial export can expose assumptions hidden by the normal workflow. Run the export with a representative population, compare it with the on-platform records, and open the result in an environment that does not share the vendor’s proprietary layer. The goal is not portability at any cost. It is knowing where the platform creates dependency and whether the buyer retains the records needed to keep working.

Questions that expose a demonstration#

A structured demonstration should use the buyer’s own file types, metadata, and intended workflow. Several questions reveal the boundaries quickly:

• What throughput does the platform sustain on this file population, and under what processing configuration?
• What happens when processed data must be changed, and what costs arise for reprocessing?
• How does the search engine retrieve a parent when a search term appears only in an attachment?
• What does the audit log record about review decisions, model or ranking changes, privilege calls, redactions, and production actions?
• How are families, attachments, and original metadata represented after each processing step?
• What exactly can be exported, in which formats, and can the export be validated outside the platform?

The answers should be demonstrated or documented, not left to a marketing statement. A sample workflow should also include exception handling: missed files, unreadable content, interrupted processing, changing custodians, and a revised production request.

Align the platform with the discovery rules#

Software capabilities should support, rather than replace, the legal framework. The e-discovery amendments to the Federal Rules of Civil Procedure took effect on 1 December 2015 and govern cases pending on, and commenced after, that date. Rule 26(b)(1) moved the proportionality factors into the definition of the scope of discovery and added consideration of the parties’ relative access to relevant information. A platform that can narrow custodians, date ranges, data sources, and search methods can make those decisions more operationally meaningful.

Rule 34(b)(2)(B) requires a responding party to state grounds for objecting to a request with specificity. Rule 34(b)(2)(C) requires an objection to state whether responsive materials are withheld on that basis. A review workflow should support defensible logging and reporting of objections, withheld material, and the basis for each position.

Rule 37(e) creates a two-tier framework for lost ESI that should have been preserved. Under (e)(1), a court may order measures no greater than necessary to cure prejudice upon a finding of prejudice. Under (e)(2), a presumption or sanction requires a finding that the party acted with the intent to deprive another party of the information. Preservation controls, event records, and chain-of-custody documentation therefore belong within the platform evaluation.

Rule 26(f) requires the parties to confer before the scheduling conference, and Rule 16(b) governs the scheduling order. The system should retain enough discovery history to support those discussions. Federal Rule of Evidence 502(d) also permits a federal court to order that privilege or work-product protection is not waived by disclosure in the proceeding before it, making accurate privilege handling and controlled disclosure important beyond the search phase.

The larger decision: software or an operated service#

The most consequential choice may be whether the organization runs the platform itself or buys it operated. A self-run model gives the organization direct control over users, retention, configuration, data movement, and exit strategy. It also assigns more responsibility for infrastructure, support, processing, administration, and method validation.

An operated service can reduce the internal burden and supply experienced personnel. The trade is control: the operating model, staffing, escalation path, and reliance on the provider become part of the discovery process. Contracts should address staffing continuity, knowledge transfer, service levels, data location, security responsibilities, subcontracting, export rights, and what happens when the engagement ends.

The EDRM helps organize the evaluation. Its stages are information governance, identification, preservation, collection, processing, review, analysis, production, and presentation. It is a reference model, not a mandatory sequence, and matters often loop between stages. That makes platform flexibility important. The best purchase is not the product with the longest feature list. It is the one whose ingestion, data model, review controls, production outputs, auditability, and operating model fit the organization’s actual discovery practice.