Choosing a review platform: four buying postures, not four products

Comparing review platforms is not a feature-counting exercise. A platform can support a broad set of source types and still fit poorly with a matter because the control of administration, the defensibility of its review process, or its export terms do not match the organization’s operating model.

This comparison therefore does not rank products, award scores, or report hands-on testing. It establishes durable evaluation criteria for enterprise platforms, integrated cloud platforms, and existing in-suite tooling. Major services such as Relativity, Everlaw, and DISCO appear only as examples of platform categories, not as recommended answers.

The relevant answer depends on matter profile and on whether the organization has dedicated litigation-support staff. A platform that is excellent for a 10-terabyte antitrust matter can be the wrong tool for a 20-gigabyte employment case. The more defensible comparison asks how each operational posture handles discovery work, not which interface contains the most buttons.

Four buying postures, not four products#

The first buying posture is an enterprise platform operated by a provider. The provider controls the hosted environment and manages much of the underlying infrastructure and support. This model can place routine administration, maintenance, and technical response outside the organization, although the allocation of those duties still needs to be defined in the agreement and service documentation.

The second posture is an enterprise platform self-hosted or self-administered. The organization controls the environment, configuration, upgrades, access, and support responsibilities. That control can be valuable where data-handling requirements or internal technical capacity make centralized administration unsuitable, but the organization must assess the personnel required to keep the platform operable and defensible.

The third posture is an integrated cloud platform sold directly to firms and legal departments. The defining issue here is not merely cloud deployment but integration between review, matter management, collaboration, and the workflows already used by legal teams. An integrated environment may reduce handoffs when it matches the organization’s actual staffing and administration model. It may also increase switching costs when those connections become deeply embedded.

The fourth posture is the in-suite tooling already owned. That approach belongs to the separate Microsoft-focused analysis and is not repeated here. It remains part of the buying decision because an existing suite can be adequate for defined matter types while requiring a different platform for larger, more specialized, or more technically demanding discovery work.

Start with the matter profile#

Before comparing capabilities, define the work the platform must support. The relevant profile includes data volume, source diversity, number of custodians, review population, language needs, deadline pressure, and whether the data must move among the organization, a service provider, opposing parties, and experts.

Also distinguish collection from review. A platform may receive data through an existing collection process and then focus on search, issue coding, redaction, privilege review, production, and analysis. A matter requiring defensible chain-of-custody handling, distributed collection, or several load-file deliverables demands a broader workflow assessment.

The Electronic Discovery Reference Model provides a useful vocabulary for that assessment. Its stages are information governance, identification, preservation, collection, processing, review, analysis, production, and presentation. EDRM is a reference model, not a mandatory sequence, and real matters loop between stages. A platform should therefore be evaluated against the way the organization works, including revisits, not against an assumption that every matter follows a straight line.

The staffing profile is equally important. In-house teams with dedicated litigation-support personnel may be able to manage configuration, load files, detailed logging, and production operations directly. A smaller legal department may need a provider-operated model, although that does not eliminate the need to understand access, escalation, security, and exit arrangements.

Evaluation criteria that survive a release cycle#

Ingestion breadth#

Ingestion breadth concerns the range and complexity of electronically stored information the platform can ingest and make reviewable. The evaluation should begin with the organization’s actual data estate rather than a generic list of supported formats. Sources may include structured applications, collaboration platforms, email archives, mobile data, databases, and files created by specialist systems.

Ask how the platform identifies metadata, handles attachments, preserves relationships, and reports exceptions. Also determine whether collection can run directly, whether a load file is required, and how errors are surfaced and corrected. The important distinction is between accepting a data type and producing reviewable content with coherent metadata and usable search fields.

De-duplication, email threading, and near-duplicate detection belong in this discussion because they affect the size and shape of the review population. Their relevance depends on the matter, and their settings should be documented because different choices can affect what reviewers see.

Search expressiveness#

Boolean and keyword search remains a baseline capability because many review teams need precise, explainable term combinations. The comparison should examine field selection, operators, date and custodian filters, saved searches, proximity controls, and whether searches can be reproduced as part of a review protocol.

Search quality should not be reduced to a demonstration involving a prepared dataset. A useful evaluation uses representative custodians, known responsive material, and the issues expected in the matter. Reviewers can then examine whether the platform supports both broad issue searches and targeted follow-up without turning every question into a specialist query.

Search expressiveness also includes the relationship between search and technology-assisted review. TAR, including predictive coding and continuous active learning, can support prioritization or review workflows, but the evidentiary significance comes from how the workflow is designed and documented, not from the label attached to the feature.

