Legal Services Offshore blog
Creating a native-file metadata exception register for discovery intake
Record missing and inconsistent metadata while preserving source files and leaving evidentiary significance to counsel and technical experts.
Metadata review describes a file; it does not decide what it proves
Native discovery files may carry filesystem dates, embedded properties, message headers, author fields, application data, family relationships, and processing metadata. A support specialist can compare those values against an approved specification and record exceptions. The specialist should not decide that a date is authentic, that a field proves authorship, that a mismatch shows spoliation, or that one value should replace another. Metadata can change through ordinary copying, migration, export, or processing. The register preserves observed facts and gives counsel or a qualified technical reviewer a precise question.
Lock down the received population first
Begin with the delivery manifest, transfer source, received time, custodian or collection identifier as supplied, file count, byte count, archive structure, and hashes provided or calculated under the approved procedure. Keep the received package read-only and create controlled working copies. NIST's digital-evidence preservation guidance emphasizes documenting source and transfer and explains both the usefulness and limits of hashes. A matching hash supports an integrity comparison; it does not establish every fact about origin or content. A mismatch is an exception requiring investigation, not automatic proof that evidence was altered improperly.
Use a field dictionary tied to the matter protocol
The firm should identify required fields, acceptable formats, null handling, timezone treatment, family relationships, and source priorities before review begins. Record the dictionary version with each batch. Do not import a field rule from a prior matter because the same label may have a different definition or extraction method. Distinguish source metadata, extracted metadata, normalized display values, and reviewer annotations. If the specification says Sent Date but the load file supplies Date Sent, record the mapping question rather than silently treating the labels as equivalent.
Preserve raw values beside normalized displays
Normalization can make sorting possible, but it can also conceal the original timezone, precision, encoding, or invalid value. Store the raw value, normalized value, transformation rule, tool version, and result. Never write the normalized value back into the native file. A blank field, zero date, impossible date, and extraction error should remain different states. When a value cannot be parsed, retain the exact string. This side-by-side design lets a technical reviewer reproduce the transformation and lets counsel assess whether the distinction matters to discovery obligations or case strategy.
Work through a migrated-attachment timestamp
Suppose an email was sent in 2024, but its attachment shows a filesystem creation date in 2019 and a modified date in 2025. The collection notes state that a mailbox migration occurred in 2025. The specialist records the email family, all raw timestamps and timezones, extraction tool, file hashes, migration note, and the observed inconsistency. The register does not select the earliest date as the document's creation date or conclude that the later value is harmless. Counsel and the technical reviewer determine whether collection history, embedded application metadata, or another source should be examined.
Keep family relationships visible
Email messages, attachments, embedded objects, and container files can lose context when reviewed as isolated rows. Capture parent and child identifiers, attachment order where supplied, container path, and any orphan condition. If a load file identifies an attachment whose parent is absent, record the missing relationship and source references. Do not create a substitute parent or remove the child from the population. Duplicate hashes also do not necessarily make records interchangeable, because their custodians, paths, family context, and collection sources may differ. The register should preserve those distinctions for reviewer decisions.
Separate extraction failure from source absence
A field may be empty because the source never contained it, the format does not support it, the collection omitted it, the processing tool failed, or the export specification excluded it. Use distinct exception codes only when evidence supports the distinction. Capture tool messages, affected formats, sample identifiers, and retry results. Avoid filling gaps from filenames or document text unless counsel approves a separate derived-data process. Derived values need their own field, method, and confidence limits; they should never masquerade as native metadata.
Record every transformation and use copy
The National Archives describes digital-preservation practices that include fixity, tracked file actions, metadata capture, validation, and separate public-use copies. A law firm's matter process will differ, but the operational lesson is useful: transformations should be attributable. Record archive extraction, decompression, conversion, text extraction, timezone normalization, virus handling, and load-file generation when those actions are in scope. Link outputs to inputs and retain logs under approved controls. If a tool cannot process a file, isolate it according to the protocol and escalate rather than experimenting on the only copy.
Pilot against several failure modes
Test missing fields, invalid dates, unsupported formats, encrypted files, hash mismatches, orphan attachments, duplicate content from different custodians, and timezones that cross a calendar date. A second reviewer should reproduce the observation from the preserved input and dictionary. Measure population reconciliation, source-linked exceptions, reproducible transformations, incorrect family links, false duplicates, unexplained value changes, reviewer corrections, and time awaiting disposition. Sampling should include clean records because systematic normalization errors may not appear in an exception-only review.
Close through an authorized disposition
Each resolved exception should retain the original observation, reviewer, instruction, action, output identity, and verification result. Reconcile the final batch count and hashes to the controlled manifest, and list every item still held, excluded, unreadable, or awaiting direction. If counsel accepts a limitation, record its scope without converting it into a general rule for future batches. A later delivery should receive its own identity and comparison rather than silently extending the closed population. LegalServicesOffshore.com can help define a Philippines-based role for intake manifests, controlled working copies, field comparisons, family checks, transformation logs, and exception routing. The firm retains preservation scope, collection strategy, discovery positions, privilege decisions, evidentiary conclusions, production specifications, and communications with courts, clients, or opposing parties.
Plan a controlled native-file intake and exception lane with E-Discovery Support.
Sources
- NIST, Digital Evidence Preservation: Considerations for Evidence Handlers
Checked for digital-file preservation, source documentation, integrity, and hash limitations.
- National Archives, About the Digital Preservation Program
Checked for public examples of recorded fixity, tracked file actions, metadata capture, validation, and separate use copies.
- State Bar of California, Rules 5.1–5.7: Law Firms and Associations
Checked as an accessible official jurisdictional example for supervision and nonlawyer assistance; the firm must apply each controlling jurisdiction.