Eva-brain report verification

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

Verification

The reports support a bounded implementation account of a maintained Markdown intermediary, with structural admission and later read-back, not demonstrated semantic acceptance or improved answers. I read all supplied members and types, the record contract, the empty correction-answer files and the report check. The report check reports none; there is no structural failure to route. I independently inspected source rather than treating the analysts' validation or inspection statements as verification. The frozen checkout HEAD matches the reviewed boundary. No target program, test, example, installer or service was executed.

Runtime and admission

I traced the command registry, source copying and eligibility, runtime/profile lookup, worktree creation, all three ingest adapters, protected-path verification, commit/log ordering, lint comparison, automatic merge, held decisions, worker progression and cleanup in SRC-1, apps/desktop/src-tauri/src/main.rs and apps/desktop/src-tauri/src/ingest.rs. These support RT-RTE-source-ingest and RT-OBJ-ingest-worktree. The patch is filesystem/Git state, not the agent's summary. Both uncommitted protected paths and committed base-to-HEAD differences are inspected before admission. The no-uncommitted-change error, deletion comparison with rename detection disabled, and string-membership comparison with baseline issues agree with the report. Human acceptance does not rerun a semantic test. The gate's invariant is properly limited to this admission path and its named paths, not arbitrary physical effects of external tools.

I checked producer and consumer together for RT-CLM-structural-gate, EPI-OBJ-lint-issues and EPI-RTE-structural-check: SRC-1, packages/eva-mcp/lint-cli.mjs, packages/eva-mcp/vault-io.mjs, packages/wiki-lib/src/parse.ts, packages/wiki-lib/src/vault.ts, packages/wiki-lib/src/graph.ts, packages/wiki-lib/src/lint.ts, and Rust's lint wrapper and gate. The rules test the parsed representation. The source-prefix and disconnected-mutual-link deductions are supported without executing their hypothetical inputs. Neither source existence nor semantic entailment is checked by the summary predicate. Existing issue strings and a review override prevent interpreting admission as a comprehensive structural-cleanliness guarantee, much less a truth oracle.

I separately traced bootstrap, creation/import and settings writes for RT-RTE-brain-settings, including preservation of existing operating files, profile-section replacement and clean-status requirements. I checked setup, presence/version branches, downloaded installers and derived-model configuration for RT-RTE-runtime-setup. These are distinct admission mechanisms, not exceptions silently folded into the ingest gate. The reports correctly withhold immutable external-distribution identity and transactional rollback claims. Adapter arguments, mutable model selectors and the local Modelfile support the separately bounded parameter/fixity findings of RT-CMP-codex, RT-CMP-claude and RT-CMP-eva-qwen. The inspected code requests inference, not training; provider internals remain uninspected.

Read-back, alternate consumers and saved products

For RT-RTE-vault-query, I traced supported Option<Vec<String>> input normalization through each adapter and compared it with actual tool inputs and returned-answer checks. Nonempty working sets change the prompt; they do not filter the MCP loader or validate returned citations. Empty scope explicitly permits the whole brain. The reports therefore do not mistake a requested restriction for enforced exclusion or claim an observed bypass. Read-oriented CLI permissions remain external-runtime contracts, and the documented Claude memory discovery and OpenCode config merging are retained rather than erased by isolation flags.

I read the complete MCP server/loader and parser/resolver/graph implementations for MEM-RTE-mcp-navigation, EPI-RTE-wiki-navigation and MEM-OBJ-page-metadata. All four registered tools are read operations. Search ranks lexical hits and limits matches/excerpts; full page reads have a different output boundary. Graph traversal concerns resolved links, not evidential support. Raw, dot paths and root infrastructure exclusions are loader-local, not a restriction on every filesystem tool. The reports preserve this distinction.

The retained-object findings of MEM-OBJ-raw, MEM-OBJ-knowledge-pages, MEM-OBJ-summaries, MEM-OBJ-analyses and MEM-OBJ-log agree with the source-to-proposal-to-merge/read chain. I checked the source contract, templates, Rust copy/log/formatter/bootstrap code, and actual desktop consumers in SRC-1, schema/EVA.md, schema/AGENTS.md, schema/CLAUDE.md, schema/eva.json, templates/vault/index.md, templates/vault/log.md, apps/desktop/src-tauri/src/ingest.rs and apps/desktop/src/main.ts. Unknown imported provenance does not erase the later known write mechanisms. Log substring eligibility, including rejection and incidental-name collision, is an actual later deterministic consumer, not merely a trace-retention claim.

I traced both query-save and profile-result-save UI callers into RT-RTE-analysis-save and its EPI-RTE-analysis-format part. Safe-reference filtering affects metadata/evidence while answer prose survives; the report's concrete formatting deductions match the code. All saves use a pending decision, not the clean-ingest auto-merge predicate. The supplied answer is not authenticated as the result of a preceding query. This supports the distinction between human decisions in shipped UI and unresolved identity of arbitrary callers. The profile caller preserves result content/citations but supplies a tool/profile label as its saved question; the analysis object does not promise retention of every customization or a full reasoning trace.

