When Does a New Decision Replace an Old One?

The team has approved moving new requests from email to a portal. A project note now marks email “obsolete,” but the change starts next month and requests already in progress will remain in email. The label could send someone to the wrong process today.

A new decision replaces an old one only within the scope and timing established by the accepted change. Record what was replaced, when the replacement applies, and which work remains under the earlier instruction. Approval, effective date, and implementation are related facts, not the same fact.

Establish that a replacement was actually accepted

Start with the outcome, not just the latest date. A proposal to use a portal, a newer draft, or a question about the current process does not by itself replace the accepted approach.

Find the decision-maker or process that accepted the change. Then identify the earlier choice it affects. Similar project names may conceal different audiences, phases, or workstreams.

An option rejected for a pilot may later be accepted for another phase. That is compatible history, not a contradiction. For the broader distinction between unselected options, see recording rejected and deferred options.

Keep acceptance and effective timing separate

A change accepted on October 28 may take effect on November 15. The earlier process can remain the instruction for current work until that date.

Use precise descriptions:

Do not use a guessed start date to complete the note. If execution depends on readiness checks, keep those visible too. An accepted plan does not establish that a technical rollout has already happened.

Check whether the replacement is partial

Identify the work covered by the change. “New requests from November 15” and “all requests” are different instructions. Work already in progress may need to continue under the earlier process.

Keep exceptions beside the main rule. A source link is helpful for background, but the person doing the work should not have to open a personal transcript to discover that their case is excluded.

The historical reason remains useful as well. A later replacement does not mean the original choice was a mistake; it may have fit the resources or timing of that phase.

Example: an accepted change has not yet taken effect

The following fictional example illustrates a project instruction, not a real system or Hemory output.

For a planning note prepared on November 4, the supplied decisions support this summary:

Current instruction: Continue using email before November 15.

Accepted replacement: Use the portal for new requests from November 15.

Exception: Requests already in progress at the transition remain in email.

Historical basis: Email supported the pilot because the portal was not ready for that phase. The later review accepted a change for the stated scope and date.

This describes the accepted instructions. It does not prove that the portal has been deployed or that old requests have been migrated. Check current implementation evidence when your task requires it.

A bare “email superseded” label would lose both the future effective date and the continuing use for existing requests. “Superseded for new requests from November 15” preserves the useful limit.

Recover the change with Hemory and draft a dated note

Use an existing decision or approval document when it already explains the transition. If a short note omits scope or timing, return to the supporting exchange.

For a conversation captured in Hemory, follow-up Q&A can help locate what was accepted and when it was intended to apply. If the change developed across several discussions, a compatible AI agent connected to Hemory can help draft from available context:

Prepare a transition note for the request process as of November 4.
Use available Hemory discussions and the current approval or implementation
updates I provide.

Identify the earlier choice, the accepted replacement, its effective date,
and the work covered. Keep exceptions for existing requests explicit.
Separate a future instruction from evidence that it has been implemented.
Do not treat a new proposal as an accepted change.

Include source references and flag any timing or scope not established.

Provide external updates separately when the connection cannot access them. The agent can help assemble the relationship between decisions before you manually reconstruct the whole sequence.

Keep a transition note people can use

Earlier instruction and its scope:
Accepted replacement and basis for acceptance:
Effective date or condition:
Work covered by the change:
Cases staying under the earlier instruction:
Current implementation information, if needed and established:
Instruction as of the date of this note:
Source references and remaining question:

When a later accepted change moves the date or alters the exception, update the current instruction and identify that source. Preserve the earlier explanation so someone reviewing past work can understand what applied then.

For changes to promises rather than a process choice, see tracking renegotiated commitments.

FAQ

Does a newer document automatically replace the earlier decision?

It may replace a document version. Establish whether it also records an accepted change to the decision. Keep the document status and decision status distinguishable.

Should I delete the earlier decision?

Keep enough history to explain earlier work, while making the current instruction prominent. The old rationale can remain useful after its approach stops applying to new work.

What if the replacement is accepted but the start date is unclear?

Identify that gap and obtain the timing needed for the task. Do not infer immediate effect merely from the date of the acceptance.

Use Hemory to preserve the discussion behind a change while you focus on the choice. Later, a dated transition note can tell people which instruction applies to their work without losing the history behind it.