Memory diffs

Memory diffs make changes to Memory reviewable. A diff shows what TOW wants to add, update, supersede, or archive before that change affects the workspace's trusted context.

Review memory diffs in Inbox or Memory Diffs when a document, chat, onboarding answer, project Check-In, or background job produces new facts.

Canonical state

A pending memory diff is not canonical memory. It is a proposal. The facts in a diff should not be treated as trusted workspace state until a reviewer approves the diff and the resulting memory is active.

When diffs appear

TOW may create a memory diff after:

• A doc is created, edited, restored, archived, or processed for memory extraction.
• A project Check-In includes facts that should be remembered.
• Chat produces a proposed memory update.
• Onboarding or other workspace intake creates baseline knowledge.
• TOW detects that existing memory may be stale, duplicated, or contradicted.

Diffs are intended to keep AI-assisted work auditable. They separate generated suggestions from accepted company knowledge.

Diff statuses

Diff statuses describe where a proposal is in the review process.

Status	Meaning
pending	Waiting for human review.
approved	Accepted and applied to memory.
rejected	Reviewed and not accepted.
auto_applied	Applied automatically because the system considered it safe. Review high-impact changes anyway.
partially_applied	Some proposed changes were applied, but others still need attention or could not be applied.
migrated_to_ai_inbox	Moved into Inbox or a newer proposal workflow for review.

The most important status is pending: it means a human should decide whether the change is true, useful, and scoped correctly.

What a diff can change

A memory diff may propose one or more changes:

• Create a new memory item.
• Update the title, body, type, tags, confidence, or importance of an existing item.
• Supersede one or more older memory items.
• Archive stale memory.
• Identify possible conflicts or review reasons.

For updates and supersedes, open the target memory item before approving. The same words can have a different impact depending on what they replace.

Review checklist

Before approving a memory diff, confirm:

• The proposed fact is true.
• The wording is specific enough to be useful later.
• The source is recent, relevant, and appropriate for the claim.
• The scope matches where the fact should apply.
• Confidence and importance are reasonable.
• The change does not duplicate active memory.
• The change does not silently reverse a decision, customer commitment, or technical constraint.
• Any superseded or archived memory should really stop influencing current work.

Reject a diff when it is speculative, unsupported, misleadingly broad, duplicated, or based on source material that should not become durable memory.

AI-generated content

TOW can extract and propose facts, but generated wording may overstate certainty or miss context. Review the source and edit the wording before approval when a diff affects strategy, customers, compliance, finances, security, architecture, hiring, or external commitments.

Reviewing creates

For a proposed new memory item, check:

• Is this fact durable enough for Memory, or should it remain only in Docs?
• Does the title summarize the fact clearly?
• Does the body include the specific constraint, assumption, or decision?
• Is the memory type useful for filtering?
• Are confidence and importance calibrated?

Approve creates when they add a durable fact the workspace should use again.

Reviewing updates

For an update, compare the current memory with the proposed wording.

Use an update when the same fact is being clarified, corrected, or made more current. If the business fact changed in a meaningful way, supersede the old memory instead so the history remains understandable.

Good updates usually:

• Preserve the original meaning while improving clarity.
• Add missing evidence or qualification.
• Correct stale wording without hiding that the fact changed.

Reviewing supersedes

Use supersede when a newer fact replaces an older fact.

Examples:

• A target customer segment changes.
• A project status moves from active to paused.
• An architecture decision changes because the system direction changed.
• A risk is resolved by a mitigation plan.

Superseded memory no longer represents current state, but it remains useful for audit history and for understanding why recommendations changed.

Reviewing archives

Archive memory when it should stop guiding current work but should remain visible as history.

Archive is appropriate for:

• Stale project status.
• Outdated risks or blockers.
• Facts that were once true but no longer apply.
• Temporary operating context that should not be deleted.

Archive instead of deleting history

Archiving removes a memory item from current operating context while preserving history. Deleting or hiding source context can make later AI answers harder to audit. Prefer archive or supersede unless the information must be removed for policy, privacy, or legal reasons.

Project-scoped diffs

Diffs follow the project scope that produced them. If a doc or project Check-In was created inside a project, the memory proposal should usually stay inside that project.

Project scope

Review the selected project before approving a diff. A correct fact in the wrong scope can cause misleading answers: project-only facts may look company-wide, or company-wide facts may be invisible outside the project.

After approval

After approval, review the resulting memory if the change is high impact. Confirm the status, scope, confidence, importance, source quote, and any supersedes or superseded-by links.

If you approve a diff by mistake, correct the resulting memory directly: edit it, supersede it with the correct fact, or archive it.

Rejection patterns

Reject and move on when a diff:

• Repeats an existing memory item without adding value.
• Turns a short-term task into a durable fact.
• Treats an opinion as a confirmed decision.
• Infers strategy from weak evidence.
• Extracts sensitive or irrelevant detail.
• Proposes a broad company fact from a project-only source.

Rejection is part of keeping the workspace healthy. It prevents weak generated content from becoming trusted context.