Phantom report verification

Type: agentic-system-analyses/types/agentic-system-verification.md

Verification

The current reports support a bounded code-grounded account with no material blocker. Two local limits remain below. I reviewed every declaration, annotation, evidence-status assessment, containment relation and reconciliation amendment against its scope and supporting passages. I independently checked the checkout's HEAD and clean status against the Source register, enumerated its top-level tracked tree, and traced consequential source producers and consumers. No target code, tests, providers or services were executed. The supplied structural check reports none; there is no structural finding to route.

Correction answers and reflection consumers

Both runtime correction answers and the epistemic correction answer are supported, rather than accepted merely because their authors marked them corrected. Memory and workflow supplied no answers. Direct inspection of SRC-1 src/evolution/reflection-subprocess.ts, src/evolution/versioning.ts and src/evolution/engine.ts confirms that the sentinel parser admits only ok/skip/escalate. Compaction is a per-file change action; admitted changed compactions return ok and take the live-config callback. I checked the runtime account, control table, forcing case, route fields, persistence and self-change discussion, and the epistemic ledger and bounded conclusion for dependent remnants. Their previous false compact-status distinction is gone. The retained parser, action and callback passages in RT-RTE-reflection-admission support the revised account.

I separately followed the consumer, not just the callback. SRC-1 src/evolution/engine.ts selects the fixed evolved files; src/agent/prompt-blocks/evolved.ts applies the content-line condition; src/agent/prompt-assembler.ts inserts those sections. Runtime now distinguishes automatic foreground delivery from reflection reading and subsequent promotion. This agrees with MEM-OBJ-evolved-files and MEM-OBJ-reflection-context. The earlier runtime consumer blocker is repaired. Memory's continuing attribution of those old defects to the supplied runtime is a local reporting inconsistency, not evidence against the corrected mechanism; its disposition is in Limits.

The independent branch trace also preserves the supported weaknesses: skip returns without post-state comparison/restoration, malformed sentinel parsing falls back to checked ok, and snapshots exclude top-level meta/staging. These are different conditions, not interchangeable failure cases. Versioning retains file-level summaries and drain/session metadata rather than generic per-bullet reasons. The theory-builder conditions in the runtime route remain separately qualified: wired recurrence is not evidence that content-directed criticism occurred. The dispositional self-change conclusion does not claim later change-dependent operation or demonstrated improvement. Neither correction warrants promoting those conclusions.

Runtime and effect boundaries

I checked the four model-component declarations, three runtime objects, eight routes, public claim, task-table absence and two authority paths. Component descriptions distinguish external inference and dense representations from retained text or symbolic control, with exact parameter versions and provider-side mutation unresolved. Session rows select opaque SDK history; they are not that history. Dynamic definitions and the chat supplement likewise have different substrates and consumers.

Independent reads of SRC-1 src/agent/runtime.ts, src/agent/permission-options.ts, src/agent/agent-sdk-loader.ts and src/agent/murph-context.ts, together with query-option searches in src/agent/chat-query.ts and src/agent/judge-query.ts, support the separation of foreground, judge and reflection controls. Requested SDK settings and hooks establish wrapper wiring, not dependency enforcement. Session serialization is instance-local. Stale resume recovery does not roll back prior tool effects. These qualifications are retained in RT-RTE-channel-work, RT-RTE-durable-chat and RT-RTE-judge-call.

SRC-1 src/mcp/dynamic-tools.ts, src/mcp/dynamic-handlers.ts, src/mcp/auth.ts and src/mcp/server.ts corroborate registry admission, persisted definition dispatch, external scope checks and shell execution outside the foreground Bash hook. The environment filter is not a filesystem/network sandbox. RT-RTE-dynamic-tools and RT-BAP-handler-execution preserve that distinction. Configuration-save searches in SRC-1 src/ui/api/phantom-config.ts support per-file persistence/read-back, not installation of a new live runtime config. The report correctly declines to infer next-message activation from a helper comment.

Retention and epistemic force

I checked every memory object and its consumer, all six memory routes, the memory claim and absence, and all epistemic declarations and ledger functions. Independent reads of SRC-1 src/memory/consolidation.ts, src/memory/semantic.ts and src/memory/context-builder.ts confirm the central chain: copied/truncated user text and prefix-derived task metadata; extractor-assigned confidence; same-subject similarity selection without an equal-predicate requirement; confidence-driven expiry; and later selective prompt delivery. The checking, disposition and retention stages remain distinct in EPI-RTE-similarity-check, EPI-RTE-validity-change and EPI-RTE-fact-retention. None supplies truth acceptance. Temporal recall can return expired facts; automatic rendering omits source IDs and procedure conditions. The extraction counterexamples establish failure of universal semantic preservation, not observed downstream misinterpretation.

Searches of SRC-1 src/memory/embeddings.ts, src/memory/procedural.ts, src/evolution/queue.ts and src/evolution/cadence.ts, plus direct gate and batch-processor reads, corroborate index/payload separation, singular procedure selection, queue replacement and distinct clean-skip/transient/invariant-failure dispositions. They do not resolve deployed vector provenance, Qdrant counter semantics or actual model curation. Source claims in SRC-1 docs/memory.md and docs/self-evolution.md remain attributed doctrine, not verified universal learning or benefit. MEM-CLM-universal-memory and EPI-CLM-session-learning appropriately retain the mismatches.

