Skip to content

Trust

Review and Trust

Understand how Origin keeps uncertain memory visible: pending captures, revisions, contradictions, rejections, confirm, and forget.

Qi-Xuan LuUpdated 5 min read

At a glance

01

Review is the trust layer between raw captures and context your future agent should rely on.

02

Use review for uncertain captures, pending revisions, or changing facts; use distill when related trusted memories deserve a readable page.

01

Review before trust

A useful memory layer should not silently trust every captured sentence. Some facts are low-confidence, duplicated, contradicted, superseded, or too vague to promote into future context.

Origin keeps those states visible so the human can confirm, correct, dismiss, forget, or let the daemon keep the item out of trusted context.

02

Capture queue

Use /review captures when you want to walk unconfirmed memories. Confirm the captures that are durable and reject or forget the ones that should not carry forward.

In MCP-only clients, list_pending and confirm_memory expose the same basic flow: inspect candidates, then confirm one source_id when it is worth keeping.

Claude Code

/review captures
/review revisions
/recall "what changed about the setup path"
/forget mem_abc123

03

Revisions and supersession

When a fact changes, prefer a correction that supersedes the old memory over a silent rewrite. The old context still explains why future sessions might see a historical decision.

/review revisions is for staged memory updates. Accept a revision when the new statement is the right current record; dismiss it when the old memory should remain.

04

Contradictions

Contradictions are not always bugs. They often mean the project changed, the user corrected course, or two contexts are being mixed.

When Origin surfaces a contradiction, decide whether the newer fact supersedes the older one, whether the memories belong in different spaces, or whether one should be forgotten because it is simply wrong.

05

Quality-gate rejections

Some attempted captures should never become memory: duplicates, low-quality fragments, tool output, logs, or transient status. Rejections are useful diagnostic records, not a failure of the work loop.

Use rejections when you are debugging why a capture did not appear. Do not treat every rejected item as something to recover.

06

MCP tool map

The MCP connector exposes review and trust operations for clients that do not have Claude Code slash commands.

Destructive or authority-changing tools require care. Get the source_id from recall, list_pending, or a page source list before confirming, forgetting, or resolving a revision.

MCP tools

list_pending             unconfirmed captures
confirm_memory           accept one capture by source_id
list_pending_revisions   staged correction/revision rows
accept_revision          apply a pending revision
dismiss_revision         keep the current memory
dismiss_contradiction    mark a conflict as handled
list_rejections          quality-gate rejects

07

When to forget

Use forget when a memory should not remain in the local record at all: sensitive accidental capture, wrong private fact, or data that should not be retained.

For ordinary changes, prefer a correction with supersession. That keeps the reasoning trail visible while steering future context toward the newer fact.

Read data and privacy

Next

Core Concepts

Understand the pieces behind Origin: memories, sessions, handoffs, pages, the daemon, MCP, Markdown, and the local index.

Read next