When a project lacks a reliable timeline, the evidence often still exists in meeting notes, messages, document versions, and approval records. The challenge is to distinguish when something happened from when someone wrote about it. Sorting files by modification date cannot answer that question on its own.
This guide uses ChatGPT to draft an event timeline with evidence references, unresolved dates, and clear gaps. It provides an original reconstruction method rather than a claim that missing records can always be recovered. Examples are fictional, and current capability documentation was checked on October 6, 2026. A project owner must review the resulting chronology.
Define the reconstruction question
Specify the project, period, and reason for reconstructing the timeline. A chronology of approvals has different inclusion rules from a chronology of implementation milestones. State whether the review needs exact dates, an approximate order, or the dependencies between a small set of events.
Identify the information cutoff and authorized sources. A later retrospective can help explain an earlier event, but it should remain labeled as a retrospective account. Do not treat it as contemporaneous evidence merely because it describes the relevant period.
Avoid framing the task as proving a predetermined explanation. “Show that the delay started with Team A” invites selective extraction. Ask what the supplied records establish, where they disagree, and which events remain undocumented.
Create a source register
Give each record an ID and capture its title, author or originating system, document date, relevant version, and accessible location. Preserve the original timezone where it exists. Note whether the timestamp describes creation, modification, sending, approval, or the event itself.
OpenAI's projects reference describes keeping related sources and chats together. A reconstruction packet can use that organization, but the reviewer must still confirm which records are present. A project container is not evidence that every relevant conversation has been collected.
Check that exports include quoted messages, attachments, and revision context needed for interpretation. A message saying “approved” may refer to an earlier attachment that is missing from the export. Mark that missing dependency instead of assuming which version received approval.
Extract event candidates with separate dates
Ask ChatGPT to list candidate events before arranging them into a narrative. Each candidate should include what happened, the supporting passage, the event date claimed by the source, and the source's own date. Keep those date fields separate even when they happen to match.
| Candidate field | Why it matters |
|---|---|
| Event ID | Stable reference across revisions |
| Event description | Bounded account of the documented action |
| Event date or interval | When the action is said to have occurred |
| Source date | When the supporting record was created or sent |
| Evidence location | Record ID and relevant passage |
| Date basis | Explicit date, relative expression, or unresolved inference |
| Review status | Confirmed by review, disputed, or incomplete |
A source timestamp may support ordering without proving an exact event time. For example, a Wednesday message saying a review happened “yesterday” can suggest Tuesday, but only after the relevant timezone and speaker context are checked. Preserve the original phrase and the transformation used.
Use a prompt that preserves gaps
Provide the source register and extraction schema. Instruct ChatGPT to avoid filling intervals with assumed work or converting scheduled milestones into completed events. A plan records intention; it does not establish that the planned action occurred.
Extract project events from the supplied dated records.
Separate event dates from source creation, sending, and modification dates.
Preserve the source ID, passage location, timezone, and original date wording.
Label planned, reported, approved, and completed events distinctly.
Do not invent missing events, owners, or precise dates.
Return event candidates, possible duplicate groups, and unresolved date conflicts.
After review, arrange approved candidates into a timeline with visible gaps.Review candidate coverage against the source list. Some records may contain no relevant event; mark that disposition. Others can support several events, and those should receive separate IDs rather than being compressed into a vague milestone.
Reconcile duplicates and conflicting accounts
Several records may describe the same approval. Group them when the action, subject, and version match, retaining all source IDs. Two approvals of different revisions are distinct events even if their wording is identical.
When accounts conflict, show the alternatives and their evidence. Do not assume the newest account is correct, or that the most senior author provides the strongest timestamp. Ask the owner for the missing approval record or another suitable source.
Use intervals when evidence supports only a range. “After the documented review and before the deployment notice” can be accurate without an exact date. An unresolved date is more informative than an invented timestamp that later becomes embedded in a report.
Work through a fictional sequence
A fictional packet contains a Monday plan scheduling review for Wednesday, a Thursday message saying the review finished, and a Friday approval record for revision R-3. The plan supports a scheduled milestone. The Thursday message supports reported completion by Thursday but does not independently prove Wednesday completion.
The Friday approval record can establish a separate approval event if its content identifies the approved revision. The timeline should not merge review and approval merely because both concern the same document. Their relationship may matter to understanding the project's sequence.
If a Saturday retrospective says implementation began earlier in the week, add a candidate with the broad interval and source context. Request supporting records if precision matters. Do not convert “earlier in the week” into Monday just to make the timeline look orderly.
Arrange the timeline without inventing causation
Sort supported events by their reviewed dates or intervals. Display uncertain events with their uncertainty rather than forcing a single order when intervals overlap. Use a short event description and a source link so readers can inspect the evidence.
Keep causal explanations separate from chronology. A delayed approval preceding a delayed launch does not alone prove that the approval caused the launch delay. Label any proposed explanation as an interpretation and identify the additional evidence needed.
Explain important gaps directly. “No supplied record establishes the implementation start date” describes the packet's limit. It does not mean implementation did not occur. Distinguish absence of evidence in the reviewed materials from evidence that an action never happened.
Review, approve, and retain the record
Ask the project owner to verify event identity, date treatment, version references, and completeness. Reviewers should identify supporting records for corrections rather than simply supply a preferred narrative. Retain their decisions and the revised timeline version.
If review comments conflict, the feedback ledger guide offers a way to connect requested changes with evidence and approval. Keep the original source packet unchanged while revising the derived timeline.
Save the approved timeline with its scope, cutoff, source register, and unresolved questions. Future records can improve the reconstruction, but updates should explain which events became better supported or changed interpretation. This makes the chronology useful for handovers and reviews without overstating what the evidence establishes.
Frequently asked questions
Can file modification dates establish event dates?
They establish a file timestamp, not necessarily when the described event occurred. Record the timestamp type and check the content.
Should planned milestones appear in the timeline?
They can appear when useful, but label them as planned and distinguish them from documented completion or approval.
What if the exact date is missing?
Use a supported interval or mark the date unresolved. Do not invent precision for the sake of a neat chronology.
Does an earlier event prove the cause of a later delay?
No. Sequence can inform analysis, but a causal explanation requires additional evidence and should be labeled separately.
How should later evidence change the timeline?
Review the affected event, retain the new source reference, and record the change in a new timeline version with its reason.