TAR workflow auditability#

When evaluating TAR, inspect the decision points rather than only the throughput claim. The platform should expose how documents are categorized, how training or active-learning decisions are made, how errors are found and corrected, and how a reviewer or court can understand the path from the initial population to the reviewed result.

Ask what controls govern seed documents, coding consistency, reviewer feedback, validation, and quality assurance. The ability to retain the material used for training and to reproduce a classification decision can matter as the matter advances. The answer should also distinguish between assistance that prioritizes documents and assistance that makes production decisions.

Federal case law does not make TAR a universal requirement. 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 stated that courts will permit technology-assisted review where the producing party wants to use it, describing the proposition as black-letter law. Maura Grossman was later appointed special master in that matter to resolve TAR disputes. By contrast, Hyles v. City of New York, decided on 1 August 2016, held that a court will not force a producing party to use TAR when it prefers keyword searching. That approach is consistent with Sedona Principle 6, which places the responding party best situated to decide how to search for and produce its own ESI.

Some language in Rio Tinto and Hyles is dicta rather than holding. Those passages signal judicial attitude rather than establish a binding rule, but they make clear that a defensible technology choice can rest on a reasoned response to matter-specific conditions.

Redaction and privilege tooling at volume#

Redaction and privilege review should be evaluated as a combined workflow. The platform needs to support consistent application of selections, controlled batch changes, visual verification, and the creation of a privilege log with fields suitable for the matter. Reviewers must also be able to distinguish confidentiality concerns from legal privilege without relying on unrelated metadata cues.

At volume, the practical questions concern exception handling and review discipline. Can redactions be burned into the production? Can text remain searchable beneath a redaction? Are annotations, blackened images, or privilege designations represented consistently? How are privilege calls exported, and what mechanism supports a clawback when protected material is produced?

Federal Rule of Evidence 502(d) permits a federal court to order that privilege or work-product protection is not waived by disclosure in the proceeding before it. That possibility does not replace a sound privilege-review process. It underscores why reviewers should understand the distinction between a logged assertion, a redacted document, and material actually disclosed.

Production and load-file flexibility#

Production flexibility should be tested against actual recipients and obligations. Ask whether the platform can create native, TIFF, or PDF productions, with or without load files, and whether it can produce combinations rather than forcing one export template across the matter.

The load-file evaluation should go beyond a successful export. Review the available metadata fields, delimiters, character handling, Bates numbering, confidentiality designations, and the treatment of extracted text. Confirm whether the output can satisfy a specified production specification and whether the same process works for a later supplemental production.

Presentation also matters when productions are used in testimony or demonstrations. The platform should preserve the relationship between the produced content and the review context without requiring reviewers to rely on an inaccessible internal state.

Audit logging#

Audit logging should answer who did what, when, and under which configuration. Relevant events include ingestion, processing changes, search execution, document viewing, coding, redaction, privilege designation, export, administration, and permission changes. Logs can support matter management and defensibility, but their existence alone is insufficient if the records cannot be filtered, retained, or associated with the correct matter.

Evaluate timestamp consistency, event detail, retention behavior, and access controls. For TAR workflows, ask whether the log captures enough information to connect model or active-learning activity with human review. A useful audit trail records the operating history rather than merely showing that a user clicked a control.

Administration and permissions#

Administration should be mapped to the organization. Identify who can create matters, assign roles, alter settings, manage custodians, run collections, approve productions, export data, and retrieve audit records. Examine whether permissions can reflect segregation of duties, client or matter boundaries, and the need to separate ordinary reviewers from administrators.

Consider both granularity and exception handling. A platform may offer detailed roles but make routine operations cumbersome, or offer convenient defaults that leave controls too broad. The evaluation should use realistic staffing patterns and include the work performed when a team member leaves or moves between matters.

Export on exit#

Export on exit is a core comparison criterion, not an afterthought. Determine which matter data leaves the platform, in what formats, at what granularity, and whether privileged, redacted, and unreviewed content remain distinguishable. The exit package should preserve the data and metadata needed for ongoing review, later production, or transfer to another system.

Ask whether exports include logs, privilege data, saved searches, TAR decision records, annotations, and configuration. Also examine whether the organization can retrieve the full data if the provider or platform is unavailable. Contract language should be evaluated alongside technical export capability because the two answer different parts of the exit problem.

Procurement questions that features cannot answer#

Who administers it?#

