Three Metadata Fields That Mislead in E-Discovery

Date Created, Author and Last Modified record something real, though not always what a brief needs them to prove.

An email attachment can carry a date later than the email that delivered it, and in a production that impossible order is ordinary rather than rare. A January 2025 r/ediscovery thread described it plainly, an attachment dated after its email was sent, "which makes no logical sense," and the poster had seen it with multiple clients. The trail led to Nuix's primary date field, built from a ranked list of fields with the file system modified date near the top, and to email vaults that split messages apart for storage and rejoin them on retrieval, leaving each attachment with a fresh file system date. Under that poster's exchange protocols, which carry a single date field, the later date is the one opposing parties see.

The fault is quiet. Date Created on copied files, Author on templated documents and Last Modified after collection each record something real, though rarely the thing a brief needs them to prove. Genuine tampering tends to leave a different trace: in OZ Optics v. Zeynep, an executive ran a scrubbing program on a company laptop before handing it over, a forensics expert detected it, and the court ordered a $90,000 sanction. I would carry that distinction into any meet-and-confer. A strange date is a question about the pipeline. A discovered wiping program is evidence about a person. Metadata, read with that kind of attention, corroborates a story, and it should never be asked to carry one alone, which is why the place to begin is with what Date Created and Author actually record.

What Do Date Created and Author Really Record?

Date Created usually marks when the copy in front of you was made, and Author usually names whoever built the original template, so neither proves who drafted a document or when.

In 2024, a reviewer on the r/ediscovery forum described 4,000 non-duplicate PowerPoint presentations in an opposing production, every one carrying the same Author, John Doe, and the same Created Date of 1/31/1999. As the reviewer put it, "a single person cannot create 4,000 different slide decks on the same day," and so the honest question is what those two fields were recording all along.

Before either field enters a timeline, I put it through three plain questions:

1. Does the date cluster? Many unrelated files sharing one Created Date point to a copy, migration or scan event rather than to drafting.
2. Does the name repeat across unrelated work? One Author on thousands of files suggests an inherited template.
3. Do the natives agree? Ask for a few native files and compare their metadata with the load file before concluding anything.

Date Created is the date the version you are viewing came into being, which is to say the copy, NOT the draft. A commenter in that same 2024 thread called it a "low quality" field whose name is deceiving, and joked about renaming it the "Collected Date," because a non-forensic collection rewrites it. Others in the thread traced the pattern to data migrations, the retiring of an old file server and the wholesale moving of its contents to new storage without preserving date stamps, and to scan bureaus and batch processing that stamp a single date across everything they touch.

Author is subtler, because it carries a person's name. In Office files it is a document property, which is why Nuix Discover files it under its Office Property metadata, and why practitioners in a separate 2024 thread found the query syntax for it differs between Nuix Discover and Nuix Workstation. The common assumption is that a name in the Author field works like a signature. It behaves more like an inheritance: one commenter described users working from a template of a template made a decade ago, carrying forward the name of a long departed original template maker, "all the users blissfully unaware." Another moved over 100 gigabytes of data between storage locations and found their own name on every file.

A native file does not settle the matter either. In another exchange, produced .MSG natives carried the same impossible timestamps as the review data, so the error lived inside the files themselves. A comparison of 5 sources behind this section points one way. On a 2023 Microsoft podcast, the company's Director of Discovery Programs described the first step toward reliable filtering as complete extracted text and a complete rendering of the metadata, and for these two fields that means reading what a document says about its own making beside what its properties claim.

Published guidance still presents a creation date as strong enough to undo a party's timeline, and sometimes it is, though that strength depends entirely on how the file travelled. Where files travel is a matter of custody, which is why Relevant e-Discovery runs inside the client's own AWS account under the client's own keys, a trust posture almost no small-firm tool can match, and a question I take up further in whether your e-discovery AI trains on your case data. The name on a file is a clue. It is not a confession.

And if Date Created marks the copy and Author marks the template, the third field, Last Modified, marks something stranger still: the moment the collection itself reached in and touched the file.

Why Does Last Modified Change During Collection and Export?

Last Modified changes because the discovery pipeline itself writes to it: export packaging, email vaults and deduplication can each replace the user's last edit with a processing event.

If Date Created and Author are bent before anyone collects a file, Last Modified is worse, because it can be bent by the very process meant to preserve it. Three mechanisms recur. Mordor Intelligence estimated that SaaS and cloud deployment held 76.45% of the e-discovery market in 2025, so cloud export steps of this kind sit on the ordinary path of a collection, and their settings are worth asking about before collection begins.

Zipped exports from Microsoft 365

In a 2022 r/ediscovery thread, a practitioner reported that exporting from Microsoft 365 Advanced eDiscovery, which packages review set data in zip files, changed the modification time of SharePoint documents. When Nuix processed them, its Item Date field, the one its automated date filter relies on, showed when each file was added to the zip rather than when anyone last edited it on the SharePoint site. Not everyone in the thread agreed on the cause. One commenter said zipping normally leaves file metadata alone and suspected an earlier copying step, while others said Core eDiscovery, which does not zip SharePoint documents, had served them for years without trouble, and one team reported collecting 4x faster with it in a rough comparison.

The disagreement matters less than the result. A date filter run on that field culls by export day, not by conduct.

It is a little like a postmark, which tells you when a letter passed through the sorting office and nothing at all about the evening it was written. No one would date a letter by its postmark. Yet a date range built on a rewritten Item Date does something very close to that.

Email vaults that split and reassemble messages

