Memory Impact Preview

4 min readFor reviewersUpdated 2026-05-19

What you'll learn

• What a memory impact preview shows you before promotion.
• The signals reviewers should look at: contradictions, evidence, scope.
• When a preview is enough, and when you should ask for a direct memory.write grant.

Memory impact preview

A read-only forecast of what would happen if you promoted the pending proposals for a task — facts that would be added, facts that would be invalidated, contradictions that would surface, and the scope visibility of every change.

Previews never write. They surface enough information to make a decision.

Run a preview

Show the impact of promoting task_review_docs

craik memory preview task_review_docs

The preview prints:

Facts that would be added

The net-new facts a promotion would create, with the scope each one lands in.

Facts that would be invalidated

Existing facts a promotion would supersede or retire.

Likely contradictions

Proposals that conflict with existing approved facts, surfaced for explicit resolution.

Proposals missing evidence

Pending proposals without sufficient evidence references — almost always a "no" until evidence is attached.

Scope visibility counts

How many actors / projects each scope reaches. The "blast radius" view.

What to look at first

When a preview lands on your desk, the priority order is roughly:

1. Proposals missing evidence. If a proposal claims a fact without citing a file, issue, or upstream memory record, reject it or ask for the evidence to be attached. Evidence-free facts contaminate memory faster than anything else.

2. Likely contradictions. A contradiction is the runtime telling you "this proposal disagrees with something already trusted." Decide which side wins before you approve, and use the contradiction inbox to record the decision.

3. Scope visibility. A proposal that wants to land in a wide scope (project:*, org:*) deserves more skepticism than one scoped to a single project.

4. Invalidations. Confirm that retiring an existing fact is the actual intent. Sometimes a "would invalidate" surfaces because the new proposal should have been narrower, not because the old fact is wrong.

Previews are explicit about scope

Memory scope is intentionally first-class in the preview output. Reviewers should confirm three things before approving:

Question

Signal

Where it lives

Is the scope appropriate?

visibility

Each pending proposal carries its target scope. Anything wider than the run was authorized for is a red flag.

Is there evidence?

supported_by

Every proposal should cite at least one evidence reference. "No evidence" is a default-reject signal.

Are there contradictions?

contradictions

Resolve before promotion. The contradiction inbox is the durable record of how you resolved it.

Previews don't grant authority

A preview is a read-only forecast. Promotion of proposals still requires the reviewer flow. Direct writes to Stigmem or a memory backend still require a matching memory.write grant — when that grant is absent, agents must leave proposals for review instead of writing directly.

If you find yourself wanting to bypass the proposal flow because "the review step is tedious," that's usually a signal that:

• The policy envelope doesn't yet match the task's risk profile (consider adding a memory.write grant scoped narrowly to the affected memory scope), or
• The proposals are too granular (consider batching proposals at the handoff boundary so review is a single pass).

What's next

DoManage memory proposalsThe full proposal lifecycle from creation to approval.DoResolve contradictionsHow conflicting facts are surfaced, recorded, and resolved.ReadMemory & StigmemWhy memory is governed and how scope, evidence, and trust compose.