Processing: the stage that decides what reviewers will ever see

Processing is routinely treated as a technical handoff between data collection and document review. That framing understates its significance. A file that is not expanded, converted, indexed, or reconciled with a collection manifest may remain technically present while remaining functionally unavailable to the review team.

The distinction matters because downstream tools operate on what processing makes visible. Search results, de-duplication decisions, privilege review, production preparation, and sampling all depend on the document population created at this stage. A reviewer cannot assess responsiveness to a term that never appears in the searchable text.

Processing also creates an evidentiary record. The record can show what the custodian’s data contained, how transformations were performed, which files could not be handled, and how uncertainty was resolved. That record is more useful when it was designed at the outset rather than reconstructed after a dispute.

What processing actually does#

Processing converts heterogeneous electronically stored information into a reviewable and searchable form. The steps may occur in different orders, and some tools may combine them, but the underlying functions remain distinct. Each function changes either the representation of a file, the population under review, or the ability to locate a document.

1. File identification determines what each item actually is. A file extension may be misleading, and a collection may contain formats associated with office applications, email, images, databases, and software-specific packages. Identification establishes the starting point for deciding whether a file can be opened, expanded, or converted.
2. Container expansion opens files that hold other items. An email archive may contain messages and attachments; a compressed file may contain a directory; and a document package may contain embedded files. The expanded items then need their own metadata, text, relationships, and exception treatment.
3. Text and metadata extraction pulls searchable content and available contextual fields from each item. Extracted text supports search and review. Metadata may include such matters as the file’s creation and modification information, email headers, document properties, and relationships to other items.
4. OCR processing creates text from image-only pages, including pages incorporated into otherwise searchable documents. OCR output becomes part of the search index, but it is a derived representation rather than the original image content.
5. Date normalization converts recorded time values into a consistent form for sorting, searching, and display. The original values remain relevant to interpretation, especially where systems recorded local time without a complete time-zone offset.
6. De-duplication identifies exact or near-duplicate material so reviewers do not spend time on redundant copies. The comparison scope and matching method determine what counts as a duplicate and which version remains in the review population.
7. Indexing makes the resulting text and metadata available to the search platform. Indexing does not improve the underlying file. It determines whether a word, phrase, date, or field value can lead a reviewer to a responsive document.

These functions should not be collapsed into the word “conversion.” Conversion may alter a file’s format, while expansion may increase the item count, extraction may create searchable text, de-duplication may reduce the review population, and indexing may make the entire population queryable. Each operation has distinct consequences for scope and defensibility.

Why a collection grows after collection#

The volume measured before processing can understate the population that reviewers will actually search. A compressed archive contributes one item at collection but may expand into many files. An email message may be one collected object while its attachments are separate review items. A document package may yield embedded objects that had no independent item count in the source collection.

Processing can therefore increase both the item count and the searchable text volume. That result affects processing capacity, review design, and any pricing model based on collection or processed volume. Under a volume-based pricing model, an estimate made before expansion is an estimate of the source data, not a dependable measure of the processing work still ahead.

That distinction is especially important when an estimate is used to decide how much data can be processed under a fixed budget or within a review schedule. An estimate can be improved by identifying the expected source formats and testing representative material, but it cannot reliably account for archives, embedded items, corrupt files, unexpected duplication, or image-only content before the collection is processed.

Volume figures should therefore identify what they measure: collected objects, expanded items, pages, extracted files, or searchable content. Otherwise, two reports may use the same total to describe different populations. That ambiguity can propagate into search design, production planning, and the explanation of how the review population was assembled.

Exceptions are part of the evidentiary record#

An exception is a file, object, or item that the processing workflow could not handle according to its normal path. Exceptions are not limited to visibly damaged files. They include any item that the process cannot render, extract, convert, or make reliably searchable.

Password-protected files present one type of exception. If the password is known or lawfully available through an appropriate channel, the file may be opened and processed through a separate workflow. If it is not, the file can remain represented only by its name, location, and available metadata. Its contents then remain invisible to ordinary full-text search.

Corrupt files present a different problem. Damage may prevent opening, text extraction, image rendering, or some combination of those functions. The processing platform may identify an error while preserving the item and its metadata. That preservation is important, but it does not make the content reviewable. A corrupted item still needs to appear in an exception record, and the available options for recovery or alternate rendering need to be documented.

Unsupported formats create another category. A file can be intact and identifiable while remaining outside the platform’s ordinary rendering or extraction path. The name alone does not establish whether the document is relevant. Without separate conversion, visual review, or another documented approach, the file is present in the collection but absent from the effective search population.

Files that produce no text present a related risk. An image-only page may produce an image but no searchable text. A document may contain only graphics, a blank form, or visual content that does not yield extractable characters. Unless OCR or visual review handles the item, it will not respond to a keyword query based on its contents.

Embedded objects can escape notice because they remain inside a parent document. An embedded spreadsheet, image, archive, or attachment may not appear as a separate collected item until the parent is expanded. Failure to expand the parent can conceal responsive content from search while leaving the parent item itself searchable. The processing record should therefore distinguish an object that was extracted, an object that was inventoried but not opened, and an object that could not be accessed.

Each of these exceptions has the same practical effect if left unresolved: the document’s content is not available through ordinary search. A search term may match a filename, a custodian reference, or some other metadata, but it does not reach the unknown words inside the file. A document that cannot be found by search can also be missed by de-duplication review, sampling, and targeted issue searches.

For that reason, the exception report is a defensibility document, not merely an IT artifact. It should identify the affected item, the processing operation that failed, the available metadata, what was done to resolve the exception, and the result. If an item remains unavailable, the report should state that fact rather than allowing silence to suggest that the file was successfully processed.

