GoodMemory-Current-Status-and-Evidence.md

GoodMemory Current Status and Evidence

This is the compact current-truth entrypoint. Historical narrative has been removed from this file; use docs/archive/quality-gates/README.md, generated reports, and git history for phase-by-phase provenance. Product scope remains in docs/GoodMemory-PRD.md, and execution order remains in task-board/00-README.txt.

Stable OSS Surface

• Current stable package line: 0.6.0. Tag v0.6.0 resolves to release commit 6fdd63ec; workflow run 29522907352 published the GitHub release and npm latest resolves to goodmemory@0.6.0.
• Main has completed Phases 68 through 72 on the generalization-first line. The production selector graph contains only generalized selection primitives, and the recommended preset now has a provider-free multi-granular BM25/entity/RRF path with an optional dense channel. The 139-file historical selector closure now lives physically under scripts/eval-profiles/legacy-fitted/; repo-local historical evals must activate that profile explicitly with bun run test:legacy-fitted.
• Release packaging is compiled-only: public bins execute dist/bin entrypoints, and the tarball excludes src plus TypeScript bin sources. A release test scans compiled JavaScript for known fitted benchmark literals.
• Core public workflow remains centered on createGoodMemory, remember, recall, buildContext, feedback, forget, exportMemory, and deleteAllMemory; advanced host/operator facades such as runtime, jobs, reviseMemory, and runMaintenance stay explicit.
• Package subpaths goodmemory, goodmemory/ai-sdk, goodmemory/host, goodmemory/http, and goodmemory/runtime-kit resolve through compiled dist/ artifacts and emitted type declarations.
• Storage resolution is automatic: explicit config wins, configured Postgres can be used when bootstrap succeeds, Bun gets local SQLite, and unsupported Node zero-config local SQLite falls back to in-memory with observable runtime inspection.
• The official CLI uses the package bin. The global CLI invocation path is goodmemory ... after npm install -g goodmemory; project-local installs use npx goodmemory, npm exec -- goodmemory, or ./node_modules/.bin/goodmemory .... Non-version command execution remains Bun-backed today.
• Generic live-memory eval semantics are auto-storage aligned: eval:live-memory, eval:live-auto-memory, runLiveMemoryEval(), eval:live-provider-memory, and historical reports/eval/live-memory/phase-* paths keep their existing meanings.

Installed Host And Runtime Surface

• Phase 35 installed host-memory middleware is now part of the accepted stable host surface. Phase 35 is now closed as the installed host-memory middleware and hooks slice. Accepted commands and hooks include goodmemory setup, goodmemory status, SessionStart / UserPromptSubmit hooks, and managed Codex/Claude install/enable/disable flows.

• Phase 37 is now closed as the installed host selective writeback slice: goodmemory codex writeback, runtime defaults off unless explicitly changed, and new interactive installs recommend observe.

• Phase 37.1 is now closed as installed-host writeback productization polish: goodmemory codex writeback inspect, audit/undo support, and observe/selective boundaries.

• Phase 38 is now closed as the governed runtime surface slice: GoodMemoryConfig.observability.traceSink, targeted reviseMemory(), memory.runtime.*, memory.jobs.enqueueRemember(), GoodMemoryConfig.providers.embedding, and examples/express-chat-server.ts.

• Phase 39 is now closed as the Python HTTP integration bridge slice. See docs/GoodMemory-Python-HTTP-Integration-Bridge.md and examples/python-fastapi-memory-consumer.py.

• Phase 41 is now closed as installed-host pre-action unification: goodmemory codex hook pre-tool-use, goodmemory codex action, and the installed action bridge share the installed memory backend.

• Phase 42 is now closed as the Progressive Recall Protocol slice.

• Phase 43 is now closed as the Runtime Kit slice: goodmemory/runtime-kit.

• Phase 43.5 is now closed as the Optional Runtime Worker slice: goodmemory runtime worker drain-once.

• Phase 50 is now closed as the Installer CLI Runtime-Shell Hardening slice: goodmemory doctor [codex|claude|both] and goodmemory repair [codex|claude|both].

• Phase 51 is now closed as the Typed Behavioral Memory And Enactment slice; typed behavior is stored on compiled validated_pattern feedback.

• Phase 52 is now closed as the Structured Text-Response Enactment And Guarded Policy slice; guarded_policy remains internal.

• Phase 71 is now closed as the local memory administration product slice. goodmemory inspector serve hosts the packaged private React/Vite console and versioned /admin/v1 API for scope discovery, categorized memory, candidate review, governed revision/deletion, recall traces, and audit events. Auth is Bearer-only after fragment-token bootstrap; mutations require ETags and idempotency keys. goodmemory runtime viewer is deprecated and delegates to the same server in exact-scope read-only mode. See docs/GoodMemory-Inspector-and-Admin-API.md and reports/quality-gates/phase-71/run-20260711-admin-inspector/.

• Phase 73 remains active as a separate Codex-only product-effect lane. C0-C2 are closed. C3's tracked projection remains internally accepted as frozen-prehistory protocol/host evidence, but its source-reproducibility gate is reopened. C4's prior v8 acceptance is superseded; the canonical v9 corpus-wide leakage core, independent review, baseline, authenticated raw and projected stage evidence, and final readiness are accepted. C5 is unblocked for the internal pilot but has not run; C6-C7 remain open. Final C3 run c3-controlled-20260716-cleanclone-003 used a clean mechanical runner snapshot at commit fc31f4f96f3975daea361805da3fc4fc942c5aa4 / tree 996b1c24bfb53a9d9c62eb109997576df7b512af, clean GoodMemory source commit 594ee5406ff082f6210d4be4f763f529f13a1a9f / tree af13dc2688a0e3636f2c2e40728a47eb52ce90eb, package SHA-256 4526fc05ee1fadf05ff80e555827af67477724bf5e0d4cd3613452b899a647c3, Codex CLI 0.144.5, and gpt-5.6-sol / xhigh. The CLI now rejects /tmp, /private/tmp, /var/tmp, and /private/var/tmp for every sensitive C3 input/output because Codex 0.144.5's macOS platform sandbox unconditionally allows those scratch roots. The accepted run used non-temporary roots, exact-denied current and cross-arm runtime state, direct current/cross-arm auth probes, workspace read/write positive controls, and a network-off positive/negative control before both model launches. No-memory completed before frozen-prehistory materialization, and both Codex processes completed before evaluator materialization. The installed recall preflight and current-session canary bound the exact seeded memory, thread, sanitized transcript, cursor advancement, committed Stop writeback, and raw transcript persistence off. Deterministic hidden fail-to-pass and pass-to-pass tests passed in both arms: 2/2 attempts finalized and resolved, zero infrastructure failures, one comparable pair, outcome tie-both-pass, and publicClaimEligible: false. The tracked projection under reports/quality-gates/phase-73/c3-controlled-20260716-cleanclone-003/ contains 17 bound files. Its independent verifier accepted internal consistency and two clean-clone patch replays with no reasons, while explicitly recording externalAuthenticityVerified: false. C3 is therefore accepted for protocol execution and installed-host activation only; the tie does not prove coding uplift and does not authorize a public coding-effect claim. C3 source-reproducibility gate is reopened: the recorded GoodMemory commit and tree are reachable in the current repository, but runner commit fc31f4f96f3975daea361805da3fc4fc942c5aa4 and tree 996b1c24bfb53a9d9c62eb109997576df7b512af are not. The projection proves internal consistency only; it cannot currently recover the exact verifier source from repository objects. C4's previous v8 controlled dataset, baseline ceiling pilot, independent review, and final readiness are historical and superseded. The schema-v2 fixture has 6 episodes, 18 stages, 2 controlled repositories, all 8 required memory strata, a 63-file asset lock, 54 stable fresh-base probes, and 18 passing fresh gold replays. The complete leakage audit covers 486 surface-by-hidden-artifact cells. Its 1458 intentional mutation cells cover fragment, typed-value, and typed-relation channels; 648 are applicable and 810 are explicitly not applicable. Relation detection preserves exact trim/case endpoints and scans each agent-visible corpus across repository relative paths, whitespace, sentence, line-count, byte-length, and physical-file boundaries. The frozen manifest now explicitly binds public pass-to-pass relations already present in visible repository source; undeclared relations split across files are rejected. Four content-preserving dynamic surfaces remain bound for live C5 re-audit: effective-codex-input-after-seeding, flat-summary-after-seeding, goodmemory-export-after-seeding, and goodmemory-hook-context-after-seeding. Core SHA-256 6ec596c99891376842e612520ae00b00f627e99ba63f48b9a690f02c06c72d3a binds asset lock a4db88c4dc9ebea7fc464ba104f34c3a0852e2743a798694723d9ae9614606c4. A fresh fork-turns-none reviewer inspected only the 63 frozen assets and deterministic core before the live baseline existed, accepted all six episodes, and explicitly recorded that no coding outcomes were inspected. Review SHA-256 cfa5b75dc8ad7bc30fc287f05dae113a6af3720e5b3ca806ba1487e38acbf44e and provenance SHA-256 1eee28b3fb8f08b5f57dcfb74db62632682145f062d32cad93341c227f54c4dc bind dispatch, request, input bundle, and response, while disclosing that the orchestrator attestation is not a cryptographic receipt. Historical v8 baseline run-c4-baseline-v8-20260717T032532Z finalized all 12 planned no-memory stages with 2 resolved, 10 unresolved, zero infrastructure failures, and ceilingRisk: false; report SHA-256 145075fe1db774e14fbce1ba6df6b6170c64cd87a9c81c89a7abb39aefcfb220 recorded decision proceed-to-c5-pilot. Historical final readiness SHA-256 7cf3f8cb829472f34e475dddfe69911651887c2896559712988e1153b6ea0128 bound the superseded core, baseline, review, and provenance. The immutable v8 artifacts remain at explicit *-v8 historical paths. Canonical v9 core SHA-256 420f5c11b1a8aa344714a950b154477449856aed130be37abfe2cdf474eff544 and review SHA-256 16f63486e39d349b98abfb38340e8492962d8ecf2b78ed488b28e9c4ae439a09 bind asset lock 795473a2916e441ff9cc39ac92578565a84405ffd45589d90943ad31b81d1195. Baseline run-c4-baseline-v9-20260718T1815Z has report SHA-256 2140f020a5d3817d4b91a0d8edf5227db6fa7fec32995a6fab12df6d52901270, zero infrastructure failures, no ceiling risk, and decision proceed-to-c5-pilot. Final readiness SHA-256 3b24b4233faa6930d98c4de3d9bfea003ab09225c0eec0c7c81fb9c10869b2e2 binds the v9 core, baseline, review, provenance, 12 projected stages, and 12 authenticated raw sources in one repository-replayable bundle. Those artifacts, not this summary prose, are the C4 truth source; the release test rejects any routing/status projection that drifts from them. No C4 version proves coding uplift or authorizes a public coding-effect claim. The C5 harness implementation now retains sanitized failed-canary and interrupted-resume attempts in the verifiable projection, rejects foreign injected memory, authenticates its recursive runtime import closure from projected source bytes, and resumes only at the uncommitted cluster boundary under the exact original run identity. This is implementation/test closure only. A six-process C5 diagnostic canary was rejected under a live-disproved prior-memory equality rule, and its source identity was later invalidated; no accepted canary or broader pilot has run. C5 is unblocked for internal execution by accepted v9 C4 prerequisite evidence.

• The Phase 72 benchmark gate and versioned release gate are closed for v0.6.0. Current public-opt-in claims are LoCoMo, BEAM, and MemoryAgentBench. The strict claim gate reports five declaration/README- consistent rows: three current claims and two historical/internal rows. LoCoMo covers all 1540 non-adversarial questions with zero execution/judge failures and scores 0.6298701299 strict, 0.8707792208 under the independent gpt-5.5 official protocol, and 59/96 = 0.6145833333 on open-domain. MemoryAgentBench uses deterministic judge-free scoring and reports CR 0.9589041096 and TTL 0.9333333333 versus no-memory 0.000; AR/LRU remain excluded.

  BEAM 100K (unified 0.7651 / strict 0.620 / recall 0.8276) is the current generalized public-opt-in claim. The run disables all 148 narrow recall gates and legacy fitted answer postprocessing, covers all 400 questions and 1051 rubric items, and has zero execution/judge failures. The independent unified score is 0.7650987103 versus the public same-protocol 0.49 reference; strict binary remains disclosed at 248/400 = 0.620 and the upstream paper score at 0.7510180808. The frozen event-ordering audit found 7/40 cases with non-chronological official evidence order plus one requested-item/rubric mismatch. Therefore 0.72 strict and 0.80 unified remain disclosed stretch diagnostics, while the hard comparable gate uses complete independent scoring against the same-protocol public reference. Generic probes that failed the 3pt admission rule or required benchmark-label semantics were not promoted.

  LongMemEval and ImplicitMemBench remain versioned internal evidence. LongMemEval's Phase 72 eval-only verifier chain reaches 360/500 = 0.720 judge-free and 462/500 = 0.924 under an independent gpt-5.5 official-prompt-compatible judge. That model is outside the pinned LongMemEval evaluator model zoo, so the result is not directly comparable to published official scores; it is also not a production runtime profile. ImplicitMemBench's explicit retry-merged artifact reaches 0.6923666667 with zero failures, but does not replace a monolithic fresh Full-300 run. HaluMem, MemGym, and MINTEval remain release evidence rather than public benchmark claims. External adapter PR #17 remains open pending maintainer review. The complete v0.6.0 release-candidate verification passes: the exact intended tree has 3743 passing tests, 2 environment-gated Postgres skips, and 0 failures across 436 files; the separate Postgres-enabled coverage run has 3634 passing tests, 0 failures, 90.74% overall coverage, and 94.40% storage coverage. Node 20/22/24 packed-consumer smokes and desktop/mobile browser flows pass. The 219-file tarball excludes src/ and unpacks to 3,868,829 bytes (3.689603 MiB). The published GitHub asset is goodmemory-0.6.0.tgz with SHA-256 4b9c3d4b2aa7300943dfc334860bdc58bc88dcb0adc2f88137f1cd548bfe1cdf; npm reports an unpacked size of 3,867,885 bytes.

