Compare dates a report prints with dates the cited page actually shows

Treat each printed date as a claim, not a fact

A generated summary can state a date with the same confident tone it uses for everything else, even when the underlying page does not show that date. NIST's generative-AI guidance notes that these systems can present erroneous content that is inconsistent with their inputs, and it recommends verifying sources and citations in their outputs. So your first pass is mechanical: read the report once with a pen, and circle every date-shaped statement. Include obvious ones like "created in 2019" and quieter ones like "active last week" or "posts regularly on weekends," because those carry dates in disguise. Do not evaluate them yet; the goal is a complete list to check. [NIST AI 600-1: generative AI confabulation and source verification]

• Circle every date or time expression, including relative ones such as "last month" or "recently."
• Write the exact wording beside each circle so you can compare it later without relying on memory.

Record only what the cited page displays

For each circled item, open the specific public page the report cites. Scan it for the same kind of date and write down only what is visibly present: a join date, a post timestamp, an "edited" marker, a comment date. Note where it appears, such as under a username, beside a post title, or in a comment header. If the page is private, missing, or a different page than the one described, stop there and record that limit — do not look for another way in. A mismatch between the report's date and the page is itself a useful finding, not something to smooth over. [NIST AI 600-1: generative AI confabulation and source verification]

Sort findings into three columns

A simple table keeps observations, their limits, and decisions from blurring together. The left column holds what the page actually shows. The middle column names what that display cannot establish. The right column is what you will do next — usually keep, correct, or strike the report's claim. The example rows below are hypothetical.

Keep "date shown" separate from "person active"

A timestamp records when something was displayed or published, not when a person was present, reading, or truthful. An account creation date says the account exists from that point; it says nothing about who types today. Even AI analysis of public profile content produces interpretations about work, income, or relationships that remain unverified inferences rather than established facts. Write your notes so the date and any inference about activity sit in different sentences, and label the second one as a guess if you include it at all. [TraceSeek: product overview and operator-confirmed capabilities]

Handle missing, private, or ambiguous sources

When the cited page cannot be opened, is private, or does not match the report's description, the honest output is a recorded limit. Write something like: "Report claims posting date of March 2024; cited page inaccessible; unsupported." That sentence is more accurate than filling the gap from memory or from a different page. If the page exists but a visible date is ambiguous — an unlabeled number, a timezone-free timestamp — note both readings rather than choosing the convenient one. Never treat a badge, a privacy setting, or a matching photo as confirming any date or identity. [NIST AI 600-1: generative AI confabulation and source verification]

Close with a corrected date ledger

Finish by rewriting the report's date statements against your columns: kept dates keep their page location, corrected dates show the page value, and struck dates carry the reason. This ledger is your editorial record. It is not a platform test and does not prove what any tool will show next time, because public-page availability and displayed dates can change. [TraceSeek: product overview and operator-confirmed capabilities]

A couple more questions