Exception handling also requires careful population accounting. An expanded file that cannot be processed should be distinguishable from a successfully expanded item, and both should be distinguishable from a successful parent file containing an unexpanded object. Collapsing all of them into a generic “error” total obscures the actual search coverage.

Time-zone choices can change the sequence of events#

Time-zone normalization is not merely a display setting. It affects which documents appear in a date filter, how messages are sequenced, and whether a search for a particular day returns the expected population. It also affects the explanation of causation, chronology, notice, and the order of events.

Consider an email sent from one system and received through another. Each system may preserve a different representation of the event. When normalized without preserving the original field, the conversion can appear authoritative even though the underlying time value was incomplete or inconsistent. The normalized value helps comparison; the source value helps interpretation.

The defensible approach is to record the selected time zone for the collection or matter, identify where another zone was used, and preserve enough original information to explain the transformation. Where the original entry has no unambiguous offset, the record should not manufacture certainty. Search and review teams need to know whether the date represents a normalized convention, a source value, or an inference.

Time-zone choices also interact with search and de-duplication. A date filter can exclude an item from the period under review if its normalized value falls outside that period, even though the unnormalized source value would place it inside. Near-duplicate detection can likewise treat versions differently if their available date fields vary. Those results should be tested against the documented convention rather than accepted automatically.

OCR: useful text, but not perfect text#

OCR converts visible characters in an image into machine-readable text. It gives scanned documents and image-only pages a way to enter the same text index as native documents. That is a major benefit: without OCR, a visible phrase in a scanned record may be unreachable by keyword search.

OCR output is still an imperfect representation. Character confusion, poor scan quality, unusual layouts, and missing context can introduce recognition errors. Handwriting presents additional challenges because character forms may not follow the patterns applied to printed text. OCR can also produce text from marks, forms, or graphics that resemble characters without carrying the intended meaning.

The practical consequence is that keyword search over scanned material depends on the quality of the derived text. A search term may miss a document when OCR altered the word, and it may retrieve a document because OCR interpreted visual material incorrectly. The existence of searchable text does not establish that every visible word has been captured accurately.

OCR should therefore be evaluated as part of the review design. Teams may compare OCR output with the image for representative pages, consider which search terms are especially sensitive to recognition errors, and supplement keyword review with visual review where the stakes justify it. An OCR exception or low-confidence result should not be treated as equivalent to clean text extraction from a native document.

Derived text should also remain distinguishable from original document text. Keeping the OCR output associated with its source image supports validation and explanation. It also permits a reviewer to see that a hit came from OCR rather than from an embedded text layer.

Decisions that belong in the processing record#

The processing record should preserve decisions that shape the review population and explain why a document appeared, disappeared, or could not be found. The record need not reproduce technical execution logs in full. It should make the governing choices legible to litigation support, counsel, and anyone later evaluating the review.

• De-duplication scope should identify what was compared, including the metadata fields used to group potentially duplicate items. It should also explain whether the retained item was a custodian copy, a parent email, a later version, or another designated representative. Those choices can affect search context and how reviewers understand relationships among documents.
• Time zone should identify the normalization convention and any collection-specific exceptions. The record should explain whether original time values remain available for review and export.
• File-type exclusions should identify what was excluded, why it was excluded, and how many items were affected. A format excluded from ordinary processing may still require separate handling if it could contain responsive material.
• Exception resolution should describe each category, the action taken, the unresolved population, and the impact on search coverage. Password-protected items, corrupt files, unsupported formats, textless files, and embedded objects should be distinguishable when their handling differs.
• OCR treatment should identify the scope of image processing and how derived text is labeled. If some materials received visual review rather than OCR, that decision should remain visible.

The purpose is not to create a larger technical archive. It is to connect a reviewer’s search result to a known population. When a document is present, searchable, and reviewable, the record should indicate how it entered that state. When it is absent or unavailable, the record should explain why.

Search coverage, proportionality, and the invisible document#

Search operates on an indexed representation. A keyword search cannot retrieve a document whose content was never extracted, and an OCR-dependent search depends on the quality of the OCR output. Filtering by custodian, date, or metadata only reaches items that remain in the processed collection. The review is therefore constrained by processing even when the search query itself is precise.

Rule 26(b)(1) places proportionality factors within the definition of the scope of discovery, including the parties’ relative access to relevant information. Processing choices bear on that inquiry because they determine what a search can reach. The scope of the data source, the burden of processing less relevant formats, and the availability of alternatives can bear on how the review population is built.

That does not turn every exception into a discovery dispute. It does mean that exceptions and processing decisions should be understood as part of the search method. If a category of files was not expanded, converted, OCR-processed, or otherwise reviewed, the search plan cannot simply be described as covering all collected material.

The 2015 amendments to the Federal Rules of Civil Procedure took effect on 1 December 2015 and govern cases pending on, and commenced after, that date. Within that framework, discovery remains connected to preservation and the treatment of electronically stored information lost after it should have been preserved. Rule 37(e) distinguishes between a failure that causes prejudice and a failure accompanied by an intent to deprive another party of the information. A processing exception report does not establish either condition, but a clear record helps explain what was preserved, what was accessible, and what the party actually did with the information.

The central point is simple: processing determines the practical universe of discovery. It decides which containers open, which objects receive text, which records can be found by a date or term, which duplicates remain for review, and which failures are visible to the team. Without that work, a term list is only a list of hypothetical routes into the data. With a documented processing record, search becomes an auditable method rather than an assumption that every collected file was fully available.