# How to Reconstruct a Timeline of Project Deadline Changes

> Trace project deadline changes across conversations. Separate proposals from accepted dates, preserve scope and reasons, and explain the established plan.

- URL: https://www.hemory.com/blog/searchable-memory/deadline-change-timeline/
- Language: English (en)
- Author: Hemory Team
- Published: 2026-11-04
- Last updated: 2026-11-04
- Summary: A workflow for reconstructing a project's deadline history from available records and captured conversations. It separates warnings, proposals, accepted changes, conditional rules, scope splits, and completion. A five-record example produces a clear timeline and current-plan explanation. Hemory and supported connected agents can retrieve and draft from accessible discussion context without a preassembled manual timeline.
- Tags: deadline changes, project timeline, decision history, project updates

You need to explain why a project deadline changed, but the notes contain several dates: the original target, an early warning, a proposed extension, and a later rollout plan. Putting them in date order is not enough. You need to know which dates actually became the plan.

Build the timeline around one milestone and its scope. Separate accepted changes from forecasts and proposals, keep the reason attached to each change, and finish with a clear statement of the latest established plan.

## TL;DR

- Identify the deliverable or milestone before comparing dates. A pilot date and a full-rollout date can both be correct.
- A warning or proposed extension is relevant history, but not automatically a deadline change.
- Keep the conversation date, the date a change was accepted, and the delivery date distinct when they differ.
- For discussions captured in [Hemory](/features/), a compatible AI agent connected to Hemory can help retrieve and draft the timeline before you manually assemble every excerpt.
- Report the current plan separately from actual completion. A past promise does not establish that delivery happened.

## Start with the milestone, not every date in the project

State the question you need to answer: “How did the customer rollout deadline change?” gives you a useful boundary. If the project later split into a pilot and a wider release, preserve that change in scope rather than forcing both into one date.

Use the records already available. An approved plan or well-maintained decision log may establish the main changes. Return to conversations when you need the reason, the conditions, or the relationship between competing dates.

You can begin with a project name, a remembered date, or a likely review meeting. Add a time boundary when it helps answer the question, and widen it if a result points to an earlier change.

## Distinguish a changed deadline from a discussion about one

| What the record says | How it belongs in the history |
|---|---|
| “Testing may run late.” | Warning; no new deadline established |
| “Could we move delivery to November 27?” | Proposed change; look for the response |
| “Move delivery to November 27.” | Accepted change if made through the relevant authority or process |
| “Keep November 27 for the pilot; release to everyone else on December 4.” | Separate dates for different scopes |
| “We approved the extension last Thursday.” | A report of an earlier acceptance; distinguish the report date from the reported decision date |
| “The release went out yesterday.” | Report of completion, not another planned deadline |

Someone with authority can still speculate or ask a question. Their role does not turn every date they mention into an accepted change. Conversely, a colleague may accurately report an approved change made elsewhere; follow the referenced approval when it matters.

Keep conditions attached to accepted changes. “If the review is not complete by November 19, move release to December 4” can be an approved contingency rule. It is different from an unaccepted suggestion to delay. Until the trigger is known, report the rule and the relevant uncertainty rather than choosing a branch yourself.

## Reconstruct the sequence from the available sources

Find the earliest useful baseline, then the exchanges that changed or qualified it. You do not need to include every repetition of the same date.

Look for the milestone, old and new dates, and the explanation for the move. Use wording found in the records to guide the next search. A summary that clearly records acceptance may be sufficient; an ambiguous “new target” may need the surrounding discussion.

If the conversations were captured in Hemory, its transcript and organized Memory give you access to the explanations behind short status notes. Hemory's built-in Q&A can retrieve across captured conversations. Ask which deadline changes were accepted and what scope each covered. If you are preparing the update in a compatible AI agent connected to Hemory, it can use the accessible discussion context to draft the timeline:

```text
Build a timeline of customer-rollout deadline changes from the relevant
Hemory discussions you can access.
Separate warnings and proposals from accepted changes. Preserve the
milestone scope, reason, conditions, and source for each relevant event.
Distinguish when a change was reported from when it was accepted if the
record gives both. End with the latest established plan and any precise
gap that prevents identifying it. Do not infer completion from a date.
```

Provide a newer approved plan separately if the agent cannot access it. The agent can retrieve and draft from the captured context; you do not have to prepare a verified timeline before it can help build one.

## Example: five records, different kinds of change

This fictional project illustrates the method, not a customer result or Hemory output. You are preparing a November 4 update; the reviewed records contain the following events and no later accepted change:

| Discussion date | What the record establishes | How to represent it |
|---|---|---|
| October 2 | Approved plan: customer rollout on November 20 | Baseline |
| October 9 | Engineering warns that testing may need more time | Risk to the baseline; no changed date |
| October 16 | A participant proposes November 27; the decision is deferred | Proposed extension |
| October 20 | The authorized project review approves November 27, allowing another week for testing | Accepted change from November 20 to November 27 |
| October 29 | The authorized review keeps the pilot on November 27 and moves the wider rollout to December 4 to complete accessibility checks | Accepted scope split; different dates for pilot and wider rollout |

The useful explanation is:

> The original customer-rollout date was November 20. The October 20 review moved it to November 27 to allow another week for testing. On October 29, the plan split: the pilot remains November 27, while the wider rollout moves to December 4 for accessibility checks. These are the latest accepted dates in the records reviewed for the November 4 update.

October 9 and October 16 explain how the issue developed. They should not be counted as additional accepted deadline changes. The final row does not mean the pilot moved to December 4, and none of the records establishes actual delivery.

## Keep the final timeline usable

A compact working format is enough:

```text
Milestone and scope:
Period and sources reviewed:

Event date / source date, if different:
Previous accepted plan:
Proposal, accepted change, or other event:
New date and scope, if accepted:
Stated reason and conditions:
Source reference:

Latest established plan:
Remaining question, if any:
```

Include the source or acceptance distinction only where it affects interpretation. Do not fill the table with guessed approval dates, invented reasons, or a confidence score that blends uncertainty with decision status.

If a later meeting repeats the same change, add it as supporting context when useful. If it changes the scope, condition, or effective timing, record that difference. A later mention is not automatically a replacement.

Check the entries that determine the final plan and the reason for each accepted move. If two records conflict, identify the exact point requiring clarification. An empty interval in the timeline does not prove that no conversation happened during it.

The finished update should state the usable plan directly. Readers should not have to open a private transcript to discover which audience or condition a date applies to.

[When a new decision replaces an old one](/blog/searchable-memory/when-decisions-are-replaced/) covers accepted dates that take effect later. For the update itself, [report a delayed deliverable](/blog/searchable-memory/report-delayed-deliverables/) using the current plan and actual progress separately.

## FAQ

### What if I only find a later report of the change?

Record it as a report and preserve any stated earlier acceptance date. Follow its source if the distinction affects the task. Do not silently treat the later meeting date as the approval date.

### Should a missed deadline appear in the same timeline?

It can, but label actual progress or completion separately from the plan. A date passing does not by itself show whether delivery occurred or whether a new deadline was accepted.

### Do I need to trace every date ever mentioned?

No. Include what explains the relevant milestone and current plan. Keep a proposal or warning when it clarifies the history, not merely because it contains a date.