DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-145-correction-recognition-v0_1.md

CR-2026-145 — Correction-Recognition (Propose-and-Confirm) — v0_1

Version. 0.1 Date. 2026-07-04 Status. Drafted, not staged for build. Number 145 confirmed free at staging (highest prior: CR-2026-144). Base: engine main @ 542e09c, OL main @ 9938628. No build yet. Repos. loomworks-engine, loomworks. Grounded on. loomworks-semantic-meaning-foundation-v0_1 (correction-recognition/supersede-not-duplicate), engine research into existing supersession mechanisms (this session).


What this fixes

Today, correction/supersession of an assertion only happens by explicit number ("change 5 to X"). When the Operator states something new that actually corrects an existing fact — e.g. "I parked on level 10" after previously recording level 12 — the system has no way to recognize this and simply adds a new, unrelated assertion. The old fact and the new fact sit side by side with no relationship recorded, contrary to the seed's "corrections preserved, not smoothed" principle, which assumes a correction is recognized as such.


Prior failure in this codebase — the reason this CR does not do naive auto-matching

A similar approach (matching new content against an existing assertion by text comparison) was tried before, in remember_about_me's refinement path, and deliberately removed — the team's own comment: "NO text comparison (that comparison was the source of the confirmation loop)." The one surviving content-matching mechanism in the codebase (forget_about_me's retraction-target matching) is deterministic keyword/substring, not semantic, and is narrowly scoped, capped, and gated behind human confirmation.


Fix — propose-and-confirm, not auto-supersede

When a new statement appears likely to correct an existing assertion, the Companion proposes the match ("This looks like an update to [existing assertion] — supersede it?") rather than silently superseding. The Operator confirms before anything changes — same pattern as forget_about_me's gated confirmation, and consistent with the seed's Operator-authority principle: the system surfaces and signals, the Operator approves.

Matching approach: to be determined at Step-0/build-brief stage, but must not repeat the removed text-comparison approach from remember_about_me. A semantic (embedding or LLM-based) approach is the likely direction, since the codebase's one prior keyword-based failure was specifically about naive text comparison, not semantic matching — but this needs explicit grounding before being assumed.


Seed check

No conflict. Directly implements "corrections preserved, not smoothed" and Operator-authority ("the system surfaces and signals; the Operator approves").


Out of scope

Content-to-engagement routing (separate, already-recorded finding). Semantic recall for ask_about_past_input (separate, already-recorded finding). Auto-supersede without confirmation — explicitly rejected by this CR's own design.