For MEM-RTE-desktop-reload, I followed recursive Markdown collection, separate log loading, graph/lint reconstruction and merge/rejection event handlers. This is a shipped later consumer, not a hypothetical API use. MEM-BAP-wiki-evidence and RT-BAP-vault-contract correctly distinguish subject evidence interpreted by models from operating guidance and parsed dispatch settings. Neither delivery path establishes compliance or benefit.

Epistemic and workflow judgments

I checked the whole epistemic inventory and every ledger function against its declaring records and the relevant source consumers. EPI-OBJ-raw and EPI-OBJ-wiki describe evidence/corpus objects, not accepted propositions. EPI-OBJ-query-answer, EPI-OBJ-health-report and EPI-OBJ-profile-result separate transient products and their different uses. I read all seven profile-tool instructions, shared customization/scope prompt, validators and all query/Health/profile dispatch branches for RT-RTE-advisory-tools. Health supplies advice without an automatic edit consumer; generated exam answers are not independent reference answers. Content generation remains semantically indeterminate without actual source/output pairs. Deterministic structural derivation and formatting have narrower, supported classifications.

The product/contract passages support the attributed EPI-CLM-durable-knowledge, while the comparison with implemented routes does not upgrade that label into a truth guarantee. The research guidance explicitly requests competing-explanation revision. The bounded theory-builder discussion preserves that positive request, localized editable content and persistence without inferring completed content-directed criticism, iteration or successful learning. Configuration changes likewise do not establish trace-fed self-revision. The absence of supplied run or causal evidence is consistently separated from inspectable implemented capacity.

The workflow account follows a connected ingest path. I independently checked its handoff, decision owner, delivery events, error cleanup, post-merge lint ordering and removal of held state before merge. The recovery qualifications are supported: a reported error need not imply rollback, cleanup discards its own errors, and process-held review/queue data is not durable reconstruction. The worker's ordinary hold-return path is supported; the distinct re-enqueue caveat below prevents upgrading that account to a system-wide scheduling exclusion.

Relations, reconciliation and omission coverage

I checked every declaration's evidence strength, identity and annotations, both explicit Part of: relations, and the two supersessions in reconciliation. Structural checking is a function within ingest, though also reused elsewhere; formatting is within save preparation, not its admission decision. The raw-object and MCP-route supersessions identify the same referents without selecting stronger statuses. The wiki corpus can remain a valid container alongside memory's prose/metadata parts; transient answers and temporary proposal worktrees are not duplicate durable pages. No required operative part with different warrant or force is hidden by those container findings. Reconciliation preserves the reports' convergence and uncertainty. No unresolved cross-report disagreement, missing conflict evidence or unaddressed correction answer was found.

Omission questions were selected from the frozen tree and the producer/admission/consumer chain: whether another writer bypasses the ingest characterization; whether actual tools enforce working-set exclusion; whether saved products lose evidence before later reuse; whether static instructions or shipped callers introduce another maintenance loop; and whether review really establishes a universal scheduling barrier. Inspection covered the complete command registry, bootstrap/settings/import, all model adapter families, all MCP registrations, canonical standard and entry prompts, frontend save/reload/review code, and the dev auto-enqueue caller. I also read SRC-1, apps/desktop/scripts/bundle-tools.mjs and apps/desktop/vite.config.ts: packaging and dev-report transport do not supply semantic acceptance or an observed successful run. Added coverage is implementation or doctrine/design within SRC-1, not a new source or execution layer.

The broad conclusions survive these checks: maintained files can be produced, structurally admitted and later consumed; there is no established exercised semantic acceptance or causal improvement in the supplied evidence. Optional omission expansion stops because the selected material alternatives have supported dispositions or the local scheduling limit below. More rendering, asset, dependency or external-runtime inspection is not reasonably required to sustain that bounded account. This is not exhaustive security, UI, reliability or provider-context verification.

Blockers

none

Limits

• The pause in RT-RTE-source-ingest and the workflow review handoff describes the worker returning after a hold, not a universal prohibition on further enqueue activity. SRC-1, apps/desktop/src-tauri/src/ingest.rs sets worker_running false on that return, while ingest_enqueue can start a worker without checking held entries. The supported sources: [] scan input is also used by the shipped dev caller in apps/desktop/src/main.ts; after a hold, other eligible raw files can produce nonempty queued work. This is a source-derived alternative, not an observed concurrent run or proof that the ordinary production UI permits a particular click sequence during its review modal. Withhold a system-wide “nothing else can run until review” scheduling guarantee. The ordinary worker hold/decision sequence, protected-path checks and per-proposal admission conclusions remain supported; this local alternate-call omission does not change their statuses.

if !st.worker_running { st.worker_running = true; drop(st); let handle = app.clone(); std::thread::spawn(move || worker(handle)); } --- apps/desktop/src-tauri/src/ingest.rs