Short answer
The date a file was uploaded says when your team received it, not when its facts were true. Keep four dates apart: receipt, source version, the period the fact describes and the owner's review. When sources disagree, keep both and let a named owner choose; the newest upload does not win.
TL;DR
- →Track when a file arrived separately from the period its information describes.
- →Use effective dates, source versions and owner decisions to resolve competing facts.
- →Leave unknown timing visible instead of inferring it from file order.
On Wednesday, a client uploads a glossy profile saying the company has 18 regional offices. On Monday, the operations director approved a spreadsheet showing 16. The profile is the newer upload, so the writer uses 18 in a press release. Later the team discovers that the profile was designed nine months earlier for an expansion that changed. The rule that prevents it: keep the date a file arrived apart from the period its facts describe, and let a named owner, not the upload order, decide which fact is current.
The upload timestamp answers when the communications team received a file. It says nothing by itself about when the contents were true, whether they remain true or which definition produced them. Treating recency of receipt as recency of fact can make an old document silently overrule a current decision.
Which dates should a fact record keep?
Four: when the file arrived, when the source was issued or revised, the period the fact describes and when an owner reviewed it for this use.
Receipt date
When did this workspace receive the file or statement? This helps with lineage and handoffs. It cannot establish the period described inside the material.
Source date and version
When was the document created, issued or revised, and which version is it? If the document lacks a reliable date, record that gap instead of substituting the upload time. The Dublin Core metadata standard keeps these apart too, with separate terms for the date a resource was created, formally issued and changed1.
Relevant or effective period
When was the assertion true or intended to take effect? A report issued in April can describe results through December. A policy signed today may begin next month. Store a range or boundary where a single date would mislead. Dublin Core has a separate term for this as well: the date, often a range, during which a resource is valid1.
Review and decision date
When did an authorized owner assess the fact for the intended use? A recent review improves visibility but does not rewrite the historical period of the source.
How do you check whether a fact is still true for the draft?
Write the claim with its time meaning exposed, ask the owner whether it is a snapshot, a total, a forecast or a standing policy, and check its definition as well as its date. Reporters are watching for exactly this: 72% told Cision's 2025 State of the Media survey they worry about factual errors in AI-generated PR content2. A date is one of the notes to read before you use a number.
Write the proposed claim with its time meaning exposed. “The company has 18 offices” is a current-state assertion on the publication date. “The company planned to reach 18 offices by June” describes a plan at an earlier point. Those sentences can come from the same source and require different evidence. Published copy needs its own dates for the same reason; the BBC’s guidelines say it should normally be clear when content was first published and, where relevant, when it was last updated significantly3.
Ask the owner whether the fact is a snapshot, a period total, a cumulative figure, a forecast or a standing policy. Check definitions as well as dates. One document may count staffed offices while another includes partner premises. A date match cannot reconcile a scope mismatch, and figures that share a name but differ in scope need their own check.
When facts conflict, keep both records and describe the precise disagreement. Do not overwrite the earlier one or choose the latest upload automatically. Ask the responsible owner to accept one for the current assertion, retain both with distinct scopes or hold the claim pending clarification. That is the same explicit old-and-new decision used to keep company facts up to date without losing their history.
QuoteIt records facts the same way. Each one keeps the period it describes beside its source passage, apart from when the file arrived, and when a newer source disagrees with a fact already held, a person decides between them; the earlier value stays in the fact's history rather than being overwritten.
How do you resolve two dated sources that disagree?
Lay out each source's receipt date, revision date and effective period side by side, then ask the owner which fact holds for the current claim; the newest upload does not win by default.
Consider a fictional food distributor. A brochure uploaded April 8 says it serves 40 towns. Its file metadata identifies a January 15 revision. The page gives no effective date. An operations note issued March 30 says deliveries currently reach 36 towns and four proposed routes await approval. These details are invented to illustrate the method.
The chronology should record: brochure received April 8; brochure revision January 15; brochure fact period unknown; operations status effective March 30. It should also record the different wording and the owner asked to resolve it. The recent upload does not displace the later-dated operational status.
If the owner confirms that deliveries currently reach 36 towns, current copy can use that approved fact. Keep the four proposed routes as separate planning information; their count does not establish how many towns they would serve. The 40-town statement remains part of the record with its uncertain timing and rejected current use, which is how you retire a fact from current use while keeping its record. If a historical article needs to describe the January plan, the brochure might still be relevant after its meaning and permission are checked.
What should you do when a fact has no date?
Mark the date unknown, name who will clarify it and show which drafts depend on the answer; never borrow the upload date to fill the gap.
A missing effective date is information. Mark it unknown, assign a clarification owner and show which drafts depend on the answer. When the answer sits with the client, frame the request so a busy client can answer it quickly. For urgent work, the release owner can narrow or remove the claim. Inventing a date from context makes the record look complete while weakening it.
Add review triggers for facts that change after appointments, openings, reporting cycles or policy decisions. The extra fields require maintenance, so reserve detailed tracking for reusable or material claims. A chronology that leaves an effective date visibly unknown is more reliable than a tidy record that borrows the upload date.
Is the upload date the same as the date a fact was true?
No. The upload date says when your team received a file. The fact's period comes from the source itself, and a recent file can describe a situation that has since changed.
Which source wins when two documents disagree?
Neither by default. Record both, describe the exact disagreement and ask the responsible owner to choose the current fact, keep both with distinct scopes or hold the claim.
What if a document has no date?
Record that the date is unknown and assign someone to clarify it. For urgent work, narrow or remove the claim rather than inferring a date from context.
Should published copy show when it was updated?
Where relevant, yes. Readers and journalists need to know when a statement was first published and when it last changed significantly, especially for facts that move.
Sources
Numbers in the text point here. Each link opens the original page.
- 1DCMI Metadata TermsDublin Core Metadata Initiative, 2020-01-20
- 2Cision's 2025 State of the Media Report Reveals a Tipping Point for Trust, Technology, and PR-Journalist PartnershipsCision, 2025-05-07
- 3Section 13: Use of BBC Content After Publication or Broadcast - GuidelinesBBC
Written by
Shubham Kukrety, Founder and CEO, QuoteIt
Shubham Kukrety co-founded QuoteIt to fix the part of PR writing that ends in a long mail trail: facts that drift between the source document and the published statement. QuoteIt drafts press releases, spokesperson quotes, bylined articles and answers to journalists from a team's own documents, in each spokesperson's own voice, and shows every claim beside the passage it came from before anyone signs off.
How these posts are researchedUpload your company profile and latest figures to QuoteIt. Each fact keeps the period it describes beside its source, so an old brochure cannot quietly overrule a current number.
Join the Pilot
