# How to Track Changed Decisions and Renegotiated Commitments

> Track changed decisions without confusing proposals with agreements. Preserve accepted terms, unchanged obligations, effective dates, and the reason for change.

- URL: https://www.hemory.com/blog/searchable-memory/track-renegotiated-commitments/
- Language: English (en)
- Author: Hemory Team
- Published: 2026-11-02
- Last updated: 2026-11-02
- Summary: Distinguish proposed revisions, accepted changes and current instructions. Record affected terms, acceptance, reasons and effective timing, preserving obligations that did not change. Use available Hemory context with a supported agent to explain the transition, then maintain a usable working record through the normal process.
- Tags: decision changes, commitments, project decisions

A search returns an old promise to deliver the full package on Thursday and a later discussion about splitting the delivery. Before telling the customer what to expect, you need to know whether the split was accepted, which parts moved, and what still applies.

Keep the earlier agreement available as history and make the accepted change clear in the current work record. A later statement is not automatically a replacement: it may be a proposal, a change for another audience, or an agreement that takes effect in the future. Useful conversation memory helps you retrieve those relationships without blending them into one inaccurate answer.

## TL;DR

- Separate the original agreement, a proposed revision, an accepted change, and the current instruction.
- Record what changed, why, the relevant acceptance, and when the change applies.
- A partial renegotiation changes only the terms it addresses; keep unchanged obligations visible.
- Hemory preserves captured discussions so you can recover how a change was discussed and use that context in a supported agent draft.
- Put the accepted terms in the working record people use, with enough history to explain the change.

## A newer mention is not necessarily a new agreement

A project discussion may contain several kinds of statements: “Could we move delivery?”, “I can accept Friday for the diagrams,” and “The installation date stays the same.” They do not all change the same part of the plan.

To interpret a revision, establish the work item, the affected terms, and whether the relevant people accepted it through the applicable process. An edit date or a speaker's seniority alone is not enough.

A later request for a different customer group may coexist with the earlier agreement. A proposal may be rejected. A decision may be withdrawn without an immediate replacement. These cases do not fit a simple rule that the latest version always wins.

If acceptance itself is disputed, first use the [client commitment clarification guide](/blog/searchable-memory/client-commitment-disagreements/). Record the revised terms once the applicable agreement is established.

Start with the actual relationship between records, then use labels that help communicate it.

## Keep history and the current instruction distinguishable

Useful status language can be simple, but it should describe the situation accurately.

| Description | What it means for the reader |
|---|---|
| Proposed change | A revision has been discussed but acceptance is not established |
| Accepted change, effective now | The revised terms apply within the stated scope |
| Accepted change, effective later | The revision is agreed, but the earlier arrangement may still apply until the effective point |
| Partly replaced | Specified terms changed; other parts of the agreement remain applicable |
| Cancelled | The obligation or choice ended within the stated scope, with no replacement necessarily implied |
| Current status unclear | Available sources do not establish which arrangement applies |

These are explanatory distinctions, not a required set of Hemory interface states. A sentence in a task or project note can communicate them without a separate version-control system.

An old entry is not false merely because the plan changed. It describes an earlier agreement. Preserve useful reasoning and identify the replacement or cancellation where needed so a reader finding the earlier item can understand its status.

## Capture what changed and what stayed the same

A concise revision note should answer the questions that affect action:

```text
Work item and scope:
Earlier agreement:
Accepted change:
Reason for the change:
Acceptance and source:
Effective from:
Terms that remain unchanged:
Remaining question or next action:
```

Use the fields the case needs. If the effective time was not established and it matters, make that a question instead of inventing a date. A named participant does not automatically establish decision authority; use the actual acceptance and responsibilities relevant to the work.

Hemory can preserve the exchange where these details emerge. You start listening to the real-world discussion, then return to its transcript and organized Memory afterward. This is useful for revisions made in a short follow-up conversation that might otherwise be summarized only as “delivery changed.”

The captured background reduces the need to reconstruct who accepted which term. The working note still needs to state what the people carrying out the task should do now.

For a shared explanation that will be reused by the team, follow the [team wiki entry workflow](/blog/searchable-memory/conversation-context-to-wiki/).

## An example: one deliverable moves while the other terms stay the same

In this illustrative example, the original agreement was to send an installation guide and wiring diagrams on Thursday, with installation scheduled for the following Monday.

