Preparing Relativity-Ready Data Without Over-Collection

“Relativity-ready” should not mean “a large folder of exported data.” It should mean the collection and processing decisions were made with the receiving workspace in mind, and the package can be imported, understood, and validated without unnecessary rework.

The best time to define the delivery is before collection. That is also the best time to prevent over-collection.

Obtain the actual import specification

Relativity environments are configurable. Hosting providers and litigation teams may use different field names, identifier rules, date formats, native strategies, image requirements, analytics fields, and messaging workflows. Ask the receiving team for a written specification or sample load package.

Confirm at least:

• Required document identifier and whether it must be unique across all loads
• Metadata delimiter, quote, newline, and encoding requirements
• Native, extracted-text, and image path conventions
• Date and time format, time zone, and treatment of missing values
• Custodian, source, collection, and location fields
• Parent-child, family, attachment, and conversation identifiers
• Hash and deduplication fields
• RSMF or other short-message requirements
• Maximum field lengths, unsupported characters, and exception handling

Separate preservation scope from review scope

A source may need to be preserved even when it is not immediately collected or loaded. Create a preservation inventory, then identify the priority custodians, accounts, folders, channels, devices, and date ranges for active review. Document deferred sources and the conditions that would trigger expansion.

This approach protects against loss while limiting the first review set to the sources most likely to answer the case questions.

Collect metadata deliberately

Metadata should serve a review or evidentiary purpose. Common fields include custodian, source path, file name, extension, size, created, modified, sent, received, author, sender, recipients, subject, conversation, parent identifier, hash, and collection information. Not every source provides every field, and similarly named fields may have different meanings.

Create a field dictionary that identifies the source of each field, normalization performed, time-zone treatment, expected nulls, and any field that was generated during processing rather than obtained from the source.

Preserve families and context

Email attachments, embedded items, archive contents, and message attachments should remain linked to their parent records when the relationship matters. Deduplication should not destroy the ability to identify which custodians or locations contained a document.

For messages, a series of individual text records may be technically searchable but difficult to understand. Structured formats such as RSMF can preserve conversation, participants, timestamps, attachments, reactions, and other context. The source export must be evaluated to determine which fields are reliable and complete.

Choose native, text, and image strategy

Many review packages include native files and extracted text, with images created later when needed. Some matters require pre-rendered images, endorsements, or production-ready page numbering. The chosen strategy should account for spreadsheets, media, encrypted files, unsupported formats, embedded content, and documents whose appearance matters.

Do not assume extracted text is complete or equivalent to the native. OCR may be necessary for image-only material; application text extraction can omit hidden or unsupported content. Record text-extraction errors and files that require special handling.

Track exceptions as data

Password-protected, corrupted, zero-byte, oversized, malformed, unsupported, or partially processed items should not disappear from the workflow. Maintain an exception log or fields that identify the item, source, reason, action taken, and resolution status.

Exceptions help counsel assess whether a gap is material, authorize further effort, or explain why a record is unavailable.

Validate the package before delivery

Quality control should test more than whether the load file opens. Depending on scope, checks may include:

• Document and row counts across stages
• Unique and valid identifiers
• Existing native, text, and image paths
• Encoding and delimiter integrity
• Reasonable date ranges and time-zone conversion
• Parent-child and attachment relationships
• Hash values and duplicate treatment
• Text presence and extraction exceptions
• Sample comparison to source records
• RSMF validation and representative conversation review
• Malware, password, corruption, and unsupported-file reporting

Deliver a manifest and decision record

The handoff should identify the package, source collections, processing date, tool versions where material, field map, filters, deduplication approach, time zone, native and text strategy, message handling, exceptions, QC performed, counts, and contact for import questions.

A smaller, well-documented package is often more valuable than a larger export with unclear provenance. Relativity-ready data is the product of coordinated scoping, collection, processing, and validation—not a file extension.