In docProps/core.xml, every docx carries two timestamps:
<dcterms:created>— when the document was first created.<dcterms:modified>— when the document was last saved.
These are among the first fields a forensics report surfaces. They look interchangeable but aren't. The relationship between them tells a specific story about how the file came together.
How each one is set
created
Set when the .docx file is first created on disk. This is not when the writing started; it's when the underlying file came into existence. Specifically:
- New blank doc in Word. Set to the moment the user typed in the new file.
- "Save As" from an existing template. Set to the moment the save dialog completed; the template's original creation date is overwritten.
- Google Docs Download-as-Word. Set to the moment of export.
- Copy-of via Finder / Explorer. Set to the moment of file-copy (NOT inherited from the source file's
createdtimestamp). - macOS Pages → Export to Word. Set to the moment of export.
The field is rarely edited by the document's content tools after first creation. Most word processors don't touch it on subsequent saves.
modified
Set on every save. Updates each time the file is written to disk:
- Manual save (Cmd-S / Ctrl-S).
- Autosave by Word's background autosave engine.
- Any tool that opens the file, performs an edit, and re-saves.
- Some converters that re-emit the file even without content changes.
The granularity is seconds.
What the relationship tells you
created ≈ modified (within a few seconds)
The file was created and never re-saved. Plausible scenarios:
- The student exported from another tool (Google Docs, Pages) and submitted immediately.
- The student typed a one-shot reflection in a single sitting without saving more than once.
- The file came from a paper-mill or AI tool that generated it and was submitted without further editing.
This combination, plus TotalTime: 1 (covered in the EditingDuration field guide) plus revision: 1, is the strongest "minimum-handling docx" pattern in forensics. None of the three is conclusive alone; together they're highly diagnostic.
created ≪ modified (hours, days, or weeks apart)
The file was created earlier and re-saved multiple times. Plausible scenarios:
- Normal student work: started Monday, finished Friday.
- The student used a template the instructor provided weeks ago.
- The file passed through several drafts.
This is the modal pattern for authentic student work on long-form assignments. The gap should roughly match the assignment's window.
created > modified (impossible — created is later than last-modified)
This pattern shouldn't occur. When it does, it indicates one of:
- The system clock was wrong on the workstation that wrote the file.
- The file was edited by a tool that doesn't update
modifiedcorrectly. - The metadata block was manually edited.
Treat as suspicious.
created far in the past, modified recent
A file with created: 2014-09-03 and modified: 2026-05-12 is interesting but not necessarily suspicious — common sources include:
- The student used a template from a previous semester or course.
- The student inherited a workstation with old templates pre-installed.
- A document-management system or LMS converted/re-wrapped the file at submission time.
What's worth checking: does the rest of the metadata match? An old created paired with new lastModifiedBy paired with an instructor-template-style file is consistent with template re-use. An old created paired with a fresh creator field is more puzzling — ask.
Common misreadings
"The created date is right before submission, so it must be cheating"
Could be Google Docs export. Could be a copy-of. Could be the student starting and finishing the same day. Check Google-Docs-style metadata patterns (see why Google Docs exports look different) before drawing conclusions.
"The dates don't match my assignment window"
Less common, but possible. Reasons:
- System clock drift on the student's machine (uncommon now that all OSes auto-sync, but happens).
- The student worked offline for a long stretch and the clock was wrong when they saved.
- The file was authored by someone else and they handed it off — the dates reflect that workflow.
Worth asking about. Not by itself an answer.
"The modified date keeps changing on me"
If you have the same file and the modified date appears to shift, the LMS or your local environment may be re-saving the file when you download or preview it. Hashes don't lie about content; metadata can shift on round-tripping. When in doubt, check the SHA-256 hash.
What Autotend Forensics surfaces
The metadata signal-set reads:
createdvsmodifiedproximity (within minutes → flagged as low-severity timeline observation).createdaftermodified→ flagged as structural anomaly.createdoutside the assignment window → flagged for review in the per-paper rolling baseline.
These feed into the broader metadata signal layer along with the EditingDuration and lastModifiedBy fields.
Bottom line
created and modified are a pair of fields, not standalone signals. Read them together with TotalTime, revision, and lastModifiedBy to get a coherent story. A single suspicious-looking timestamp is much weaker evidence than a pattern across all five fields.
For the full metadata methodology, see the metadata signals page.