File notes have separate paths: direct reads of SRC-1 src/agent/prompt-assembler.ts and src/agent/prompt-blocks/working-memory.ts confirm automatic line-clipped working memory and deliberate exclusion of agent notes from injection. Operator memory-file and vector-deletion branches in SRC-1 src/memory-files/storage.ts and src/ui/api/memory.ts establish mutation capability, not per-content human approval or revocation of already consumed copies. The afforded status of MEM-RTE-foreground-notes is appropriately weaker than evidence of actual agent edits.

For chat, direct reads of SRC-1 src/chat/writer.ts, src/chat/continuity-context.ts, src/chat/transcript-search.ts and src/chat/sweep.ts support distinct committed messages, translated events, derived timelines and selected supplement. Checkpoint metadata is not the SDK's summary; timeline page artifacts can survive event expiry. Bound lexical transcript reload is a separate consumer route, not complete restoration. MEM-RTE-transcript-recovery and RT-RTE-chat-context maintain the correct distinction between delivery, model use and successful recovery.

Workflow, identities and conflicts

I independently traced the validation, execution and delivery decisions in SRC-1 src/scheduler/create-validation.ts, src/scheduler/executor.ts, src/scheduler/delivery.ts and the timer portion of src/scheduler/service.ts, supplemented by tool/service/recovery searches. WF-RTE-job-creation admits stored instructions and schedule metadata, not a verified future answer. The workflow correctly separates creation acknowledgment, error-prefix run classification and transport outcome. A busy empty return leaves the row unchanged but can receive a callback completion label. Delivery failure does not veto completion or trigger a delivery-only retry in the inspected executor; successful delete-after-run can remove the job despite failed delivery. No observed success or exactly-once effect guarantee follows.

All four Part of: relations are substantively valid: the three memory chat objects are cross-kind retained state parts of durable chat, and EPI-RTE-review-request is a direct-work subroute. Review handler searches in SRC-1 src/mcp/tools-swe.ts support advisory runtime feedback and the stated disconnected status placeholders, not enforced merge acceptance.

The four amendments in reconciliation correctly identify duplicate fact, episode and procedure payloads and the common extraction route without replacing their assessments. Dense indexes remain distinct from text payloads. Delivery and deletion routes overlap without being identical; the broader containers remain valid, so split supersession is unnecessary. Public claim records have different source assertions, and task execution versus procedure learning have different absence targets. Reconciliation accurately distinguishes repaired mechanism disagreements from memory's residual attribution conflict. That conflict includes both positions, record citations, evidence and the conclusion prevented; no reconciliation blocker is needed.

Omission questions and stopping decision

The frozen tree, startup callers and producer/consumer dependencies guided additional searches beyond listed anchors. I tested whether alternate ingress shared channel learning, whether another shipped task/procedure producer defeated the bounded absences, whether timeline persistence supplied full checkpoints, and whether a separate compact status really bypassed refresh. Non-test src/ searches for consolidation/evolution callers, procedure writes/outcome updates and task-table operations corroborate caller-specific learning and the bounded absences in MEM-ABS-procedure-learning and RT-ABS-task-executor. The scheduler's separate table does not refute the latter. Session-log reference searches leave its population unresolved, as already stated in memory. Consumer traces settle the checkpoint and compaction questions without inventing absent SDK behavior.

I also searched shipped skill instructions for alternative evidence checks and approval policies, and read SRC-1 skills-builtin/ritual/SKILL.md completely. Its instruction-level memory check and approval requirement justify retaining the prior inventory limit below. Further optional expansion stopped because each selected challenge has a supported disposition, the reports expressly retain partial epistemic coverage, and no identified material contradiction remains undisposed. Available uninspected skill bodies do not establish absence, but their existence alone does not require an exhaustive inventory. External SDK behavior, deployed state and missing execution/comparison evidence remain beside the affected conclusions rather than being recast as defects.

Blockers

none

Limits

• The memory annotation on RT-RTE-reflection-admission and Integration issues, items 1–2, still describe compact-without-refresh and overbroad automatic file consumption as defects in the supplied runtime. The current runtime record explicitly corrects both, agreeing with MEM-OBJ-evolved-files and MEM-OBJ-reflection-context. Independent SRC-1 src/evolution/reflection-subprocess.ts, src/evolution/engine.ts and src/agent/prompt-blocks/evolved.ts reads support that agreement; their load-bearing passages are retained in the cited records. Reconciliation explicitly identifies this as a stale attribution, not an unresolved source-mechanism alternative. Withhold the inference that those two runtime repairs remain outstanding. This is publishable as a local integration-description inconsistency because memory's own mechanism findings are correct, the current runtime and epistemic accounts are corrected, and no emitted system mechanism or comparison finding depends on the stale attribution.
• The epistemic coverage boundary and MEM-RTE-memory-tools do not inventory every shipped skill-guided checking path. SRC-1 skills-builtin/ritual/SKILL.md instructs the model to check temporal-pattern candidates against memory, discard unsupported candidates and obtain user approval before using WF-RTE-job-creation. This is doctrine/design using recorded lookup and scheduling capabilities, not observed checking or software-enforced approval. Central heuristic/reflection findings and the selective workflow remain supported. Withhold exhaustive comparisons of epistemic evaluators and schedule-admission policies; generic tool admission without compulsory approval does not describe every instruction-guided path.

Discard any candidate that the session pattern suggests but memory does not support. Discard any where the cadence is off (the user did it three Mondays in a row, then stopped two weeks ago). --- skills-builtin/ritual/SKILL.md

Never create a schedule without explicit user approval. --- skills-builtin/ritual/SKILL.md