The administration question should identify the party responsible for each operational task, not merely the party that hosts the software. Separate platform administration from collection, processing, review management, user support, security administration, and production delivery. The allocation should reflect the organization’s staffing and the matter’s requirements.

A provider-operated model may place more technical duties with the provider while leaving the organization responsible for legal decisions and matter governance. A self-administered model reverses much of that allocation. An integrated cloud platform may combine workflow administration with product administration. Those distinctions should be captured in the operating model before feature comparisons begin.

What happens when a production is due tomorrow?#

The support model needs an operational answer for urgent production work. Identify the escalation path, available hours, response channels, incident ownership, and the point at which provider support ends. Ask whether production assistance comes from the party administering the platform or from a separate team accustomed to legal discovery delivery.

Also examine knowledge transfer. If the organization manages the environment, the staffing plan should account for specialists who can handle urgent processing and production issues. If the provider administers it, the agreement should describe how escalation works during a critical deadline and how responsibility is tracked.

What is the data-residency position?#

The data-residency question should distinguish storage location from the complete processing path. Identify where data is hosted, where it may be backed up, which parties can access it, and whether support or troubleshooting can involve cross-border access. Then map those answers to the organization’s contractual, client, and internal requirements.

No general platform description answers this question. It requires current contractual terms, architecture documentation, and a clear understanding of the intended data flow. A secure hosting statement is not meaningful if the boundary around vendor access and support operations remains undefined.

What does the contract say about getting the data out?#

The exit contract should specify the available formats, timing, completeness, fees if any, and the conditions for retrieval. It should address both raw matter data and review artifacts. The parties should also establish how long the provider must retain or return material, what happens after retrieval, and how the organization can verify that an export is complete and usable.

Technical testing of an export does not replace contractual clarity. The evaluation should compare what the platform can export with what the agreement obliges the provider to deliver. Where those differ, the difference belongs in the procurement analysis.

Discovery rules shape the operational questions#

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 itself and added a factor for “the parties’ relative access to relevant information.” That factor makes the search method a matter-specific issue: a party with superior access to relevant information may bear a different practical burden from one that lacks that access.

Rule 34(b)(2)(B) requires a responding party to state the grounds for objecting to a request with specificity. Under Rule 34(b)(2)(C), an objection must state whether responsive materials are being withheld on that basis. Review platforms should therefore support disciplined objection tracking and defensible basis documentation rather than treating objections as informal collection notes.

Rule 37(e) addresses electronically stored information that should have been preserved and was lost. Under (e)(1), a court may order measures no greater than necessary to cure the prejudice upon a finding of prejudice. Under (e)(2), the adverse presumptions or sanctions described in the rule require a finding that the party acted with intent to deprive another party of the information. Preservation controls, auditability, and documentation of collection and processing therefore belong in a platform assessment.

Rule 26(f) requires the parties to confer before the scheduling conference, and Rule 16(b) governs the scheduling order. Those provisions make early, structured discovery planning part of case management. A platform should furnish information that supports those discussions and preserve the record needed to explain later search, review, and production decisions.

The comparison should produce an operating decision#

A durable platform comparison ends with a documented operating model. It identifies the matters the platform will handle, the party that will administer it, the controls that must remain auditable, the support available under deadline pressure, the applicable data-residency constraints, and the contractual route for exporting the data.

The same platform can be a good fit for one organization and a poor fit for another. Existing staff, data sources, review methods, production obligations, and exit requirements can outweigh a difference in nominal feature coverage. Comparing those operational variables produces a clearer decision than naming a preferred product or presenting an unqualified feature table.

Common questions#

What are the four buying postures for eDiscovery review platforms?

They are provider-operated enterprise platforms, self-hosted or self-administered enterprise platforms, integrated cloud platforms sold directly to firms and legal departments, and existing in-suite tooling.

What factors belong in the matter profile?

The profile includes data volume, source diversity, number of custodians, review population, language needs, deadline pressure, and whether data must move among the organization, a service provider, opposing parties, and experts.

What should be inspected when evaluating TAR?

Inspect how documents are categorized, how training or active-learning decisions are made, how errors are found and corrected, and how a reviewer or court can understand the path from the initial population to the reviewed result. Also examine seed documents, coding consistency, reviewer feedback, validation, quality assurance, and reproducibility.

What is the best software for law firms?

Relativity, Everlaw, and DISCO appear only as examples of platform categories, not as recommended answers. The relevant choice depends on matter profile and whether the organization has dedicated litigation-support staff.