In a Tuesday discussion, the supplier proposes sending the guide on Thursday and the diagrams on Friday because the connector list needs revision. The customer accepts that split delivery and confirms that Monday's installation date remains unchanged. The current project note records this accepted change; it does not yet record either file as delivered.

A useful revision entry is:

| Field | Entry |
|---|---|
| Earlier commitment | Guide and diagrams due Thursday |
| Accepted change | Guide remains due Thursday; diagrams move to Friday |
| Reason | The connector list needs revision |
| Acceptance | Customer accepted the split delivery in Tuesday's discussion |
| Effective from | The accepted revision governs this delivery |
| Unchanged | Installation remains scheduled for Monday |
| Current delivery status | Not established by the supplied records |

The answer to “What are we sending Thursday?” is the guide. The answer to “Did the installation move?” is no change was agreed to that date. Whether either file has already been sent requires a delivery record or later update.

A draft follow-up could say:

> As agreed on Tuesday, the installation guide is due Thursday and the wiring diagrams Friday, allowing time to revise the connector list. Monday's installation date remains unchanged.

That message states the agreed plan. It does not announce completed delivery or imply that every term was renegotiated.

## Distinguish the discussion date from the effective date

A change can be discussed one day, accepted later, and take effect after that. The date on a transcript identifies the discussion; it does not necessarily identify when the new instruction begins.

For example, a team may agree on Monday that a new support arrangement begins the following month. Until then, the existing arrangement can remain applicable. An answer that reports only the newest agreement would miss what the reader should do today.

When timing matters, retain the relevant acceptance and effective dates. You do not need multiple date fields for a simple immediate change, but you do need to preserve a future start or condition that alters action.

If sources disagree, compare scope and actual acceptance before using chronology to order them. The later timestamp helps locate the event; it does not resolve the disagreement by itself.

## Ask for the current terms and the change behind them

For a known Hemory conversation, ask follow-up questions about the revision discussed there. For a question spanning several exchanges, a supported connected agent can retrieve available Hemory context and prepare a comparison.

```text
Explain the current delivery agreement using the available Hemory
installation discussions and the current project note I provide.

Separate the original terms, proposed revisions, and changes that were
accepted. State which deliverables or dates changed, what stayed the same,
and when the revised terms apply. Keep delivery completion separate from
the agreed schedule.

Provide the current instruction first when the sources establish it,
followed by the short history needed to explain the change. If acceptance
or effective timing is unclear, identify the precise question to confirm.
```

You do not have to prebuild the entire revision chain before making this request. Supply the task and current external records, then check the transitions that affect the answer.

If the request is historical—“Why did the diagrams move?”—give the reason and relevant change. If it asks what applies today, lead with the applicable terms and timing. The answer should follow the question rather than always hiding history or always reproducing every version.

## Update the working record without rewriting the past

Put the accepted terms in the task, account note, or project page people already use. Include the important condition and make it clear that an earlier term was replaced. A reference back to the earlier agreement can help explain the change; an accessible forward pointer can help someone who finds the old entry first.

Where supported, a link from the old entry to the revision can help readers find the current terms. Otherwise, include a clear revision note with accessible supporting records. Do not edit an original transcript to make it sound as though the revised terms were agreed from the beginning.

Keep personal Memory and shared instructions separate. Share the relevant explanation or permitted excerpts through the team's normal workflow. Hemory capture does not automatically update a tracker, notify everyone affected, or establish team access to a personal record.

Update the current instruction when an accepted change becomes known, and retain the history needed to explain the transition through your existing information-management practices.

## FAQ

### Does the latest dated statement always override an older agreement?

No. It may be a proposal, apply elsewhere, or take effect later. Establish the relationship, scope, and acceptance before treating it as a replacement.

### How should I record a change to only one part of a commitment?

State the specific term that changed and the terms that remain applicable. For example, moving one deliverable to Friday does not automatically move another deliverable or the installation date.

### What if a commitment is cancelled without a replacement?

Record the cancellation, its scope, and the relevant acceptance or instruction. Do not invent a successor merely to fit a proposed/current/superseded model.

### What should I put in the current project record?

State the applicable terms, what changed, and any condition or future effective date. Use captured Hemory context to explain the transition, then put the useful explanation where people carrying out the work can access it.

Choose one agreement that changed recently. Use [Hemory](/features/) to recover the discussion, identify the accepted difference, and leave a current instruction that preserves both the new terms and the reason they changed.