Public Boundary Notes

• root goodmemory no longer re-exports internal evolution contracts.
• automatic adapter/event user_correction path is proposal-first.
• automatic adapter/event user_correction path is proposal-first and records selective evidence plus proposal/promotion receipts instead of writing an intermediate active feedback memory; public feedback() remains the explicit durable procedural feedback entrypoint.
• Provider-backed retrieval is explicit; rules-only remains the default accepted mode, and provider failures surface as provider_error.
• Dashboard, cloud sync, and team workspace remain a Phase 48 no-go decision.
• Current public-opt-in claims are LoCoMo, BEAM, and MemoryAgentBench. BEAM 100K (unified 0.7651 / strict 0.620 / recall 0.8276) retains its strict, paper-protocol, and event-ordering disclosures. LongMemEval and ImplicitMemBench remain versioned internal evidence. The runtime capability descriptor and both README current-claim tables expose only the three current v0.6.0 declarations. The strict gate enforces declaration status, package-version equality, evidence assertions, README row provenance, and disclosure fragments.
• ImplicitMemBench Full-300 rerun evidence guard note: eval:phase-61-full300 rejects ambiguous source/output/run/budget selectors before launching live shards. The 2026-07-06 full-root run run-phase61-full300-rerun-20260706-codex-current completed 300 cases with zero failures and measured same-model diagnostic GoodMemory 0.7081666667 versus baseline 0.41. That number remains diagnostic; the later gpt-5.4 stored-answer rescore is versioned historical evidence, not a current-production score.
• ImplicitMemBench postchanges rerun note: run-phase61-full300-rerun-20260706-postchanges-current completed the same /tmp/ImplicitMemBench full-root 300-case run after recent local changes, but had 2 GoodMemory distilled execution failures (text_answer_generation timed out after 180000ms) and therefore should not replace the 0-failure canonical internal rerun above. Its best same-model diagnostic GoodMemory score was 209.05/300 = 0.6968333333, raw was 175.05/300 = 0.5835, distilled blocking was 153/200 = 0.765, and baseline was 131/300 = 0.4366666667. Treat this as drift evidence, not a public-claim artifact.
• ImplicitMemBench latest rerun note: run-phase61-full300-rerun-20260706-latest-current completed the same /tmp/ImplicitMemBench full-root 300-case run after the current benchmark-hardening work. It measured best same-model diagnostic GoodMemory score 211.06/300 = 0.7035333333, raw 179.06/300 = 0.5968666667, distilled blocking 155/200 = 0.775, and baseline 130/300 = 0.4333333333. It improved over the failed postchanges rerun but still had 1 GoodMemory distilled execution failure, so it does not replace the 0-failure codex-current source-answer run or the stored-answer gpt-5.4 comparability artifact.
• ImplicitMemBench after-hardening rerun note: run-phase61-full300-rerun-20260706-after-hardening-current completed the same /tmp/ImplicitMemBench full-root 300-case run while the stored-answer rescore runner was being hardened. It had executionFailures: 0, but measured a lower best same-model diagnostic GoodMemory score of 206.85/300 = 0.6895, raw 174.85/300 = 0.5828333333, distilled blocking 151/200 = 0.755, and baseline 130/300 = 0.4333333333. This is the freshest drift check and is cleanly completed, but it is lower than the canonical 0-failure codex-current source score by 5.60 passed-equivalent points and does not replace the stored-answer gpt-5.4 comparability artifact.
• ImplicitMemBench stored-answer rescore readiness note: audit:phase-61-implicitmembench-rescore-readiness verifies the canonical 0-failure Full-300 reports are ready for no-answer-rerun judge replacement. The same-model artifact implicitmembench-rescore-readiness-20260706-current/rescore-readiness.json finds storedAnswersReady: true but readyForIndependentJudgeRescore: false; the cross-version artifact implicitmembench-rescore-readiness-gpt54-probe-current/rescore-readiness.json finds readyForIndependentJudgeRescore: true with answer gpt-5.5, judge gpt-5.4, baseline 300/300 rows, GoodMemory composite 300/300 rows, 35 deterministic structured_first_action rows, and 265 judge-required rows (text_behavior_judge 165 + priming_pair_judge 100).
• ImplicitMemBench stored-answer independent-rescore runner note: rescore:phase-61-implicitmembench now consumes the canonical Phase 61 overall report, loads its baseline and GoodMemory source reports, preserves stored answers, carries deterministic structured_first_action rows forward unchanged, and rejudges only the stored text_behavior_judge plus priming_pair_judge rows needed for the baseline and goodmemory-distilled-feedback+controlled-priming composite. The command rejects same-model answer/judge configuration before reading source reports, rejects partial or mismatched source scopes before any judge call, writes run-identity.json with source report SHA-256 fingerprints before judge calls, resumes completed judge-required rows from progress.jsonl only when the run identity still matches, and writes baseline-report.json, goodmemory-report.json, overall-summary.json, and rescore-summary.json under the requested run directory with sourceAnswersUnchanged: true. The completed implicitmembench-independent-rescore-gpt54-current run produced 530 judge-required row decisions (265 baseline + 265 GoodMemory composite), 0 execution failures, GoodMemory 207.35/300 = 0.6911666667, blocking 153/200 = 0.765, priming 54.35/100 = 0.5435, and baseline 120/300 = 0.4. This clears the prior same-model blocker under the public claim gate, with required same-family disclosure.

Active Research Slice

• Phase 69 is complete. The accepted provider-free gate is reports/quality-gates/phase-69/run-20260711-generalized-retrieval/phase-69-quality-gate.json. It compares frozen baseline/candidate configurations on pinned full roots: LoCoMo 10 conversations / 1986 questions and LongMemEval 500/500, both label-free and with executionFailures: 0. LoCoMo evidence recall moved 0.0229806935 -> 0.1334856928 on multi_hop and 0.0943627451 -> 0.2720588235 on open_domain. LongMemEval evidence-session recall moved 0.6794871795 -> 0.9102564103 on knowledge-update and 0.4250626566 -> 0.7667919799 on temporal-reasoning; overall moved 0.5317 -> 0.8317666667. Every protection slice improved and noise stayed within the fixed gate. These are retrieval-only diagnostics, not answer accuracy and not public benchmark claims.

• Phase 70 is complete. Its baseline-only LoCoMo selector froze a 24-question target cohort across 8 conversations plus a 12-question protection cohort across 4 conversations; target evidence was present in Phase 69 membership but absent from the real MemoryPacket top-6. The pinned gpt-5.6-terra Gurki run completed 36/36 applied reranks with executionFailures: 0, no fallback, and unchanged membership. Target top-6 evidence recall moved 0.1041666667 -> 0.7708333333; protection moved 0.4166666667 -> 0.6666666667. See reports/eval/research/phase-70/locomo/run-phase70-reranker-focused-gpt56-terra-current/reranker-eval.json and reports/quality-gates/phase-70/run-20260711-reranker-and-evidence/phase-70-quality-gate.json. This is a targeted retrieval-order diagnostic, not a full LoCoMo answer score or public benchmark claim.

• Phase 71 is complete. Its real-browser evidence covers users/scopes, categorized memory and supersession, candidate approve/reject/release, revision and destructive confirmations, recall trace, audit, read-only mode, token non-leakage, ETag conflict handling, idempotent retry, and desktop/mobile layouts with clean normal-flow consoles. The accepted quality gate records the full repository suite with 0 failures, 0 LLM calls, and a package below 4 MiB at reports/quality-gates/phase-71/run-20260711-admin-inspector/phase-71-quality-gate.json. Phase 72 is complete; its accepted benchmark and versioned release gate is tracked under reports/quality-gates/phase-72/run-20260716-final/.

• Phase 62 LongMemEval is accepted as the first Sequential Benchmark Hardening slice.

• Shared strict CLI scalar guard note: migrated Sequential benchmark evidence entrypoints that use the shared strict scalar helper reject missing values, flag-as-value mistakes, duplicate scalar flags, empty values, and whitespace-padded values before downstream parsing. This is evidence-input canonicalization only; it does not change benchmark scores or public-claim boundaries.

• Historical Phase 63 / P67 BEAM evidence includes an official-protocol 0.802 score, but it is no longer a current public claim because the recall profile is repo-eval-only; the answer-rule lane is paused. The earlier accepted rules-only measured checkpoint remains the internal binary-track baseline: answer-pack hardening (--evidence-pack, src/eval/protocol-reader/evidencePack.ts) raised answer accuracy from the no-pack 0.56 baseline (224/400) and the prior evidence-pack 0.6525 checkpoint (261/400) to 0.695 (278/400) at identical recall (0.9621), executionFailures: 0, gate accepted. The historical P67 declaration reported official-protocol 0.802 versus the 0.49 public reference; its 122/400 binary-track wrong answers and category weak spots remain archived gap evidence.

• Accepted LongMemEval internal close (historical, with-judge, superseded by the later judge-free deterministic evidence below): run-phase62-longmemeval-full500-current-after-remaining-personal-hybrid-retry-r1-merged-20260517T161058Z with 454/500 answer accuracy, evidence-session recall 0.9590, missed recall 35, wrong recall 6, wrong answers 46, and executionFailures: 0.