A subtler version lives in email. Attachments turn up in productions bearing dates after the email that carried them was sent, a sequence that makes no sense until one learns that some archiving vaults strip messages apart for storage and recombine them on retrieval, leaving each attachment with fresh file-system dates the vault never corrects. Processing tools that build a primary date from a ranked list of fields, with file-system modified high on that list, then surface the wrong one. Where the exchange protocol carries only a single date field and no separate sent date, the misleading attachment date is the one opposing counsel sees. Linked cloud attachments set a second trap, because the collection tool follows the link to the latest version of the document rather than the version as sent.

Deduplication that keeps one date and discards the rest

The third mechanism is quieter still. A 2020 r/ediscovery post observed that Nuix and Relativity normally deduplicate on file content alone, not on filename or date. Office documents carry their create and modified dates inside their content, so those survive; text files and PDFs stripped of metadata depend on the file system, so when duplicates are suppressed, the dates and filenames of the discarded copies can vanish. The same poster noted that DOJ production requirements include a Custodian Append File, yet "All Filenames" and "All Dates" fields are generally not requested.

In practice, the surviving date belongs to whichever copy the tool happened to keep.

None of this is visible from the field alone. It becomes visible only when someone sets the date beside the collection path, the parent email and the document's own content, the kind of patient cross-checking that manual review prices out of a small matter. Relevant e-Discovery runs AI-assisted review at cents per document, against the dollars per document and roughly $19K/GB of manual review, which makes that comparison affordable across a whole collection rather than a hopeful sample. The collection path still has to be sound, and forensic imaging is not a job for your IT person, since a careless copy can rewrite the very date you mean to defend.

Which leaves the firm holding a production with a practical question: how to test a date before staking a filing on it.

How Can a Small Firm Verify Metadata Before Relying on It?

Preserve hashed, unaltered originals with a documented chain of custody, then corroborate every date and author against the document's content, its parent email and the collection path before it reaches a filing.

Once all three fields are suspect, the question for a small firm is no longer whether to trust metadata but how to prove which dates and authors are real without a forensic budget. I would not begin with software. I would begin with sequence, because most of the damage described above happens in the first hours of handling, when someone opens a native file or drags a folder onto a new drive, and no later diligence can recover what that moment overwrote.

The American Bar Association's GPSolo magazine made the point plainly in 2024: opening a native document risks "inadvertently altering its metadata," while a review platform's near-native view shows the document as it appears in its original format without opening it at all. The same article recommends the scheduling conference "mandated by Federal Rule of Civil Procedure 26(f)" as the natural moment to settle the nature, volume and mechanics of ESI production.

From those two points, a workable order of operations follows:

1. Freeze the originals first. Collect forensically, hash each file, and review in near-native form so that no one's curiosity becomes an edit.
2. Settle the fields at the Rule 26(f) conference. Agree on form of production and on which metadata fields will be exchanged, including which source fills each date field, while both sides are still cooperating.
3. Corroborate before you cite. Pair each date or author with at least one independent witness: the text of the document, the parent email, the custodian's account or the collection log.
4. Ask before you accuse. When a production carries impossible values, request a few natives and an account of the collection path before drafting any motion.

The third step is where most timelines are won or lost, and a paired example shows the difference.

Before: "The pricing memo was written by the sales director on the date shown in Date Created."

After: "The pricing memo carries the sales director's name in the Author field and a Date Created consistent with the export; its text describes the meeting recorded in the parent email, which the custodian confirmed."

The second version claims less and survives more. It survives because no single field is asked to carry the whole weight.

Contrary to the instinct that an impossible date means someone lied, the law asks for considerably more. Plaintiff Magazine's guide to spoliation motions sets out the three elements from Victor Stanley II: a duty to preserve when the evidence was destroyed or altered, a "culpable state of mind," and relevance. The proof in that case was not an odd timestamp but an executive deleting files just before his computer was imaged, followed by a defragmenting program that made them unrecoverable. Microsoft's Director of Discovery Programs recommended a habit a small firm can borrow, searching known data for things you expect to find before trusting results you cannot predict, and for dates that means first checking a handful of documents whose real history you already know. It is not yet an accusation.

This is where I think tooling earns its place, not by deciding which date is true but by keeping every conclusion tethered to the document that supports it. In Relevant e-Discovery, every answer links back to the exact exhibit it came from, so an attorney can verify it with one click before filing, which is the structural answer to the sanctions risk that Mata v. Avianca made familiar. The ABA article asked how a lawyer can explain the significance of metadata to a jury without understanding it first, a question that sits close to the heart of how e-discovery can make you a better lawyer.

What remains is to set the three fields side by side, and to say plainly which of them can bear weight and which can only point the way.

How Does Metadata Hold Up When Opposing Counsel Challenges It?

Metadata holds up when it is offered as corroboration, traced through a documented collection path and matched against content, custodians and parent emails, rather than presented alone as proof.

When opposing counsel presses on a date, the answer that holds is one tied to custody, which is why Relevant e-Discovery keeps Bates numbering, privilege calls and chain of custody in the same tool as its cited answers and chronologies, rather than splitting them across two. As Kelly Twigger said in 2025, "You need to be able to recreate that timeline," so write a one-page account of each disputed file: who collected it, with what tool, and when it was hashed. That is a modest standard. It is also an unforgiving one.

Many states have adopted the ABA Model Rules on digital and electronic evidence, and an ABA practice guide for solos and small firms concluded that "the days of lawyers choosing how to navigate these challenges have ended." The comment to Model Rule 1.1 already asks lawyers to keep abreast of "the benefits and risks associated with relevant technology," and a Date Created value read as a birth date, when it records only the day a copy landed, sits squarely among those risks. Competence now includes knowing what a field cannot prove.

The questions that follow take up the narrower cases a small firm meets most often, beginning where most challenges begin, with a date that seems to say too much.