Forgetting pass

​

Context

• append-and-supersede, where nothing is merged or deleted on a write path (ADR-0005, memory model);
• type-aware consolidation that never auto-applies an edge to an event memory (ADR-0005 §3: at most an advisory extends proposal);
• an archive transition that leaves history readable.

• Supersession only happens if something proposes it. People do not maintain lineage by hand.
• Proposals cannot be applied blindly. In the S1 data, high similarity could not tell “same fact, restated” from “same ritual, new day”.

​

Decision (proposed)

1. Selects candidates: stale single memories, plus pairs of same-type, same-scope memories that likely conflict.
2. Asks for verdicts: sends them in batches to Gateway.decide() (Jev, pinned model) for typed verdicts with calibrated confidence: keep, archive, supersede-by:<id> or conflict-with:<id>.
3. Writes proposals: confident non-keep verdicts become proposals that the user reviews through review_proposals.

​

Candidate query

• type in STALE_CANDIDATE_TYPES (decision, preference, blocker, fact);
• freshness GREATEST(updated_at, last_reviewed_at) older than STALE_WINDOW_DAYS (30);
• ordered most stale first;
• capped at 60 per tenant per run.

b.memory_type = a.memory_type
AND b.scope = a.scope
AND b.project IS NOT DISTINCT FROM a.project
AND a.memory_type IN ('decision', 'preference', 'fact')
AND (1 - (a.embedding <=> b.embedding)) >= :conflict_floor   -- 0.82 to start, set by the eval

• event is excluded from pairing, as ADR-0005 §3 requires. Recurring episodic entries are near-identical by construction.
• note is excluded in v1. In the S1 data, notes were 79% of destructive-merge targets, and their free form makes “conflict” hard to judge. Revisit after the eval.
• Pair order: pairs are oriented by recency, newer first, as consolidation orients them. Pairs whose older side is stale rank first. The cap is 40 per tenant per run.
• Anti-joins:
  • an existing edge;
  • a consolidation proposal in any status;
  • a retention proposal in any status created after both memories’ freshness.
  So a decision stays final for a pair until a newer memory reopens it (the memory model rule).

​

Judgment: the Jev state shape

• Calls: one decide() call per batch of up to 12 items, through the composed gateway. JEV_API_KEY and JEV_MODEL are pinned (jev-1.14.0), the same configuration the session closer uses.
• Size limits: the judged memory’s content is cut to 1,200 characters, and each newer neighbour’s to 300. A single item then carries at most about 2,100 characters of content and a pair about 2,400. Twelve items plus JSON overhead stay under 40k characters, against Jev’s limits of 64k (MAX_DECIDE_STATE_CHARS) and 100 questions. The batcher measures the rendered state and splits a batch that would pass 48k, so an unusually long topic cannot trip assertDecideRequest.
• Metering: each call is metered as a new operation, memory.forget.decide. That takes two registry edits in packages/llm/src/operations.ts:
  • an llmOperations entry with its own cost ceiling;
  • an addition to METERED_JUDGMENT_OPERATIONS.
  The pass uses the same injected BudgetEnforcement and the closer’s metered-call shape: reserve, send, record usage, release.
• Opt-in: isJudgmentEnabled(userId) is read immediately before every send.
• No fallback: there is no fallback to complete(). A tenant without the opt-in, or a deployment without a judgment gateway, gets no forgetting pass at all.

• fenceExcerpt, which is exported from session-closer-prompt.ts;
• jsonLiteral, which is private to session-closer-judgment.ts today. PR 2 moves it beside fenceExcerpt and exports it.

{
  "now": "2026-10-26T04:30:00Z",
  "items": [
    {
      "ref": "s0",
      "kind": "single",
      "memory": { "type": "decision", "scope": "work", "project": "3ngram",
                  "topic": "…", "content": "…", "recordedAt": "…", "lastTouchedAt": "…" },
      "newer": [ { "ref": "s0n0", "type": "decision", "topic": "…", "content": "…", "recordedAt": "…" } ]
    },
    {
      "ref": "p0",
      "kind": "pair",
      "older": { "type": "fact", "topic": "…", "content": "…", "recordedAt": "…" },
      "newer": { "type": "fact", "topic": "…", "content": "…", "recordedAt": "…" },
      "similarity": 0.86
    }
  ]
}

• keep, keep_both: keep.
• archive, archive_older: archive.
• supersede_by:…, supersede_older: supersede-by:<newer id>.
• conflict: conflict-with:<other id>.

​

Proposals

• its session_run_id is NOT NULL with a foreign key to agent_sessions, and a forgetting pass has no session;
• it has no action column;
• it only stages open or waiting commitments;
• it means “this commitment is done”.