• Historical LongMemEval P67-B declaration (2026-07-02): judge-free deterministic-subset answer accuracy 0.720 (360/500) with goodmemory-rules-only vs no-memory baseline 0.068 (+65.2pt), executionFailures: 0 over 500x2 cases, v0.3.5 @ 6f9152c (run-phase67b-longmemeval-rules-deterministic-current). A case counts only when scored by a deterministic method (abstention/exact/contains/expected_alternative/numeric_count); the same-model semantic judge is excluded by construction (with-judge diagnostic 0.896 not recorded as the strict result; evidence-session recall 0.9543; abstention only 28 of the 360 correct; the baseline's correct set is 30/34 bare abstentions). Dataset MIT (xiaowu0162/longmemeval-cleaned, the exact split run). It was promoted in Phase 67, then reclassified as versioned historical evidence in Phase 68; it is not a current-production claim.

• Phase 62 CLI evidence guard note: LongMemEval eval/full500/summary/retry entrypoints reject duplicate mode/source/output/run/budget selectors, and output run ids must be single path segments. This protects evidence inputs and directories only; it does not change the versioned LongMemEval scores or their current historical-only status.

• Phase 62 LongMemEval source-root env guard note: base eval/readiness resolution rejects empty or whitespace-padded GOODMEMORY_LONGMEMEVAL_ROOT fallback values before benchmark-root resolution. This is LongMemEval smoke/full and recall source-root integrity hardening only; it does not change the public claim or the older with-judge internal checkpoint.

• Phase 62 gate CLI guard note: gate:phase-62 rejects duplicate gate-output selectors and requires a single-segment run id. This is gate-input hardening only; it does not change the versioned LongMemEval scores or their current historical-only status.

• P67-B deterministic-subset helper guard note: eval:phase-62-deterministic-subset rejects duplicate scalar report/output/profile selectors before resolving the source report: --report-path, --run-id, --output-dir, --claim-profile, and --baseline-profile; --run-id must also be a single path segment. This is LongMemEval public-claim helper input and source-report path hardening only; it does not change the 0.720 judge-free claim.

• Phase 65 union-live measurement run-directory guard note: legacy measure-locomo-union-live.ts now requires output --run-id values to be a single path segment before writing progress checkpoints, extraction caches, or union-live-report.json under --output-dir. This is older union-candidate live-evidence hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries.

• Phase 65 embedding-free comparison source/output guard note: run-phase-65-locomo-embedding-free-comparison.ts now rejects output directories that resolve to the benchmark root before parsing can hand off to the arm runner, and the runner repeats the same check before any arm can read the benchmark root. This is gateway-free comparison evidence integrity hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries.

• Phase 65 measurement source-root guard note: measure-locomo-levers.ts, measure-locomo-neural.ts, measure-locomo-union-live.ts, and run-phase-65-locomo-embedding-free-comparison.ts now reject empty or whitespace-padded GOODMEMORY_LOCOMO_ROOT fallback values before benchmark-root resolution. This is source-root integrity hardening for LoCoMo lever, neural, union-live, and gateway-free comparison evidence only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries.

• Phase 66 release-readiness CLI guard note: gate:v0-3-release-readiness rejects duplicate --skip-build, --skip-tests, --strict, and --output-dir flags before running package/release checks. This is release-gate input hardening only; it does not change benchmark scores or public claims.

• Public-claim gate note: gate:public-benchmark-claim validates declaration shape, metric direction and baseline improvement, derived answer/judge separation, full commit identity, tracked historical-projection assertions, and README row provenance/disclosures. It checks internal declaration consistency; it does not independently prove upstream licenses or reconstruct ignored raw reports. Historical source fingerprints can be checked locally with bun run scripts/project-historical-evidence.ts. A current claim must have candidate_public_claim status and a run.packageVersion equal to the current package version. Historical rows live under separate markers and remain consistency-checked without becoming current claims. Strict mode currently finds five declaration/README-consistent rows: LoCoMo, BEAM, and MemoryAgentBench are current v0.6.0 public-opt-in claims, while LongMemEval and ImplicitMemBench remain historical/internal rows.

• Phase 67 benchmark-prompt rescore evidence note: eval:official-rescore rejects ambiguous selectors, source/output overlap, malformed identities and progress rows, source fingerprint drift, judge-model drift, and incomplete judging. Its rescore-summary.json records source fingerprints, judge identity, selected/source scope, and a benchmark-and-model-aware claim boundary. LongMemEval runs with gpt-5.4 or gpt-5.5 are explicitly official-prompt-compatible but not directly comparable to published official scores because those models are outside the pinned evaluator model zoo. Stored answers remain separate from derived artifacts, and no rescore becomes a public claim without the claim gate.

• Phase 67 official-rescore cache writer / summary validation note: eval:official-rescore serializes progress through the same strict shapes accepted by resume parsing and validates final summaries, scope counts, fingerprints, category aggregates, and stored-answer boundaries before write. Existing LongMemEval, LoCoMo, and BEAM artifacts were refreshed from complete cached progress with 0 to judge, preserving their versioned historical scores while adding auditable identity and comparability metadata; this does not make them current-production claims.

• Phase 72 LongMemEval rescore profile / timeout note: eval:official-rescore --benchmark longmemeval records sourceProfile, rejects profile drift, and bounds judge requests. The retained label-free verifier chain reaches the strict judge-free floor at 360/500 = 0.720; its independent gpt-5.5 full-500 rescore reaches 462/500 = 0.924 with zero judge failures. The latter is official-prompt-compatible diagnostic evidence, not a published-score-comparable result, because gpt-5.5 is outside the pinned evaluator model zoo. Earlier 0.918 and 0.922 diagnostics remain variance/admission evidence. The verifier requires an explicit source report and validates resume checkpoints before reuse.

• Accepted BEAM smoke: run-phase63-beam-smoke-current and gate run-20260518003000.

• Latest accepted BEAM retained diagnostic: run-phase63-beam-100k-recall-diagnostic-rules-project-card-total-count-current-20260615T200000Z, evidence-chat recall 0.9620612564274538, missed 20/355, wrong-recall/noise 167/400, zero-recall 0, and hit/missing/noise ids 1022/72/810 -> 1023/71/807 (3:multi_session_reasoning:1 recovered from recall 0.5 to 1 — fourth multi_session_reasoning recovery via the multi-facet contradiction route, exhausting the confirmed-reachable msr cases; a ground-truth-misaligned [16,116] pair where the narrowed gate avoids the sibling knowledge_update 3:ku:2; returns exactly [16,116], recovering the contact-form turn 16 and shedding noise 60/88/36; cleanest single delta, a recall gain plus a noise reduction, zero ripples). The multi-facet contradiction route now serves contradiction, knowledge_update, and multi_session_reasoning (both "how much" comparisons and "how many" aggregates). Remaining partial-recall families: instruction_following (6 — via the instructionRules companionPattern recipe, NOT multiFacetGroups), multi_session_reasoning (the remaining cases have a genuine upstream candidate-pool gap, needing candidate-generation work).

• Phase 63 general-lever recall remeasure note: eval:phase-63-general-levers keeps non-provider floor / bm25 arms embedding-free even when provider embedding env is present, preserves provider semantic-union behavior for union arms, includes non-default --semantic-topk values in default union run ids, and requires output --run-id values to be a single path segment before invoking the recall diagnostic. This is BEAM recall/routing evidence-input and output-directory hardening only; it does not change answer score, closure, or public-claim boundaries.

• Phase 63 external-root prep CLI guard note: prepare:phase-63-beam rejects duplicate scalar source/output/fetch selectors before fetching Hugging Face or GitHub raw rows and before writing the refreshed BEAM root: --dataset, --github-api-root, --github-concurrency, --github-raw-root, --length, --offset, --output-root, --source, and --split. This is BEAM root-prep evidence-input hardening only; it does not change answer score, recall, closure, or public-claim boundaries.

• Phase 63 gate CLI guard note: gate:phase-63 rejects duplicate scalar gate output selectors (--output-dir, --run-id), and gate:phase-63-beam-closure rejects duplicate scalar closure-gate source/output selectors (--closure-report, --output-dir, --run-id) before reading or writing gate artifacts; both gate commands require --run-id to be a single path segment. This is BEAM gate evidence-input and gate-directory hardening only; it does not change answer score, recall, closure, or public-claim boundaries.

• Accepted BEAM measured full-run checkpoint (rules-only, evidence pack): run-phase63-beam-100k-live-closure-gpt55-evidence-pack-answer-hardening-current — 278/400 answer accuracy (0.695), evidence-chat recall 0.9620612564274538, missed-recall 20/355, wrong-answer 122/400, executionFailures: 0; prerequisite zero-failure diagnostic run-phase63-beam-100k-recall-diagnostic-rules-postmerge-current, gate run-phase63-beam-closure-gate-gpt55-evidence-pack-answer-hardening-current accepted. Models: gpt-5.5 answer + gpt-5.5 judge (ai.gurkiai.com). The answer context is built by the eval protocol reader src/eval/protocol-reader/evidencePack.ts (operation inferred from the question, source-ordered + timestamped, current-value/timeline/count/instruction/synthesis framing): +54 cases over the prior no-pack baseline (run-phase63-beam-100k-live-closure-gpt55-current, 224/400 = 0.56, same recall) and +17 cases over the prior evidence-pack checkpoint (run-phase63-beam-100k-live-closure-gpt55-evidence-pack-current, 261/400 = 0.6525). This is pipeline/gate evidence only: fitted recall 0.9621 vs generalization floor 0.6822, same-model judge bias, no numeric accuracy pass threshold, and still below the 0.70+ next improvement target. The measured full-run path supports goodmemory-rules-only and goodmemory-hybrid.

• BEAM answer-gap tooling is already present: scripts/analyze-phase-63-live-answer-gap.ts, scripts/run-phase-63-beam-live-ablation.ts, and the internal src/eval/protocol-reader/evidencePack.ts. Baseline no-pack analysis (run-phase63-beam-live-answer-gap-baseline-current) had 176 wrong: 103 full-recall-clean, 41 full-recall-noisy, 18 missing-evidence. The prior evidence-pack analysis (run-phase63-beam-live-answer-gap-evidence-pack-current) had 139 wrong: 76 full-recall-clean, 34 full-recall-noisy, 16 missing-evidence, 8 abstention, 5 unknown. The latest answer-hardening analysis (run-phase63-beam-live-answer-gap-answer-hardening-current) has 122 wrong: 58 full-recall-clean, 37 full-recall-noisy, 15 missing-evidence, 7 abstention, 5 unknown. The top repair families after the preference bucket split are conflict_update 29 (dominant full-recall-clean), instruction_following 27 (dominant full-recall-noisy), temporal_order 23 (dominant full-recall-clean), aggregate_count 15, summarization 9, preference_following 8, abstention 7, and the remaining judge_or_expected_answer 3. Answer-pack hardening now has live proof, not only unit proof; local pre-live hardening has also added latest-candidate target date/time/quantity cues, current-value filtering that keeps later sibling-entity metrics out of the ledger, conservative current-value stale-answer rewrite from updated/superseded target cues, contradiction minimal-pair extraction that leads with affirmative evidence, preserves weak affirmative wording such as registered/recommended/planned/invited without upgrading it to completion, suppresses adjacent implementation noise, recognizes same-turn strong did not / didn't denial clauses, and rewrites one-sided contradiction answers from the evidence guide into both-sides-plus-clarification answers, aggregate/count ledgers that preserve hyphenated and spaced compound word-number quantities and compute source-backed calendar interval candidates, conservative single-candidate calendar-interval answer rewrite, instruction answer-content cues that filter companion openers out of named tools/examples and surface concrete date, amount, percentage, date/format requirements, explicit response-content requirements, and comma-preserved numeric values, conservative instruction no-answer repair from explicit response-requirement cues, conservative generic instruction response-content repair from guide cues, temporal question-target timeline anchors that keep source order while filtering generic order/action words and reducing adjacent project noise, conservative unordered temporal-answer rewrite from source-ordered target anchors, value-bearing summary anchors, conservative summary no-answer repair from source-backed checklist cues, preference response-requirement cues that make lightweight/minimal-dependency, automation, step-by-step, direct-link, morning, and practical/logical constraints visible before answer support, conservative preference no-answer repair from those explicit response requirements, information-extraction coverage cues that preserve source-backed fields, deadlines, preparation steps, and required sub-items without adding unrequested identifiers, conservative extraction no-answer repair from source-backed detail cues, required summary source-coverage audits for late topic shifts, analyzer-level source-coverage warnings for expected cues found outside declared source chats, adjacent-only abstention rewrites for module-detail and atmosphere questions, and topic-specific missing-context abstention wording in focused live prompts. The focused summarization value-anchor live slice run-phase63-beam-live-slice-summary-value-anchors-prelive-current stayed at 1/9 correct with executionFailures: 0; its analyzer rerun run-phase63-beam-live-answer-gap-summary-value-anchors-current found 5/8 wrong summarization cases with source-coverage warnings (21 cues), so the next summarization repair is source-coverage / expected-answer compatibility rather than answer-pack-only prompt work. The full source-coverage audit run-phase63-beam-live-answer-gap-answer-hardening-source-coverage-current preserves the 122-wrong shape and adds status counts of 95 covered-or-no-warning, 15 expected-cues-outside-source, and 12 no-declared-source-ids; warning buckets are temporal_order 9/16, summarization 5/21, aggregate_count 2/4, conflict_update 1/2. Manual summarization audit classifies 9:summarization:1, 14:summarization:1, and 19:summarization:1 as declared-source mismatches, while 20:summarization:1 and 20:summarization:2 have no declared source ids. The corrected source-covered summarization slice run-phase63-beam-live-slice-summary-source-covered-v2-prelive-current filtered to 12:summarization:1 and 14:summarization:2, measured 1/2 with executionFailures: 0 and evidence recall 1.0, and leaves 14:summarization:2 as a source-covered expected-answer/source-content mismatch rather than a proven generic answer-pack repair. The broader source-covered preference+summarization slice run-phase63-beam-live-slice-pref-summary-source-covered-20260706-current measured 7/9 with executionFailures: 0 and evidence recall 1.0; its analyzer run-phase63-beam-live-answer-gap-pref-summary-source-covered-20260706-current leaves two full-recall-clean residuals: 18:preference_following:2 for preference constraint framing and 14:summarization:2 for structured summary / expected-answer compatibility. Preference guardrails now cover generic morning-routine ways answers and noisy practical/logical decision-preference answers. The full 9-row rerun run-phase63-beam-live-slice-pref-summary-source-covered-preference-ways-current stayed 7/9 because live variance introduced a new 12:preference_following:1 regression while 18:preference_following:2 passed; targeted validation run-phase63-beam-live-slice-preference-two-row-guardrails-current scored 2/2 with executionFailures: 0, evidence recall 1.0, and analyzer run-phase63-beam-live-answer-gap-preference-two-row-guardrails-current had zero wrong rows. The live-slice runner can filter --answer-gap-source-coverage-status covered-or-no-warning; use that filter for answer-pack-only slice validation so source metadata mismatches do not dilute the measurement. The next repair should target conflict/update resolution, instruction noise budgeting, temporal timeline granularity, count aggregation, summary/source coverage, preference constraints, information extraction coverage, abstention calibration, and judge/expected-answer compatibility without BEAM expected-answer-specific rules.

• Phase 63 BEAM source-audit update: analyzer run-phase63-beam-live-answer-gap-pref-summary-source-covered-source-audit-current preserves the focused 9-row rerun shape (7/9 correct in run-phase63-beam-live-slice-pref-summary-source-covered-preference-ways-current) but reroutes the remaining 14:summarization:2 wrong row to evidence-source selection: dominantSourceCoverageStatus=expected-cues-outside-source, one source-coverage warning, and expected cue planning resource found at chat 143 outside the declared evidence ids [4, 9, 13]. This keeps 12:preference_following:1 as an answer-time preference issue while preventing 14:summarization:2 from being treated as answer-pack-only summarization work.

• Phase 63 answer-gap / ablation CLI guard note: scripts/analyze-phase-63-live-answer-gap.ts and scripts/run-phase-63-beam-live-ablation.ts reject duplicate scalar source/output/mode selectors before reading live reports or writing derived evidence, including --benchmark-root, --live-report, --output-dir, --output-path where supported, --mode, --profile, --limit, --run-id, and --scale. They reject derived output report paths that resolve to the input --live-report before reading benchmark or live-report sources, and the answer-gap analyzer also rejects explicit --output-path values that resolve to any candidate BEAM source file under --benchmark-root; both tools require output --run-id values to be a single path segment before deriving default output paths. This is BEAM answer-gap/ablation evidence-input and output-directory hardening only; it does not change BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 base eval CLI guard note: eval:phase-63 rejects duplicate scalar source/output/run selectors before smoke or full report generation: --benchmark-root, --limit, --mode, --offset, --output-dir, --run-id, and --scale; repeated multi-value selectors such as --case-id, --profile, and --question-type remain repeatable. It also requires output --run-id values to be a single path segment before deriving smoke/full report directories. This is BEAM smoke/full evidence-input and evidence-directory hardening only; it does not change BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 recall diagnostic / analyzer CLI guard note: eval:phase-63-recall-diagnostic and analyze:phase-63-recall-diagnostic reject duplicate scalar source/report/output/run selectors before running recall diagnostics or comparing reports. The recall runner keeps repeated --profile support but makes --benchmark-root, --limit, --output-dir, --run-id, and --scale single-valued, and requires output --run-id values to be a single path segment before deriving the report directory; the analyzer makes --baseline-report-path, --baseline-run-id, --benchmark-root, --output-dir, --output-path, --profile, --report-path, --run-id, and --source-turn-limit single-valued, and requires --run-id / --baseline-run-id values to be single path segments before resolving default report paths. The analyzer also rejects output paths that resolve to either the analyzed report or the baseline report before reading inputs, and rejects output paths that resolve to any candidate BEAM source file under --benchmark-root before reading benchmark source rows. This is BEAM recall/noise evidence-input and report-directory hardening only; it does not change BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 BEAM source-root env guard note: prepare:phase-63-beam, eval:phase-63, eval:phase-63-recall-diagnostic, eval:phase-63-live-slice, eval:phase-63-live-closure, scripts/analyze-phase-63-live-answer-gap.ts, and scripts/run-phase-63-beam-live-ablation.ts reject empty or whitespace-padded GOODMEMORY_BEAM_ROOT fallback values before source-root or output-root resolution. This is BEAM root-prep, smoke/full, recall, live, answer-gap, and ablation source-root integrity hardening only; it does not change BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 initial report analyzer guard note: analyze:phase-63-beam rejects duplicate scalar source/output/run selectors (--report-path, --output-path, --run-id) before reading the source report or writing miss-case analysis, requires --run-id to be a single path segment before resolving the default source report path, and rejects output paths that resolve to the input --report-path before reading the source report. This protects the early BEAM miss-case workbench evidence from repeated-selector ambiguity, source-report path traversal, or source-report overwrites without changing BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 live-slice / live-closure CLI guard note: eval:phase-63-live-slice now rejects malformed repeated selector flags before reading answer-gap or benchmark files. --answer-gap-bucket, --answer-gap-source-coverage-status, and --case-id values must be present, non-empty, unpadded, and unique, and answer-gap buckets/source-coverage statuses are allow-listed. The live-slice and live-closure parsers also reject duplicate boolean mode switches (--evidence-pack, --resume) and scalar source/output selectors where supported, including --answer-gap-report, --benchmark-root, --case-selection, --limit, --output-dir, --profile, --recall-report, --run-id, and --scale, before report generation; --run-id must be a single path segment. This is focused-slice, closure, and live-evidence-directory integrity hardening only; it does not change BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 live-slice selection-lineage note: new eval:phase-63-live-slice reports persist optional selection metadata for explicit case ids, case-selection mode, recall report path, answer-gap report path, answer-gap buckets, source-coverage filters, and limit. This makes focused answer-gap slice evidence auditable without relying on run-id naming conventions; it is metadata hardening only and does not change BEAM scores, recall, closure status, or public-claim boundaries.

• Phase 63 live-closure coverage guard note: eval:phase-63-live-closure now rejects live reports whose cases.length does not cover the expected full BEAM case count, and rejects present selection metadata unless it proves the report came from caseSelection="all-cases" with no answer-gap filters, explicit case ids, or limit. This prevents focused slices or summary-only artifacts from being wrapped as closure evidence; it does not change BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Phase 63 closure-gate summary consistency note: gate:phase-63-beam-closure now rejects closure reports whose profilesCompared does not contain exactly the closure profile, whose correctCases + wrongAnswerCases does not equal totalCases, or whose answerAccuracy does not equal correctCases / totalCases. This keeps hand-edited or internally inconsistent closure artifacts from passing the gate without changing BEAM scores, recall, checkpoint status, or public-claim boundaries.

• Latest local BEAM pre-live infrastructure check: /private/tmp/BEAM/100K.json rebuilt from GitHub raw via prepare:phase-63-beam (20 rows), eval:phase-63 and gate:phase-63 passed with executionFailures: 0, and run-phase63-beam-100k-recall-diagnostic-rules-prelive-current compared with run-phase63-beam-100k-recall-diagnostic-rules-postmerge-current at caseDeltaCount: 0 (evidence-chat recall 0.9620612564274538, missed 20/355, wrong-recall/noise 167/400, hit/missing/noise 1023/71/807). This is refreshed root/recall readiness, not answer-performance evidence.

• MemoryAgentBench (Phase 64) is closed as the agent-memory hardening slice. The reproducible external root (prepare:phase-64-mab) and deterministic upstream match-mode scorer are in place; the accepted zero-failure AR/CR live closure (run-phase64-mab-ar-cr-live-closure-rerun-current) measured CR 0.959 and AR 0.67, while TTL/LRU exposed answer-format boundaries. CR 0.959 reproduced the prior hand-made CR A/B on the reproducible root, so the shared src/answer/currentValueResolution.ts current-value resolution is not BEAM-only; the AR retrieval gap also drove the general zero-retrieval lexical fallback with caseDeltaCount 0 on the 100K rules-only recall diagnostic. P67-C later recorded historical four-competency evidence (CR 0.959, TTL 0.767, AR 0.890, LRU 0.518; executionFailures: 0 over 259 questions). The current v0.6.0 public-opt-in declaration retains judge-free CR 0.9589041096 and raises TTL to 0.9333333333 versus no-memory 0.000; AR/LRU remain excluded because multiple-choice leakage makes them non-diagnostic.

• Phase 64 external-root prep CLI guard note: prepare:phase-64-mab rejects duplicate --merge and duplicate scalar source/output/budget selectors before fetching upstream rows or writing cases.json, including --competency, --dataset, --offset, --max-questions, --max-chunks, --max-evidence-facts, and --output-root. This is fixture-prep input hardening only; it does not change accepted MemoryAgentBench closure evidence or the scoped public claim.

• Phase 64 readiness analyzer guard note: analyze:phase-64-readiness rejects duplicate scalar source/output selectors (--phase63-analysis-path, --output-dir, --output-path, --run-id) before reading Phase 63 analysis or writing prep evidence, requires --run-id to be a single path segment before deriving the default output path, and rejects an output path that resolves to the input --phase63-analysis-path before reading the Phase 63 analysis file. This is prep-report input/source/output hardening only; it does not change accepted MemoryAgentBench closure evidence or the scoped public claim.

• Phase 64 smoke/live CLI guard note: eval:phase-64-smoke rejects duplicate --evidence-pack, --live, --no-memory, and --resume flags plus duplicate scalar source/output selectors (--benchmark-root, --limit, --output-dir, --run-id) before report generation, requires --run-id to be a single path segment, and requires --limit to be a canonical positive integer string rather than scientific or decimal notation. This is evidence-input, evidence-directory, and budget-selector hardening only; it does not change accepted MemoryAgentBench closure evidence or the scoped public claim.

• Phase 64 MemoryAgentBench source-root env guard note: prepare:phase-64-mab and eval:phase-64-smoke reject empty or whitespace-padded GOODMEMORY_MAB_ROOT fallback values before output-root or benchmark-root resolution. This is fixture-prep, retrieval, and live source-root integrity hardening only; it does not change accepted MemoryAgentBench closure evidence or the scoped public claim.

• LoCoMo's current v0.6.0 public-opt-in declaration covers all 1540 non-adversarial questions and reports strict token-F1 0.6298701299, independent official-protocol accuracy 0.8707792208, and open-domain 59/96 = 0.6145833333, with zero execution/judge failures and the CC BY-NC 4.0 non-commercial disclosure. Its older versioned declaration (strict 0.6117, judge-protocol 0.837) and Phase 65 P4 full-10 result (0.6198 versus no-memory 0.2276 over 1986 questions) remain historical evidence. Phase 65 case-level hardening is paused; Phase 69 owns generalized candidate admission and noise control. Earlier live answer generator + evidence-pack wiring (commit 3f9cf5e, --live --evidence-pack, gpt-5.5, deterministic LoCoMo match-mode scoring, no judge) and reproducible non-vendored external-root prep (commit ed08dd9, prepare:phase-65-locomo) are on main. A representative single-conversation pressure run (locomo-live-pack-full, full conversation 1, 199 questions, executionFailures: 0) measured overall answer accuracy 0.020 (4/199), purely recall-bound. Follow-up eval-only retrieval research ruled out positional dialog windows, rules-light query expansion, and LLM turn-caption enrichment (commit 2b2ec71), and P65-R003 later found a real neural endpoint ties BM25 exactly; the refined bottleneck is candidate-pool admission because additive semantic/BM25 scoring only re-ranks already-admitted lexical candidates. Source-execution guard note: eval:phase-65-reanswer-report rejects source reports with non-zero executionFailures before source answer-row completeness checks, so failed retrieval/live-source artifacts cannot be reused as gold-evidence-only or answer-policy replay inputs. Reanswer run-directory guard note: eval:phase-65-reanswer-report now requires output --run-id values to be a single path segment at CLI parse time and in the programmatic runner before source reports are read. This is reanswer evidence-directory hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries. Retrieval-probe CLI guard note: the eval-only dialog-window and rules-light query-expansion probes reject duplicate scalar source/run/window selectors (--benchmark-root, --run-id, --window-radius) before writing comparison reports, require --run-id to be a single path segment, require --window-radius to be a positive integer, and reject empty or whitespace-padded GOODMEMORY_LOCOMO_ROOT fallback values before benchmark-root resolution. This is evidence-input, source-root, and report-directory integrity hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries. Smoke/live source-root and run-directory guard note: eval:phase-65-smoke now requires --run-id to be a single path segment before writing smoke reports, live progress checkpoints, or extraction caches under --output-dir, and rejects empty or whitespace-padded GOODMEMORY_LOCOMO_ROOT fallback values before benchmark-root resolution. This is source-root and evidence-directory hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries. Provider-run timeout/resume guard note: eval:phase-65-smoke now supports --provider-embedding-timeout-ms and --provider-embedding-run-timeout-ms for provider-backed LoCoMo probes, and provider-backed retrieval-only runs now checkpoint completed question rows through live-progress.jsonl for --resume. The 7-question near-miss rel0.8 retry with 5s embedding requests and a 60s run watchdog now exits with LocomoProviderEmbeddingRunTimeoutError while starting locomo-conv-42; it wrote only the progress config header before timing out. Resume also rejects duplicate checkpoint rows, checkpoint rows outside the selected question scope, malformed non-tail checkpoint JSON, and non-header JSON objects that do not match the full progress-row shape before replaying cached results; only the final torn JSON line from a killed run is tolerated, and legacy checkpoints may still omit answerTokenF1. The explicit 1ms watchdog proof locomo-multihop-near-miss-label-rel08-retrieval-timeout-partial-current produced a partial report with 7 selected rows, 7 executionFailures, and zero retrieved turns. This is timeout and checkpoint-accounting evidence only, not retrieval recovery. Failure-row retention note: eval:phase-65-smoke now keeps failed selected rows in nonzero-failure reports for seed, recall, provider-run-timeout, and answer-generation errors, but does not checkpoint those failed rows. New failed rows carry optional executionFailureStage and executionFailureMessage metadata, and shared report validation rejects malformed stage/message pairs or zero-failure rows that still carry failure metadata. Failed rows remain retryable under --resume and still cannot be used as clean source evidence while executionFailures is nonzero. Shared smoke-report validation also rejects live-answer reports whose executionFailures count does not equal the number of failed rows with null answerCorrect and null generatedAnswer, keeping failure accounting auditable before downstream analyzers consume the report. Evidence-pack category-operation routing note: LoCoMo live/reanswer evidence-pack contexts now pass multi_hop into the shared multi_session_reasoning answer framing and adversarial into the shared abstention answer framing before live answer generation. This is deterministic answer-context hardening for multi-hop/no-answer repair only; it is not new live-score evidence, default promotion, or a public-claim change. Current local code has opt-in semantic candidate-generation union plumbing (retrieval.semanticCandidates, --semantic-candidates, runner flag --provider-embedding) with external-root provider evidence. The bounded-noise topK16/maxAdditions4 point lifted conv-1 live accuracy from 4/199 (0.020) to 97/199 (0.487), held-out conv-30 to 67/105 (0.638), held-out conv-41 to 95/193 (0.492), held-out conv-44 to 85/158 (0.538), and held-out conv-42 to 106/260 (0.408), all with executionFailures: 0. The adversarial abstention scorer repair is deterministic: No information available adversarial gold accepts explicit abstention aliases like I do not know, while still rejecting the tempting answer; --resume re-scores checkpointed live answers with the current scorer. Full-root category slices are now assembled by summarize:phase-65-locomo-categories into locomo-category-matrix-top16-add4-live-pack-current/category-summary.json: 1986 questions, 983/1986 live accuracy (0.4949647533), weighted evidence recall 0.5884050761, 1081/1986 fully retrieved, noise 15235, and executionFailures: 0. The category-gap diagnostic locomo-category-gap-analysis-top16-add4-live-pack-current/category-gap-analysis.json splits the 1003 wrong answers into 647 missing-evidence wrong rows and 356 full-recall-but-noisy wrong rows, with 0 clean full-recall wrong rows. Category summary and category-gap artifacts now include per-source questionCount lineage in sourceReports, so assembled/gap totals can be audited against their input shard sizes, and Phase 65 JSON post-processors/reanswer replay reject smoke reports whose top-level questionCount does not match cases.length before computing derived evidence. Follow-up retrieval-only budget probes showed decomposition/iteration is not the open_domain lever (recall 0.2763991013 -> 0.2822990939, noise 696 -> 858), while wider topK32/maxAdditions8 semantic admission improves missing-evidence categories at a noise cost: open_domain recall 0.3536560458 / 26/96 fully retrieved / noise 1050, multi_hop recall 0.3972616166 / 48/282 / noise 3237. The new relative-score floor (minRelativeScore) trims that wider-admission noise while preserving part of the gain: topK32/maxAdditions8/rel0.8 measured open_domain 0.3432393791 / 25/96 / noise 936 and multi_hop 0.3767491208 / 42/282 / noise 2939; the budget-delta analyzer shows open_domain has the better retrieval/noise tradeoff at +0.0278501157 recall per 100 added noise turns versus multi_hop +0.0068534205. The first wider-admission live validation, locomo-open-domain-semantic-provider-top32-add8-rel08-live-pack-current, did not convert that retrieval gain into answer gain: topK16/maxAdditions4 and topK32/maxAdditions8/rel0.8 both score 22/96 (0.2291666667) open_domain answer accuracy with executionFailures: 0, while the gap analysis moves wrong rows from 66 missing-evidence / 8 full-recall-noisy to 59 missing-evidence / 15 full-recall-noisy. The live-delta diagnostic locomo-open-domain-top16-add4-vs-top32-add8-rel08-live-delta-current/live-delta.json shows why this is not defaultable: 3 answers improved, 3 regressed, +6 fully retrieved, +240 noise turns, 9 unconverted retrieval gains, and 3 noisy full-recall regressions. The opt-in answer-policy probe locomo-open-domain-rel08-commonsense-live-current then held retrieval/noise fixed and enabled --allow-commonsense-resolution: open_domain improved to 27/96 (0.28125) with executionFailures: 0, and locomo-open-domain-rel08-vs-commonsense-live-delta-current/live-delta.json shows 7 improvements, 2 regressions, 20 same-correct, 67 same-wrong, 0 retrieval delta, and 1 noisy full-recall regression. The category-scoped strict guard validation locomo-open-domain-rel08-commonsense-strict-live-current keeps most of that open_domain gain while carrying --strict-no-evidence-abstention: 26/96 (0.2708333333), executionFailures: 0; strict-vs-nonstrict delta shows 1 improvement, 2 regressions, and -1 net, while strict-vs-non-commonsense rel0.8 still shows +4 net (6 improvements, 2 regressions). Its gap artifact has 57 missing-evidence wrong rows and 13 full-recall-noisy wrong rows. A targeted adversarial/no-answer replay over 15 baseline-correct rows (locomo-adversarial-commonsense-safety-reanswer-current) reused the original retrieved turn ids and scored 15/15 with executionFailures: 0; its delta versus no-commonsense replay shows 1 improvement, 0 regressions, and no retrieval/noise delta, which is narrow safety evidence. The broader 60-row adversarial/no-answer replay showed non-strict commonsense is not safe enough by itself: locomo-adversarial-commonsense-safety-reanswer-broad60-current tied no-commonsense at 46/60 (0.7666666667) and introduced a zero-recall abstention regression (conv-26:q181 became a plate). The opt-in category-scoped strict abstention guard --strict-no-evidence-abstention plus commonsense (locomo-adversarial-commonsense-strict-safety-reanswer-broad60-current) scored 48/60 (0.8), executionFailures: 0, with 2 improvements, 0 regressions, 46 same-correct, 12 same-wrong versus both no-commonsense and non-strict commonsense deltas; it restored conv-26:q181 to abstention and repaired conv-43:q210, lowering missing-evidence wrong rows from 13 to 11 while leaving 1 full-recall-noisy wrong row. The new answer-policy slice selector (analyze:phase-65-locomo-answer-policy-slice) wrote locomo-cross-category-answer-policy-slice-current/answer-policy-slice.json, a 45-row manifest across single_hop, multi_hop, and temporal, and now preserves source report provenance per selected question while splitting same-category reanswerJobs by source report. The first single_hop replay showed global commonsense is unsafe outside open_domain: baseline locomo-single-hop-answer-policy-slice-baseline-current scored 6/15, global commonsense+strict locomo-single-hop-answer-policy-slice-commonsense-strict-current scored 5/15, and delta locomo-single-hop-answer-policy-slice-commonsense-strict-delta-current/live-delta.json shows -1 net with 1 noisy full-recall regression. The current prompt scopes commonsense resolution to open_domain; completed open_domain-scoped manifest deltas show single_hop 0 net with 0 regressions, multi_hop -1 net with 1 improvement and 2 regressions, and temporal 0 net with 1 improvement and 1 regression. eval:phase-65-reanswer-report now retries transient answer-generation failures before counting execution failures, retains hard-failed selected rows with null answer fields, accepts --question-id-file for manifest-driven replay, and adds --gold-evidence-only-context for gold-label noise-isolation replay over retrieved gold evidence only; this recovered the temporal baseline rerun to 15/15 answered and executionFailures: 0, while making future answer-policy and noise-isolation replay queues reproducible without silently dropping failed rows. This is answer-policy hardening plus negative clearance evidence, not default-profile promotion: open_domain retains most but not all of the commonsense gain, multi_hop still regresses on the selected risk slice, and unresolved missing-evidence/noise failures remain. Category blockers remain: single_hop 457/841, open_domain 22/96 by the non-commonsense rel0.8 baseline (27/96 non-strict commonsense; 26/96 category-scoped strict commonsense), multi_hop 86/282, temporal 178/321, and adversarial 240/446. A conv-44 minSimilarity sweep did not find a defaultable noise fix, and BEAM rules-only safety run run-phase63-beam-100k-recall-diagnostic-rules-semantic-union-safety-current compared against the prelive baseline at caseDeltaCount: 0. These are historical Phase 65 diagnostics; Phase 69 owns generalized retrieval, while the current LoCoMo row is the strict/judge dual-track declaration. No upstream data is vendored (MemoryAgentBench MIT; LoCoMo CC BY-NC 4.0, non-commercial).

• Phase 65 answer-policy bucketed replay note: newly generated analyze:phase-65-locomo-answer-policy-slice manifests now split reanswerJobs by source report, QA category, and answer-policy risk bucket (baselineCorrectHighNoise, wrongFullRecallNoisy, wrongMissingEvidence). eval:phase-65-reanswer-report --reanswer-job-bucket accepts those buckets, so follow-up replay can isolate one answer-policy risk bucket and one category without manual question-id copying. Legacy bucketless answer-policy manifests remain category-filterable, and analyze:phase-65-locomo-answer-policy-slice -- --existing-slice <path> upgrades already-selected slices without re-reading legacy source reports that predate current answer-context lineage checks. The local locomo-cross-category-answer-policy-slice-current/answer-policy-slice.json artifact now has 9 bucketed jobs covering the same 45 selected rows. This is replay-routing/auditability hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries.

• Phase 65 reanswer readiness and replay note: analyze:phase-65-locomo-reanswer-readiness checks manifest reanswerJobs against their declared source reports before live replay, rejects non-LoCoMo manifests and malformed source provenance, and emits explicit-question-id replayPlan.commands only for jobs whose source report is readiness-proven. The legacy audit locomo-cross-category-answer-policy-reanswer-readiness-current/reanswer-readiness.json over locomo-cross-category-answer-policy-slice-current/answer-policy-slice.json correctly found 9/9 jobs blocked because the old single_hop, multi_hop, and temporal sources lacked answerContextMode lineage. That source-readiness blocker is now cleared: the three current-lineage source refreshes completed with 45/45 answered, 19/45 correct, and executionFailures: 0; the rebuilt slice locomo-cross-category-answer-policy-reanswer-readiness-current-slice-refresh-current/answer-policy-slice.json selected 40 rows across 9 bucket/category jobs; and locomo-cross-category-answer-policy-reanswer-readiness-after-source-refresh-current/reanswer-readiness.json reports 9/9 ready, 0 blocked, with live-answer and provider-embedding env preflight ready. The regenerated replay reports cover 40/40 rows, score 15/40 with executionFailures: 0, and no longer inherit source questionSelection. The subset-aware aggregate artifact locomo-cross-category-answer-policy-reanswer-delta-aggregate-current/reanswer-delta-aggregate.json summarizes the nine replay deltas against their refreshed source subsets: baseline 15 correct vs replay 15 correct, net 0, with 2 improvements, 2 regressions, 13 same-correct rows, 23 same-wrong rows, 7 token-F1 near misses, and no retrieval/noise delta. Bucket totals isolate the only positive lift to wrongFullRecallNoisy (+2 over 10 rows) while baselineCorrectHighNoise regresses -2 over 15 rows and wrongMissingEvidence stays 0/15. Category totals are multi_hop +2, single_hop -1, and temporal -1. This is source-readiness and answer-policy replay evidence, not LoCoMo default-profile promotion or public-claim movement.

• Latest LoCoMo effective answer-policy and context diagnostic (Phase 65): analyze:phase-65-locomo-live-delta now records per-question effective scoped prompt policy, answer context mode changes, and answerChangeAttribution objects. New smoke/reanswer rows also persist optional raw answerTokenF1, live-delta baseline/candidate side records preserve it, and the new answerTokenF1NearMiss reanswer bucket routes non-adversarial wrong rows whose candidate token-F1 is above zero but below the pass threshold for answer-contract and label-compatibility review without changing boolean correctness. For compatible historical live reports that predate only the token-F1 field, the live-delta CLI backfills missing answerTokenF1 in memory from the report benchmarkSource / external root before writing derived artifacts, and rejects output paths that would overwrite the benchmark cases.json source before loading it, without rewriting source reports or rerunning answer generation; older reports that also lack required compatibility metadata such as answerContextMode still fail fast. The refreshed multi_hop candidate-admission delta locomo-multihop-candidate-admission-rel08-token-f1-delta-current/live-delta.json proves the path on real reports: same 28-row source pair, +4 net answers, 10 diagnostic answerTokenF1NearMisses, and 8 unique answerTokenF1NearMiss replay ids after noisy-full-recall priority de-duplication. The follow-up normal-context replay locomo-multihop-answer-token-f1-near-miss-reanswer-current reran those 8 ids with executionFailures: 0 and scored 0/8; replay raw token-F1 averaged 0.2515 versus 0.2621 in the source near-miss queue, so simple reanswering does not recover the bucket. The subset-aware delta locomo-multihop-answer-token-f1-near-miss-reanswer-delta-current/live-delta.json now compares the full source report to that 8-row replay via preserved sourceReport lineage: 0 improvements, 0 regressions, 8 same-wrong, no retrieval/noise delta, and 7 rows still queued as answerTokenF1NearMiss. The near-miss label analysis locomo-multihop-answer-token-f1-near-miss-label-analysis-current/near-miss-label-analysis.json joins those 7 rows back to the benchmark source and classifies them as 5 balanced partial overlaps, 1 over-specified answer, 1 under-specified answer, 0 numeric/frequency-format rows, with 0 full-recall, 5 partial-recall, and 2 zero-recall rows; average replay token-F1 is 0.2874722639. That artifact now carries reusable top-level/category questionIds, candidate sourceReports lineage, plus four repairJobs grouped by diagnosis and partial/zero retrieval, and locomo-multihop-near-miss-label-file-loader-smoke-current consumed it as a 7-question retrieval-only selection with executionFailures: 0; default retrieval found 0/7 fully retrieved, average evidence recall 0, and 31 noise turns, so this is queue/loader proof rather than retrieval recovery. Summary counts separate answer changes that overlap retrieval-metric changes, effective prompt-policy changes, answer-context-mode changes, or residual live answer changes where none of those observable drivers changed. The regenerated open_domain-scoped single_hop/multi_hop/temporal slice deltas all have effectiveAnswerPolicyChangedCount: 0 across their 15-question slices; multi_hop's -1 net and temporal's mixed tie are therefore live-repeatability/validation-risk evidence under unchanged effective prompt policy, not proof that scoped commonsense/strict instructions caused those answer changes. In contrast, locomo-open-domain-rel08-vs-commonsense-strict-live-delta-current/live-delta.json has effectiveAnswerPolicyChangedCount: 96, so its +4 net remains the real open_domain scoped commonsense prompt-policy signal. The answer-context-mode counters and answer-change attribution counts serve the same attribution role for --gold-evidence-only-context noise-isolation comparisons. Live-delta artifacts also emit candidate-sourced reanswerJobs for top noisy full-recall wrong rows, answer regressions, improvements, unconverted retrieval gains, and residual live answer changes; diagnostic arrays can overlap, but exported jobs are priority-assigned with unique question ids across buckets and carry selected category metadata plus source report provenance and a top-level sourceReports entry for the candidate report. Follow-up row validation is reproducible through the existing --question-id-file path; --reanswer-job-bucket noisyFullRecallWrong can isolate the gold-evidence-only noise subset, --reanswer-job-bucket answerTokenF1NearMiss can isolate token-F1 near misses, --reanswer-job-category can isolate a QA category, category-only replay works for answer-policy slice manifests whose reanswerJobs are bucketless, and filtered replay narrows same-category multi-source manifests to jobs matching the supplied --source-report while unfiltered manifest replay still rejects mixed-source jobs.

• Phase 65 focused multi_hop near-miss live-answer validation note: the 10-row rel0.8 multi_hop near-miss queue now has a same-provider live comparison. Provider-only live baseline locomo-multihop-near-miss-provider-baseline-live-10row-timeout15-current scored 0/10 with average evidence recall 0, 0/10 fully retrieved, 44 noise turns, and executionFailures: 0; rel0.8 semantic admission locomo-multihop-near-miss-rel08-live-10row-timeout15-current also scored 0/10 but raised evidence recall to 0.4142857143, found 2/10 fully retrieved rows, and carried 107 noise turns with executionFailures: 0. The paired live-delta locomo-multihop-near-miss-provider-vs-rel08-live-10row-timeout15-delta-current/live-delta.json records answer delta 0, 10 same-wrong rows, +2 fully retrieved, +63 noise turns, 7 unconverted retrieval gains, 2 full-recall noisy wrong rows, and 9 answerTokenF1NearMisses. The current label artifact locomo-multihop-near-miss-rel08-live-10row-timeout15-label-analysis-current/near-miss-label-analysis.json classifies those 9 near misses at average token-F1 0.2652996301 and average declared-evidence support 0.6553631554: 6 balanced partial overlaps, 1 numeric/frequency-format, 1 over-specified, 1 under-specified, with 2 full-recall, 5 partial-recall, and 2 zero-recall rows. This confirms the targeted admission lever helps retrieval on the selected queue but has not yet converted answer correctness; next work is answer synthesis, label-compatibility, and noise control, not default-profile promotion or public-claim movement.

• Phase 65 focused multi_hop near-miss gold-evidence-only replay note: locomo-multihop-near-miss-rel08-live-10row-timeout15-gold-only-current reanswered the 9 token-F1 near-miss rows from the rel0.8 live queue using only retrieved gold evidence turns in the answer context, without rerunning retrieval. It scored 1/9 (0.1111111111) with executionFailures: 0, preserving the same average evidence recall 0.4603174603, 2/9 fully retrieved rows, and 95 noise turns as the selected source subset. The paired delta locomo-multihop-near-miss-rel08-live-10row-timeout15-normal-vs-gold-only-delta-current/live-delta.json records +1 answer, 0 regressions, no retrieval/noise delta, and the single improvement conv-42:q76 under partial->partial recall; the answer change is attributed to answerContextMode only. The follow-up label artifact locomo-multihop-near-miss-rel08-live-10row-timeout15-gold-only-label-analysis-current/near-miss-label-analysis.json leaves 6 near misses at average token-F1 0.3473556944 and average declared-evidence support 0.5997113997: 5 balanced partial overlaps and 1 under-specified answer, with 2 full-recall and 4 partial-recall rows. This shows gold-only context can recover one partial-evidence row but does not broadly solve the near-miss queue; remaining work stays in answer synthesis, label compatibility, and candidate admission rather than default-profile promotion.

• Phase 65 residual near-miss queue loader proof: locomo-multihop-near-miss-gold-only-label-file-loader-smoke-current consumed the 6-row residual gold-only label artifact with executionFailures: 0, while default retrieval found 0 evidence recall, 0/6 fully retrieved, and 29 noise turns. Filtered loader proofs cover every emitted repair job: locomo-multihop-near-miss-gold-only-label-balanced-full-loader-smoke-current selects the 2 balanced/full rows and finds 0 recall with 9 noise turns; locomo-multihop-near-miss-gold-only-label-balanced-partial-loader-smoke-current selects the 3 balanced/partial rows and finds 0 recall with 14 noise turns; locomo-multihop-near-miss-gold-only-label-under-specified-partial-loader-smoke-current selects the 1 under-specified/partial row and finds 0 recall with 6 noise turns. This makes the residual queue reproducible for targeted repair, and confirms default retrieval cannot recover it without candidate admission.

• Phase 65 residual near-miss rel0.8 candidate-admission proof: the same 6-row residual queue now has a provider-backed retrieval comparison. Provider-only baseline locomo-multihop-near-miss-gold-only-label-provider-baseline-6row-timeout15-current found 0 average evidence recall, 0/6 fully retrieved, 29 noise turns, and executionFailures: 0; rel0.8 semantic admission locomo-multihop-near-miss-gold-only-label-rel08-retrieval-6row-timeout15-current reached 0.6071428571 average evidence recall, 2/6 fully retrieved, 67 noise turns, and executionFailures: 0. The paired budget delta locomo-multihop-near-miss-gold-only-label-provider-vs-rel08-retrieval-6row-timeout15-delta-current/budget-delta.json records +0.6071428571 recall, +2 fully retrieved, +38 noise turns, and 1.5977443609 recall per 100 added noise turns. This is targeted retrieval repair evidence for the residual queue only; it is not live-answer score movement, default-profile promotion, or public-claim evidence.

• Latest LoCoMo candidate-admission repair queues (Phase 65): analyze:phase-65-locomo-candidate-admission-slice now writes deterministic question-level manifests from paired baseline/candidate reports. Rel0.8 retrieval-only selection produced locomo-open-domain-candidate-admission-slice-rel08-current with 22 selected questions (6 full-retrieval gains, 6 partial gains still missing, 10 stubborn missing; 65 stubborn-missing rows available) and locomo-multihop-candidate-admission-slice-rel08-current with 28 selected questions (8 full-retrieval gains, 10 partial gains still missing, 10 stubborn missing; 197 stubborn-missing rows available). The open_domain live-aware manifest locomo-open-domain-live-candidate-admission-slice-rel08-current selects 32 questions and exposes 15 available noisy full-recall wrong rows, selecting 10. Candidate manifests also emit reanswerJobs for selected candidate-side full-recall noisy wrong rows, including selected rows whose primary repair bucket is a retrieval-gain bucket, and expose top-level sourceReports candidate-report lineage; in reanswer-mode manifest loading, file-local reanswerJobs take strict precedence over top-level questionIds, broader repairJobs, and category fallbacks, and an explicitly empty preferred reanswerJobs queue fails instead of falling back to broader queues, while explicit CLI --question-id values remain additive. This keeps gold-evidence-only noise isolation from accidentally replaying broader missing-evidence queues. Selected jobs must carry sourceRunId or sourceReportPath; reanswer replay rejects missing job-level source provenance, mismatched --source-report run ids, mismatched source report paths, mixed-source selected jobs, non-string selected question ids, invalid or mismatched questionCount values, missing candidateReport / sourceReports runId-or-path identities, duplicate selected sourceReports lineage, and manifest-internal candidateReport / selected sourceReports provenance conflicts before loading the benchmark root, while category-filtered answer-policy replay may ignore unrelated top-level sourceReports from other categories. Generated reanswer smoke reports persist sourceReport lineage with retrieval-config metadata plus reanswerSelection metadata for explicit ids, manifest path, bucket filters, and category filters for later audit; shared report validation also rejects reanswer artifacts that carry selected questionIds without either explicit ids or the manifest path that selected them, preserve a manifest path without selected question ids or job filters, or declare explicit ids/job filters without a top-level selected questionIds header. Bucket/category-filtered replay can target one named reanswerJobs queue and one QA category, and hard answer-generation failures keep their selected rows with null answer fields plus executionFailures. The runner now consumes these queues via --question-id-file and rejects duplicate --case-id / --category smoke scope filters before report generation; retrieval-only file-loader smokes loaded both manifests with executionFailures: 0: locomo-open-domain-candidate-admission-file-loader-smoke-current loaded the 22-question open_domain manifest, and locomo-multihop-candidate-admission-file-loader-smoke-current loaded the 28-question multi_hop manifest at 0.4702380952 evidence recall, 8/28 fully retrieved, and 282 noise turns. These are targeted repair queues, not default-promotion evidence or LoCoMo closure.

• Latest LoCoMo open_domain full-recall noise-isolation replay (Phase 65): current targeted live source locomo-open-domain-full-recall-wrong-live-strict-current reran 13 strict open_domain full-recall wrong rows with topK32/maxAdditions8/rel0.8, commonsense, strict no-evidence abstention, and evidence-pack context. It scored 3/13 with average evidence recall 1, 13/13 fully retrieved, 112 noise turns, and executionFailures: 0. Same-context reanswer locomo-open-domain-full-recall-wrong-reanswer-normal-current scored 1/13; delta locomo-open-domain-full-recall-wrong-normal-delta-current/live-delta.json shows -2 net from residual live-answer changes under unchanged retrieval/context/policy. Gold-evidence-only replay locomo-open-domain-full-recall-wrong-reanswer-gold-only-current scored 4/13; delta locomo-open-domain-full-recall-wrong-gold-only-delta-current/live-delta.json shows +1 net (2 improvements, 1 regression), all rows full->full, and answer-context-mode attribution for all answer changes. The residual near-miss analysis locomo-open-domain-full-recall-wrong-gold-only-near-miss-label-analysis-current classified 4 full-recall rows as 3 rationale-bearing gold-answer rows, 0 under-specified, 0 numeric/frequency-format, and 1 balanced partial-overlap, with average token-F1 0.2470619658; the classifier now gives answer-token subsets with nonnumeric missing rationale their own label-compatibility bucket instead of misrouting them as under-specified or numeric/frequency issues. The artifact emits full-recall repair jobs for the 3-row rationale-bearing bucket and the 1-row balanced bucket. Broad loader smoke locomo-open-domain-full-recall-wrong-gold-only-near-miss-label-file-loader-smoke-current consumed the queue with executionFailures: 0, while default retrieval found only 1/4 fully retrieved, average evidence recall 0.25, and 11 noise turns. The smoke runner can now filter those repair jobs by diagnosis and retrieval bucket; locomo-open-domain-rationale-bearing-full-repair-file-loader-smoke-current selected the three rationale-bearing/full rows (conv-26:q64, conv-42:q60, conv-26:q22) with executionFailures: 0, while default retrieval found 0/3 evidence recall and 9 noise turns. Noise stripping helps selected rows but is not stable or broad enough for default promotion; the residual queue mixes rationale-bearing gold label work with default-retrieval gaps and one closed-world / no-positive-evidence edge.

• Phase 65 targeted smoke selection-lineage note: targeted eval:phase-65-smoke reports now persist questionSelection for explicit question ids, manifest paths, and repair-job filters, and shared report validation rejects malformed present lineage. The regenerated locomo-open-domain-rationale-bearing-full-repair-file-loader-smoke-current report records the near-miss manifest path plus repairJobDiagnoses=["rationale-bearing-gold-answer"] and repairJobRetrievalBuckets=["full"]. This is auditability hardening only; it does not change LoCoMo scores, default status, or public-claim boundaries.

• Latest LoCoMo open_domain unconverted retrieval-gain probe (Phase 65): because the older full-root rel0.8 live report predates required answer-context lineage, the nine topUnconvertedRetrievalGains ids were rerun as locomo-open-domain-top-unconverted-rel08-source-current with topK32/maxAdditions8/rel0.8, live evidence-pack answers, 0/9 accuracy, average evidence recall 0.6851851852, 4 fully retrieved, 90 noise turns, and executionFailures: 0. Gold-evidence-only replay locomo-open-domain-top-unconverted-reanswer-gold-only-current recovered 1/9 with identical retrieval metrics; delta locomo-open-domain-top-unconverted-normal-vs-gold-only-delta-current/live-delta.json shows +1, 0 regressions, and 8 same-wrong. The first same-source commonsense replay stayed at 0/9 because the system allowed open_domain commonsense while the user prompt still said to answer using only dialog context. The current prompt aligns that path and asks for the requested type directly; locomo-open-domain-top-unconverted-reanswer-commonsense-bridge-current recovered 1/9 with no regressions, while a grounding-phrase variant was rejected after locomo-open-domain-top-unconverted-reanswer-commonsense-bridge-grounded-current fell back to 0/9. This is a narrow answer-contract win, not closure: the open_domain unconverted-gain blocker still routes to targeted admission plus answer/context organization and label-compatibility review.

• Latest LoCoMo multi_hop candidate-admission live validation (Phase 65): after prepare:phase-65-locomo was fixed to canonicalize upstream legacy QA evidence ids such as D:11:26 to D11:26, /private/tmp/LOCOMO-full/cases.json was regenerated with 10 cases, 1986 questions, 5882 turns, and no remaining D:<session>:<turn> evidence ids. The normalized same-scope 28-row multi_hop manifest now has clean live evidence: topK16/maxAdditions4 locomo-multihop-candidate-admission-top16-add4-live-evidence-normalized-current scored 6/28 (0.2142857143), average evidence recall 0.1833333333, 0 fully retrieved, noise 220, executionFailures: 0; topK32/maxAdditions8/rel0.8 locomo-multihop-candidate-admission-rel08-live-evidence-normalized-current scored 10/28 (0.3571428571), average evidence recall 0.4753401361, 8 fully retrieved, noise 281, executionFailures: 0. The live-delta locomo-multihop-top16-add4-vs-candidate-admission-rel08-live-delta-evidence-normalized-current/live-delta.json shows +4 net correct answers (5 improved, 1 regressed), +0.2920068027 evidence recall, +8 fully retrieved, +61 noise turns, 5 converted retrieval gains, and 9 unconverted retrieval gains. This is positive targeted-admission evidence plus residual answer/noise risk, not a defaultable LoCoMo setting.

• Latest LoCoMo rel0.8 multi_hop near-miss queue expansion (Phase 65): after regenerating /private/tmp/LOCOMO-full/cases.json, locomo-multihop-candidate-admission-rel08-near-miss-label-analysis-current/near-miss-label-analysis.json labels all 10 answerTokenF1NearMisses from locomo-multihop-candidate-admission-rel08-token-f1-delta-current: average candidate token-F1 0.2429793770, 7 balanced partial overlaps, 1 over-specified answer, 2 under-specified answers, 0 rationale-bearing/numeric/zero-overlap rows, with 2 full-recall, 5 partial-recall, and 3 zero-recall rows. Its six repair jobs split balanced-partial-overlap full/partial/zero rows, over-specified partial rows, and under-specified partial/zero rows. Loader proof locomo-multihop-candidate-admission-rel08-near-miss-label-file-loader-smoke-current consumed the 10-question artifact with executionFailures: 0; default retrieval found 0/10 fully retrieved, average evidence recall 0, and 44 noise turns. The provider-only timeout15 baseline locomo-multihop-near-miss-provider-baseline-10row-timeout15-current reproduced that 0 recall with provider embeddings, while the rel0.8 semantic-admission retry locomo-multihop-near-miss-rel08-retrieval-10row-timeout15-current completed with executionFailures: 0, average evidence recall 0.4142857143, 2/10 fully retrieved, and 107 noise turns. The paired budget delta locomo-multihop-near-miss-provider-vs-rel08-timeout15-retrieval-delta-current/budget-delta.json records +0.4142857143 recall, +2 fully retrieved, +63 noise turns, and 0.6575963719 recall per 100 added noise turns. This is positive targeted candidate-admission evidence for the near-miss queue, but it is retrieval-only and still requires answer/label validation before any default-profile promotion.

• Latest LoCoMo multi_hop full-recall answer-contract probe (Phase 65): the same normalized live-delta exported a three-row noisyFullRecallWrong queue. Normal-context and gold-evidence-only reanswers both scored 0/3 before the prompt repair, so removing retrieved noise alone did not recover the rows. The live prompt now includes a generic count/frequency contract for how-many-times answers (twice instead of bare 2); with that prompt, locomo-multihop-noisy-full-recall-reanswer-frequency-normal-current scored 1/3 and locomo-multihop-noisy-full-recall-reanswer-frequency-gold-only-current also scored 1/3, both at full evidence recall and executionFailures: 0. The delta locomo-multihop-noisy-full-recall-frequency-normal-vs-gold-only-delta-current/live-delta.json shows 0 net answer change from gold-only context, with 1 same-correct and 2 same-wrong. This is a narrow answer-contract win and points the remaining multi_hop full-recall misses toward answer-synthesis / label-compatibility work, not plain noise stripping.

• Latest LoCoMo multi_hop answer-synthesis focused replay (Phase 65): after adding the category-scoped multi_hop synthesis prompt guard, the same three-row noisyFullRecallWrong queue was rerun as locomo-multihop-noisy-full-recall-reanswer-synthesis-current with executionFailures: 0. It scored 1/3, matching the earlier frequency-contract replay; the subset-aware delta against the rel0.8 source report, locomo-multihop-noisy-full-recall-reanswer-synthesis-delta-current/live-delta.json, shows +1 answer, 0 regressions, no retrieval/noise delta, and two remaining token-F1 near misses. The near-miss label analysis locomo-multihop-synthesis-near-miss-label-analysis-current/near-miss-label-analysis.json classifies both remaining rows (conv-48:q83, conv-49:q29) as balanced partial-overlap answers with candidate full evidence recall and average token-F1 0.2660818713; the loader proof locomo-multihop-synthesis-near-miss-label-file-loader-smoke-current consumed that artifact as a 2-question retrieval-only selection with executionFailures: 0, while default retrieval found 0/2 fully retrieved, average evidence recall 0, and 9 noise turns. This validates that the current prompt stack preserves the narrow full-recall win and leaves a reusable answer-synthesis / label-compatibility queue, but it does not close the queue or justify default promotion.

• Latest LoCoMo multi_hop unconverted retrieval-gain probe (Phase 65): the same normalized live-delta exported a five-row topUnconvertedRetrievalGains queue, all partial-recall gains. Normal replay over the rel0.8 candidate context, locomo-multihop-top-unconverted-reanswer-normal-current, scored 1/5 with average evidence recall 0.5, 0 fully retrieved, 56 noise turns, and executionFailures: 0; locomo-multihop-top-unconverted-reanswer-gold-only-current scored 0/5 with identical retrieval metrics. Delta locomo-multihop-top-unconverted-normal-vs-gold-only-delta-current/live-delta.json shows -1 net from gold-only context, 0 improvements, 1 regression, 4 same-wrong, and all rows staying partial->partial. This routes the selected unconverted gains back to missing-evidence candidate admission and label-compatibility review, not gold-only noise stripping.

• Phase 65 manifest selected-scope guard note: targeted --question-id-file JSON now rejects mismatched top-level questionIds versus category-level questionIds, validates top-level/category selection-header shape, category header keys, overall container shape, equality, selected counts, and exact singleton reanswerJobs category/category-list consistency before preferred reanswer-job precedence even when the preferred queue is empty, and validates overall.selectedQuestionCount against repair/reanswer-job-only or preferred reanswer-job-only questionIds only when broader selection headers are absent or empty, including explicitly empty repair/reanswer or preferred queues, instead of silently unioning or accepting inconsistent selected scopes. This protects near-miss label and other repair artifacts from widening targeted smoke/reanswer scopes through inconsistent manifest headers or typoed category buckets.

• Phase 65 whole-report reanswer lineage note: eval:phase-65-reanswer-report now records inherited source questionIds as reanswerSelection.explicitQuestionIds when replaying an already-targeted source report without any additional id/file/bucket/category filter. This makes whole-report replay artifacts acceptable to shared report validation and live-delta analysis without changing LoCoMo scores, default status, or public-claim boundaries.

• Phase 65 CLI evidence guard note: shared strict scalar and boolean mode flags across smoke, reanswer, and measurement CLIs now reject duplicate source/output/run-id, budget selectors, canonical answer-policy/candidate-admission --per-bucket values, and repeated mode switches before report generation, reanswer question-id / bucket / category CLI lists reject empty or whitespace-padded values plus duplicate bucket/category values, multi-report --report lists reject empty, whitespace-padded, or duplicate normalized path values, paired baseline/candidate analyzers reject path-equivalent self-comparisons, targeted smoke/reanswer replay rejects explicit question ids that overlap selected manifest or question-id-file scopes instead of silently de-duplicating malformed replay scope, targeted manifest parsing rejects malformed repair/reanswer/category containers, non-object entries, whitespace-padded manifest question ids, malformed, empty, or whitespace-padded reanswerJobs source provenance, duplicate per-job reanswerJobs question ids, duplicate reanswerJobs category-list values, and malformed or unknown reanswerJobs selection metadata instead of silently skipping or accepting queued rows, reanswer replay rejects selected reanswerJobs without job-level source provenance, and filtered reanswer replay rejects non-object reanswerJobs entries plus malformed, duplicate, or unknown bucket/category selection metadata before bucket/category/source selection, reanswer source-lineage validation rejects malformed candidateReport / sourceReports containers, entries, provenance field types, missing runId-or-path identities, empty or whitespace-padded lineage values, duplicate selected sourceReports lineage, self-referential source reports, same-time or future-dated source reports, gold-evidence-only replay sources, missing reanswer source answer-context lineage, self-referential question-id-file manifests, source-report-as-question-id-file manifests, source retrieval-config conflicts, reanswer questionIds without explicit-id or manifest-file lineage, unused reanswer manifest paths without selected question ids or job filters, or selected reanswer scopes without a top-level questionIds header before matching, eval:phase-65-smoke rejects partial category-filter misses before report generation, shared smoke-report validation rejects malformed, empty, or whitespace-padded report runId values, malformed benchmark-source/external-root provenance, malformed upstream source/license/answer-metric value or coverage provenance, malformed profile lineage, malformed retrieval-config metadata, malformed replay-lineage or empty/duplicate replay-selection metadata, malformed replay-selection-to-cases lineage, malformed reanswer filter manifest lineage, malformed reanswer category-filter-to-cases lineage, malformed report provenance timestamp/writer/answer-context/policy metadata, malformed gold-evidence-only answer-context lineage, malformed or whitespace-padded reanswer-writer answer-context/source/selection lineage, malformed writer/replay-lineage ownership, malformed core cases / categories containers or entries, malformed or duplicate row retrieval arrays, malformed row scalar/metric fields, malformed or partial live-answer row answer fields, malformed category summary scalar/metric fields, malformed, whitespace-padded, or duplicate selection headers, malformed questionCount / caseCount / executionFailures headers, and questionCategories headers that overstate the actual cases[] categories; reanswer output generation also narrows inherited source questionCategories headers to the actual replayed rows, and targeted reanswer rejects empty or whitespace-padded explicit question-id scopes, blank, whitespace-padded, or source-matching output run ids, explicit-run output paths that would overwrite --source-report before the source report is read, reanswer-generated source reports, live-answer source reports with missing scored answer fields, source reports whose timestamp is not earlier than the replay timestamp, source reports where one queued question id matches multiple cases, source reports that are already gold-evidence-only replay artifacts, or blank generated answers that would otherwise be written as scored replay rows.

• Phase 65 neural measurement arm-list guard note: measure-locomo-neural.ts now rejects empty or whitespace-padded comma-separated --arms entries before retrieval measurement, so malformed neural/BM25 scope such as bm25, cannot silently shrink to a narrower evidence table. This protects evidence scope only; it does not change LoCoMo retrieval, answer scores, default settings, or public-claim boundaries.

• Phase 65 paired-analyzer lineage guard note: budget-delta, candidate-admission slice, and live-delta comparisons reject baseline/candidate reports with the same top-level runId even when their paths differ, and reject output paths that resolve to either input report path. This includes default output paths derived from --candidate-report plus --run-id, before source reports are read; all three paired analyzers also require --run-id to be a single path segment before deriving default output paths. This is derived-evidence lineage and output-directory hardening only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries.

• Phase 65 near-miss label output guard note: analyze:phase-65-locomo-near-miss-labels now rejects output paths that resolve to the input --live-delta before reading reports, rejects paths that resolve to the live-delta candidateReport.path before reading that candidate source report, and rejects paths that resolve to the candidate benchmark cases.json before loading benchmark cases. It also requires --run-id to be a single path segment before deriving the default output path from --live-delta. Near-miss label artifacts now record sourceReports[].questionCount as the selected near-miss row count emitted by the artifact, not the full candidate report question count, so source lineage matches top-level questionIds. This prevents label diagnostics from overwriting source evidence, escaping intended derived-evidence directories, or overstating selected source scope without changing LoCoMo retrieval, answer scores, default status, or public-claim boundaries.

• Phase 65 multi-report post-processor output guard note: summarize:phase-65-locomo-categories, analyze:phase-65-locomo-category-gaps, and analyze:phase-65-locomo-answer-policy-slice now reject empty or whitespace-padded --report values and output paths that resolve to any input --report before reading reports. All three also require --run-id to be a single path segment before deriving default output paths from the first --report. This keeps category matrices, gap diagnostics, and answer-policy manifests from malformed source lists, overwritten source evidence, or derived-output directory traversal without changing LoCoMo retrieval, answer scores, default status, or public-claim boundaries.

• Phase 65 retrieval-gap output/source guard note: analyze:phase-65-locomo-retrieval-gap now rejects output paths that resolve to either its input --report or its resolved cases file before reading inputs, rejects ambiguous --cases plus --benchmark-root source selectors, requires output --run-id values to be a single path segment before deriving default output paths, and persists source report / cases source / output path lineage plus generatedAt and diagnostic-only claimBoundary in the generated analysis. This keeps retrieval-gap diagnostics from overwriting source smoke reports or external-root cases, escaping intended derived-evidence directories, silently preferring one cases source over another, or relying on run-directory names to audit provenance, without changing LoCoMo retrieval, answer scores, default status, or public-claim boundaries.

• Phase 65 captioned-root source/output guard note: prepare:phase-65-locomo-captioned now rejects output roots that resolve to the input source root before reading cases, and rejects empty or whitespace-padded GOODMEMORY_LOCOMO_ROOT values before source-root fallback. This keeps captioned-root fixture prep from overwriting the normalized external LoCoMo root or reading malformed env-derived source roots without changing LoCoMo retrieval, answer scores, default status, or public-claim boundaries.

• Phase 65 external-root prep source intake/output guard note: prepare:phase-65-locomo now rejects ambiguous --source-file plus --source-url selectors, rejects --source-file values that resolve to the normalized output --output-root/cases.json before reading the source file, rejects non-OK --source-url fetch responses before JSON parsing, and rejects empty or whitespace-padded GOODMEMORY_LOCOMO_ROOT values before output-root resolution. This keeps external-root prep from silently preferring one source, keeps local raw LoCoMo source fixtures from being overwritten by generated normalized cases, prevents remote error pages from becoming source data, and surfaces malformed env-derived output roots without changing LoCoMo retrieval, answer scores, default status, or public-claim boundaries.

• Phase 65 shared row-identity guard note: shared smoke-report validation now rejects whitespace-padded cases[] row caseId and questionId values before selection-header matching or question-delta joins, so malformed row identities surface as canonicality errors instead of later caseIds or question mismatch errors.

• Phase 65 shared run-directory guard note: shared smoke-report validation now rejects whitespace-padded runDirectory provenance before category-gap or other downstream analyzers preserve report output-directory lineage.

• Phase 65 shared benchmark-source guard note: shared smoke-report validation now rejects whitespace-padded benchmarkSource and externalRoot provenance before path compatibility checks, so malformed benchmark-root lineage surfaces as canonicality errors instead of later source/root mismatch errors.

• Phase 65 shared reanswer-manifest guard note: shared smoke-report validation now rejects whitespace-padded reanswerSelection.questionIdFile provenance before replay-selection lineage and self/source manifest checks.

• Phase 65 shared row-category guard note: shared smoke-report validation now rejects whitespace-padded cases[] row category values before category enum checks, category-gap aggregation, or matrix assembly.

• Phase 65 shared timestamp guard note: shared smoke-report validation now rejects whitespace-padded top-level generatedAt and nested sourceReport.generatedAt values before ISO parsing, replay timestamp ordering, or derived analyzer lineage.

• Phase 65 shared exact-provenance guard note: shared smoke-report validation now rejects whitespace-padded generatedBy, license, upstreamSource, and upstreamAnswerMetricByCategory.* values before writer/source/license allow-list checks or answer-metric comparisons.

• Phase 65 shared upstream metric category-key guard note: shared smoke-report validation now rejects whitespace-padded upstreamAnswerMetricByCategory category keys before category allow-list checks or coverage comparisons against cases[] categories.

• Phase 65 shared answer-context-mode guard note: shared smoke-report validation now rejects whitespace-padded top-level answerContextMode and nested sourceReport.answerContextMode values before enum support checks, replay writer compatibility checks, or answer-context delta attribution.

• Phase 65 shared answer-context-mode shape guard note: shared smoke-report validation now rejects non-string or empty top-level answerContextMode and nested sourceReport.answerContextMode values before enum support checks, replay writer compatibility checks, or answer-context delta attribution.

• Phase 65 shared semantic embedding-source guard note: shared smoke-report validation now rejects whitespace-padded top-level semanticCandidateEmbeddingSource and nested sourceReport.retrievalConfig.semanticCandidateEmbeddingSource values before enum support checks, retrieval-config compatibility checks, or derived analyzer lineage.

• Phase 65 shared semantic embedding-source shape guard note: shared smoke-report validation now rejects non-string or empty semanticCandidateEmbeddingSource values before enum support checks, retrieval-config compatibility checks, or derived analyzer lineage.

• Phase 65 shared report identity/mode guard note: shared smoke-report validation now rejects whitespace-padded benchmark, phase, mode, ingestMode, and answerEvaluation values before benchmark/phase identity checks, supported mode checks, or mode/evaluation pairing checks.

• Phase 65 shared report identity/mode shape guard note: shared smoke-report validation now rejects non-string or empty benchmark, phase, mode, ingestMode, and answerEvaluation values before benchmark/phase identity checks, supported mode checks, or mode/evaluation pairing checks.

• Phase 65 shared optional selection-header non-empty guard note: shared smoke-report validation now rejects empty questionIds and questionCategories arrays before selection-header matching against cases[].

• Phase 65 shared caseIds header non-empty guard note: shared smoke-report validation now rejects empty caseIds arrays before caseCount or cases[] header matching.

• Phase 65 semantic-candidate/BM25 mode guard note: eval:phase-65-smoke rejects --semantic-candidates combined with --bm25 before memory construction or report generation, preserving BM25 as the embedding-free lexical leg and semantic candidate admission as embedding-backed evidence.

• Phase 65 shared BM25 embedding-source guard note: shared smoke-report validation now rejects reports that set bm25Ranking: true while claiming a semanticCandidateEmbeddingSource other than none.

• Phase 65 shared semantic-candidate/source consistency guard note: shared smoke-report validation now rejects semanticCandidates.enabled=true with semanticCandidateEmbeddingSource="none", including nested sourceReport.retrievalConfig lineage, before analyzer attribution or replay lineage checks.

• Phase 65 semantic-candidate inactive-budget guard note: eval:phase-65-smoke rejects semantic-candidate tuning flags unless --semantic-candidates is enabled, and shared smoke-report validation rejects non-null semantic-candidate tuning fields when semanticCandidates.enabled=false, including nested sourceReport.retrievalConfig lineage.

• Phase 65 answer-policy live-mode guard note: eval:phase-65-smoke rejects --allow-commonsense-resolution and --strict-no-evidence-abstention unless --live is enabled, and shared smoke-report validation rejects retrieval-only reports that carry those live-only answer-policy flags.

• Phase 65 answer-context live-mode guard note: eval:phase-65-smoke rejects --answer-from-recalled and --evidence-pack unless --live is enabled, and shared smoke-report validation rejects retrieval-only reports whose answerContextMode is not raw-turns.

• Phase 65 multi-hop answer-synthesis prompt guard note: LoCoMo live/reanswer generation now adds a category-scoped multi_hop system instruction to compose the final answer from every required evidence link and avoid stopping at a first matching clue or partial chain. This targets the current multi_hop answer-contract / label-compatibility queue as deterministic prompt hardening only; it does not change LoCoMo retrieval scores, accepted evidence, default status, or public-claim boundaries until a focused live slice proves a score change.

• Phase 65 reanswer category-filter source-row guard note: eval:phase-65-reanswer-report rejects category-filtered manifest replay when a selected source report row's actual QA category does not match the requested --reanswer-job-category. This prevents an answer-policy or noise-isolation manifest typo from replaying, for example, an adversarial row inside an open_domain repair queue. This is targeted replay evidence isolation only; it does not change LoCoMo retrieval scores, answer scores, default status, or public-claim boundaries.

• Phase 65 shared zero-failure live-answer completeness guard note: shared smoke-report validation now rejects live-answer reports with executionFailures: 0 when any row is missing scored answer fields, while still allowing non-zero-failure live reports to retain failed rows with null answer fields.

• Phase 65 shared answer-token-F1 state guard note: shared smoke-report validation now rejects failed live-answer and retrieval-only rows that carry a non-null answerTokenF1; only rows with both answerCorrect and generatedAnswer present may carry a numeric token-F1, while legacy live-answer reports may still omit the field or use null for in-memory backfill. This protects token-F1 near-miss routing evidence without changing LoCoMo scores, default status, or public-claim boundaries.

• Phase 65 shared row turn-id syntax guard note: shared smoke-report validation now rejects row evidenceTurnIds, retrievedTurnIds, missingEvidenceTurnIds, and noiseTurnIds entries that are not canonical LoCoMo dia_id values of the form D<session>:<turn>.

• Phase 65 shared profile lineage guard note: shared smoke-report validation now rejects profilesCompared values that differ from the canonical ["goodmemory-rules-only"] lineage written by Phase 65 LoCoMo reports.

• Phase 65 shared present category-summary metrics guard note: shared smoke-report validation now rejects any present categories[] summary whose aggregate metrics disagree with cases[], while still allowing diagnostics to omit category summaries entirely and full smoke shards that carry zero-count summaries for absent categories.

• Phase 65 shared explicit-only reanswer lineage guard note: shared smoke-report validation now rejects reanswer reports whose reanswerSelection.explicitQuestionIds do not match top-level questionIds when no manifest path or reanswer job filters are present, while still allowing explicit ids to be additive with manifest-backed jobs.

• Phase 65 shared category-summary guard note: shared smoke-report validation now rejects whitespace-padded categories[] summary category values before category enum checks, category-summary comparisons, budget-delta analysis, or matrix assembly.

• Phase 65 shared generated-answer guard note: shared smoke-report validation now rejects whitespace-padded live-answer row generatedAnswer values before category-gap aggregation, live-delta comparison, or replay-derived analyzer export.

• Latest LoCoMo full-root multi_hop blocker proof (Phase 65): locomo-multihop-semantic-provider-top16-add4-current covers all 282 multi-hop questions across 10 conversations with evidence-turn recall 0.326, 37/282 fully retrieved, noise 2204, executionFailures: 0, and questionCategories=["multi_hop"]; the live evidence-pack validation locomo-multihop-semantic-provider-top16-add4-live-pack-current scores 86/282 answer accuracy (0.305), executionFailures: 0. This upgrades the multi-hop blocker from held-out-shard evidence to measured full-root category evidence; LoCoMo remains not closed.

• Latest LoCoMo full-root temporal proof (Phase 65): locomo-temporal-semantic-provider-top16-add4-current covers all 321 temporal questions across 10 conversations with evidence-turn recall 0.678, 207/321 fully retrieved, noise 2571, executionFailures: 0, and questionCategories=["temporal"]; the resumed live evidence-pack validation locomo-temporal-semantic-provider-top16-add4-live-pack-current scores 178/321 answer accuracy (0.555), executionFailures: 0. Temporal is less retrieval-starved than open_domain or multi_hop, but remains answer-side weak, especially conv-42 8/40 and conv-44 11/24.

• Latest LoCoMo full-root adversarial/no-answer proof (Phase 65): locomo-adversarial-semantic-provider-top16-add4-current covers all 446 adversarial questions across 10 conversations with evidence-turn recall 0.592, 260/446 fully retrieved, noise 3421, executionFailures: 0, and questionCategories=["adversarial"]; live validation locomo-adversarial-semantic-provider-top16-add4-live-pack-current scores 240/446 answer accuracy (0.538), executionFailures: 0. This measures the no-answer policy blocker at full-root scope; it does not close adversarial behavior.

• Latest LoCoMo full-root single_hop proof (Phase 65): locomo-single-hop-semantic-provider-top16-add4-current covers all 841 single-hop questions across 10 conversations with evidence-turn recall 0.676, 558/841 fully retrieved, noise 6343, executionFailures: 0, and questionCategories=["single_hop"]; resumed live validation locomo-single-hop-semantic-provider-top16-add4-live-pack-current scores 457/841 answer accuracy (0.543), executionFailures: 0. This feeds the assembled full-root category evidence matrix, not LoCoMo performance.

Phase 40 Release Evidence

• Phase 40 is now closed as the v0.2 release proof and product eval slice.
• cross-consumer adoption smoke covers direct TypeScript, Express, Fastify, Python/FastAPI bridge, and installed-host package paths: reports/eval/adoption/phase-40/run-20260425163012-cross-consumer/report.json
• product eval rollup compares with-GoodMemory against a no-memory baseline: reports/eval/product/phase-40/run-20260425165544-product-eval/report.json
• Quality gate: reports/quality-gates/phase-40/run-20260425172323/phase-40-quality-gate.json

Historical Evidence Index

This index keeps one-line evidence pointers instead of old narrative.

• Phase 20: docs/archive/quality-gates/GoodMemory-Phase-20-Quality-Gate.md, reports/quality-gates/phase-20/run-20260420023503/phase-20-quality-gate.json.
• Phase 22: docs/archive/quality-gates/GoodMemory-Phase-22-Quality-Gate.md, reports/eval/live-memory/phase-22/run-1776650772564-assist/report.json.
• Phase 23: docs/archive/quality-gates/GoodMemory-Phase-23-Quality-Gate.md, reports/eval/live-memory/phase-23/run-1776658376536-promote/report.json.
• Phase 29: docs/archive/quality-gates/GoodMemory-Phase-29-Quality-Gate.md, reports/quality-gates/phase-29/run-20260421213000/phase-29-quality-gate.json, reports/quality-gates/phase-29/run-20260421214500/phase-29-rc-dry-run.json.
• Phase 30: docs/archive/quality-gates/GoodMemory-Phase-30-Quality-Gate.md, reports/quality-gates/phase-30/run-20260421153410/phase-30-quality-gate.json, reports/eval/live-memory/phase-30/run-phase30-live-current/report.json.
• Phase 31: docs/archive/quality-gates/GoodMemory-Phase-31-Quality-Gate.md, reports/quality-gates/phase-31/run-20260422041616/phase-31-quality-gate.json, reports/eval/live-memory/phase-31/run-phase31-live-current/report.json.
• Phase 32: docs/archive/quality-gates/GoodMemory-Phase-32-Quality-Gate.md, reports/quality-gates/phase-32/run-20260422085720/phase-32-quality-gate.json, reports/eval/fallback/phase-32/run-20260422173045/report.json, reports/eval/live-memory/phase-32/run-phase32-live-current/report.json.
• Phase 33: docs/archive/quality-gates/GoodMemory-Phase-33-Quality-Gate.md, reports/quality-gates/phase-33/run-20260422212752/phase-33-quality-gate.json.
• Phase 34: docs/archive/quality-gates/GoodMemory-Phase-34-Quality-Gate.md, reports/eval/fallback/phase-34/run-20260422213045/report.json, reports/eval/live-memory/phase-34/run-phase34-live-current/report.json, reports/quality-gates/phase-34/run-20260423102636/phase-34-quality-gate.json.
• Phase 35: docs/archive/quality-gates/GoodMemory-Phase-35-Quality-Gate.md, reports/eval/fallback/phase-35/run-20260423173045/report.json, reports/eval/live-memory/phase-35/run-phase35-live-current/report.json, reports/quality-gates/phase-35/run-20260423213045/phase-35-quality-gate.json.
• Phase 36: docs/archive/quality-gates/GoodMemory-Phase-36-Quality-Gate.md, reports/quality-gates/phase-36/run-20260423223045/phase-36-quality-gate.json.
• Phase 37: docs/archive/quality-gates/GoodMemory-Phase-37-Quality-Gate.md, reports/eval/fallback/phase-37/run-20260424101045/report.json, reports/eval/live-memory/phase-37/run-phase37-live-current/report.json, reports/eval/live-memory/phase-37/run-phase37-external-consumer/report.json, reports/quality-gates/phase-37/run-20260424104045/phase-37-quality-gate.json.
• Phase 37.1: docs/archive/quality-gates/GoodMemory-Phase-37.1-Quality-Gate.md, reports/eval/dogfood/phase-37-1/run-phase37-1-dogfood-current/report.json, reports/quality-gates/phase-37-1/run-20260424100757/phase-37-1-quality-gate.json.
• Phase 38: docs/archive/quality-gates/GoodMemory-Phase-38-Quality-Gate.md, reports/quality-gates/phase-38/run-20260425084045/phase-38-quality-gate.json.
• Phase 39: reports/quality-gates/phase-39/run-20260425041112/phase-39-quality-gate.json.
• Phase 41: reports/eval/fallback/phase-41/run-20260425213045/report.json, reports/eval/live-memory/phase-41/run-phase41-live-current/report.json, reports/quality-gates/phase-41/run-20260425223045/phase-41-quality-gate.json.
• Phase 42: reports/quality-gates/phase-42/run-20260426100000/phase-42-quality-gate.json.
• Phase 43: reports/eval/fallback/phase-43/run-20260426113000/report.json, reports/quality-gates/phase-43/run-20260426120000/phase-43-quality-gate.json.
• Phase 43.5: reports/eval/fallback/phase-43-5/run-20260426133000/report.json, reports/quality-gates/phase-43-5/run-20260426140000/phase-43-5-quality-gate.json.
• Phase 45: Phase 45 is now closed as the First Reference Product and Adoption Evidence slice; examples/reference-chat-product, bun run eval:phase-45, bun run gate:phase-45, reports/eval/adoption/phase-45/run-20260427104530-adoption-eval/report.json, reports/quality-gates/phase-45/run-20260427110000/phase-45-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-45-Quality-Gate.md.
• Phase 46: Phase 46 is now closed as the Memory Quality and Maintenance 2.0 slice; bun run eval:phase-46, qualityRepair, reports/eval/fallback/phase-46/run-20260427123000-quality-eval/report.json, reports/quality-gates/phase-46/run-20260428110000/phase-46-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-46-Quality-Gate.md.
• Phase 47: Phase 47 is now closed as the Provider-Backed Retrieval Rollout and Quality Promotion slice; bun run eval:phase-47, reports/eval/fallback/phase-47/run-20260428120000-provider-rollout-eval/report.json, reports/quality-gates/phase-47/run-20260428123000/phase-47-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-47-Quality-Gate.md.
• Phase 48: Phase 48 is now closed as the Dashboard, Cloud Sync, and Team Workspace Decision slice; bun run eval:phase-48, no-go decision, reports/eval/fallback/phase-48/run-20260428170000-dashboard-cloud-decision/report.json, reports/quality-gates/phase-48/run-20260428173000/phase-48-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-48-Quality-Gate.md.
• Phase 49: Phase 49 is now closed as the Full ImplicitMemBench GoodMemory Research Eval; baseline-upstream-chat, goodmemory-raw-experience, goodmemory-distilled-feedback, reports/eval/research/phase-49/baseline/run-phase49-smoke-current/report.json, reports/eval/research/phase-49/goodmemory/run-phase49-smoke-current/report.json, reports/eval/research/phase-49/comparison/run-phase49-smoke-current/report.json, reports/quality-gates/phase-49/run-20260428210000/phase-49-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-49-Quality-Gate.md.
• Phase 50: reports/eval/fallback/phase-50/run-20260428223000-installer-eval/report.json, reports/quality-gates/phase-50/run-20260428224500/phase-50-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-50-Quality-Gate.md.
• Phase 52: reports/eval/fallback/phase-52/run-phase52-fallback-current/report.json, reports/eval/live-memory/phase-52/run-phase52-live-current/report.json, reports/quality-gates/phase-52/run-20260502183000/phase-52-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-52-Quality-Gate.md.
• Phase 59: Phase 59 is the Generalized Raw Executor Cleanup slice; failed/preferred operations, reports/eval/fallback/phase-59/run-phase59-fallback-current/report.json, reports/eval/fallback/phase-59/run-phase59-fallback-current/raw-diagnostics.json, reports/quality-gates/phase-59/run-20260504193000/phase-59-quality-gate.json, docs/archive/quality-gates/GoodMemory-Phase-59-Quality-Gate.md, goodmemory-raw-experience at 58 / 60, raw 90 / 200, raw 88 / 200, raw at least 115 / 200, distilled 151 / 200.

Documentation Policy

Root current-status docs should stay compact. If a future change needs detailed phase provenance, add it to generated reports or an archive summary, not this file.