CREATE TABLE retention_proposals (
  id                uuid PRIMARY KEY DEFAULT uuidv7(),
  user_id           uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  memory_id         uuid NOT NULL,              -- the memory the verdict is about
  action            text NOT NULL CHECK (action IN ('keep', 'archive', 'supersede', 'conflict')),
  related_memory_id uuid,                       -- the newer memory (supersede) or the other side (conflict)
  probability       double precision NOT NULL CHECK (probability BETWEEN 0 AND 1),
  probabilities     jsonb NOT NULL,             -- the full choice distribution, for calibration
  model             text NOT NULL,              -- the pinned judge model
  status            text NOT NULL DEFAULT 'proposed'
                    CHECK (status IN ('proposed', 'applied', 'rejected', 'dismissed')),
  decided_at        timestamptz,
  created_at        timestamptz NOT NULL DEFAULT now(),
  CHECK ((action IN ('supersede', 'conflict')) = (related_memory_id IS NOT NULL)),
  FOREIGN KEY (user_id, memory_id) REFERENCES memories(user_id, id) ON DELETE CASCADE,
  FOREIGN KEY (user_id, related_memory_id) REFERENCES memories(user_id, id) ON DELETE CASCADE
);
CREATE UNIQUE INDEX retention_proposals_open_idx
  ON retention_proposals (user_id, memory_id, action) WHERE status = 'proposed';
CREATE INDEX retention_proposals_review_idx ON retention_proposals (user_id, status, created_at);
-- tenant_isolation policy and FORCE ROW LEVEL SECURITY, exactly as 0043 and 0044;
-- runtime grants SELECT, INSERT, UPDATE only (no DELETE); covered by export and account deletion.

• Keep verdicts, and verdicts below their threshold, are stored with status dismissed and are never listed. Only the pass sets dismissed; a reviewer’s no is rejected, with decided_at set, so calibration can tell the two apart. They stop the pass from re-judging a memory until that memory’s freshness moves past the verdict, through an edit, a reaffirm or a newer neighbour.
• Table count: this is the 32nd physical table. Its JTBD is “a memory the judge thinks is finished waits for a human yes instead of lingering in every briefing, or being dropped”, and no existing proposal table can carry it, as argued above.
• Accepting:
  • archive: archiveMemoryIn with the disposition policy, the same rejection rules and an audited archive event.
  • supersede: a supersedes edge from the newer to the older memory, with applyProposal’s predecessor-close semantics. It refuses event-type and no-longer-live memories.
  • conflict: records the review only, with no memory change. The user resolves it with revise.
• Rejecting: final for that memory and action, until the memory’s freshness moves.

​

Flag and schedule

• FORGETTING_PASS_ENABLED in packages/config, a stringbool that defaults to false, loaded with loadForgettingPassConfig().
• Resident worker: with the flag on, upsert a job scheduler at 0 30 4 * * *, daily at 04:30 UTC, clear of the hourly consolidation tick. With it off, remove the scheduler, and gate the processor so a residual job completes as a no-op.
• One-shot: add forgetting-pass to ONCE_JOBS. With the flag off it exits 0 without reading anything. Add a row to the operate job table (30 4 * * *).
• Budget: the injected BudgetEnforcement reserves a slot before every decide() call, as the closer does, and the pass rejects instead of billing past the cap.

​

Eval plan

• Headline: precision on archive and supersede proposals, each separately and then combined, reported per memory type as ADR-0005 asks. A wrong archive costs more than a missed one, so recall is secondary.
• Also reported: conflict precision, the keep rate on still-valid items, and calibration (expected calibration error) of the judge’s confidences.

• labels are frozen before the first judged run;
• thresholds are chosen on a development split, and precision is reported on a held-out split;
• recorded Jev responses become fixtures for deterministic CI, as jev-recorded.test.ts does;
• a live re-measurement runs whenever JEV_MODEL changes.

• archive precision of at least 0.95 with at least 40 proposals;
• zero recurring-episodic collapses.

​

Rollout

1. Migration and db functions for retention_proposals (RLS + FORCE), plus export and account-deletion coverage.
2. Core candidate selection and judgment rendering, tested with FakeGateway.
3. Worker job, flag and one-shot entry, plus the operate docs row.
4. review_proposals V4 with the retention kind; the description rewrite, embeddings regeneration and eval-gate rerun followed in their own PR.
5. Private golden set and report-only harness.

​

Open questions

1. Should confident keep verdicts also propose a reaffirm? It would shrink the stale list, but it is a write the user did not ask for. The v1 answer is no: a keep stays silent.
2. Should notes join candidate selection after the eval, as singles, pairs, or neither?
3. Should accepting a conflict offer the two resolutions inline (archive the older, or supersede), instead of sending the user to revise?
4. How does the pass share the daily budget with the session closer when both are on?