Smriti MCP report verification

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

Verification

The pinned runtime, memory, epistemic, workflow and reconciliation members support a bounded source-level account. I independently read the six shipped Python implementation files, all four test files, package entry-point configuration, README, quick-start and maintenance guide, and the test workflow in SRC-1. The checkout HEAD equalled the reviewed revision and its working tree was clean. The tracked tree supplied the search basis for alternate entry points and shipped callers. These reads establish implementation and declared intent, not observed execution. No target code, tests, examples, host or service was executed. The supplied correction-answer files are empty and report-check reports none; there is no structural finding to route.

Runtime and memory records

I traced RT-CMP-memory-store, all four runtime routes and RT-CLM-file-controls through SRC-1, src/smriti_mcp/cli.py, src/smriti_mcp/server.py, src/smriti_mcp/store.py, src/smriti_mcp/frontmatter.py and src/smriti_mcp/fix_frontmatter.py. The implementation supports the executor identity, caller-owned next step, explicit versus automatic write branches, separate read interfaces and invoked maintenance. In particular:

  • RT-RTE-memory-write correctly limits automatic append to the best candidate's score/title predicate. Explicit modes bypass that decision; lower-level writes bypass trace creation. Remember update does not apply assembled metadata. Shape/path admission is not semantic approval.
  • RT-RTE-context-recall correctly separates response selection from host context ownership. Graph expansion precedes the top limit and budget; the budget admits the first item even if oversized. Explicit status controls and other read interfaces prevent interpreting default recall exclusion as universal withdrawal.
  • RT-RTE-trace-consolidation correctly separates raw-event grouping, external prose authorship and note admission. Create/update apply prepared trace-reference metadata; append does not. Trace references are not resolved as supporting evidence. Note and event effects are sequential, without encompassing rollback.
  • RT-RTE-store-maintenance correctly distinguishes health reports from invoked edits and fresh retrieval indexes from saved exports. The repair utility excludes hidden components of the absolute path, including a hidden root or ancestor. Dry-run checks fewer fields than real repair. Direct repair/index writes do not inherit ordinary note replacement.

The file-control record's counterpaths are consequential and preserved: note-ID resolution checks containment, trace agent-path construction does not use that resolver, locks are instance-local, and note replacement is not crash durability or a multi-effect transaction. No broader sandbox or uniform durability conclusion is emitted.

All five memory object records have supported source-native identities and consumers: MEM-OBJ-memory-body, MEM-OBJ-memory-meta, MEM-OBJ-trace-events, MEM-OBJ-markdown-index and MEM-OBJ-machine-index. I checked their production, serialization and reload paths in SRC-1, src/smriti_mcp/store.py and src/smriti_mcp/frontmatter.py. Body and controls remain distinct; persisted YAML is an export rather than an established reload route. Markdown index loading has a real delivery path but invocation-controlled freshness. Raw NDJSON remains outside ordinary note scanning. These are not interchangeable forms of semantic memory consumption.

MEM-RTE-access-reinforcement is supported by the timestamp/count/salience writes and their later affinity consumers. Its annotation as part of recall identifies the embedded write-back, while its explicit direct-call trigger remains visible. No changed retrieval outcome or improved capacity is inferred. Memory annotations accurately retain snippet/provenance omissions, metadata-only associations versus wikilink graph edges, optional supersession reasons and nonuniform withdrawal.

RT-OBJ-server-instructions and RT-BAP-tool-guidance match shipped strings and registration in SRC-1, src/smriti_mcp/server.py. Their advisory host channel is distinct from schema enforcement and later retrieved content; delivery does not establish compliance.

Epistemic, workflow and identity checks

I checked each epistemic declaration and its ledger use against SRC-1, src/smriti_mcp/server.py, src/smriti_mcp/store.py, src/smriti_mcp/frontmatter.py and src/smriti_mcp/fix_frontmatter.py. EPI-RTE-shape-check, EPI-RTE-write-admission and EPI-RTE-content-retention preserve checking, operational admission and retention as different functions. Their implemented status does not claim evidence-consuming acceptance of note truth. EPI-RTE-recall-selection grants ranking/delivery force, not warrant. EPI-RTE-access-reinforcement is the same numerical feedback route as the memory declaration, not an additional learning mechanism.

EPI-RTE-trace-review correctly treats recommendations as advisory reshaping of raw events. EPI-RTE-maintenance-check licenses only code-relative diagnostics. EPI-RTE-maintenance-rewrite does not infer semantic preservation from truncation or factual warrant from title/alias linking. Its constructed truncation example follows the 160-character prefix rule without execution; direct creation is explicitly a counterpath to the description claim, not an asserted maintenance invocation. EPI-RTE-lifecycle-disposition correctly separates operational withdrawal from refutation or acceptance of replacement.

The three claim records are accurately attributed and compared: EPI-CLM-consolidation-provenance is branch-qualified, EPI-CLM-summary-omission is contradicted by creation's fallback, and EPI-CLM-recall-bundle does not become a strict size, invariant-output or relevance guarantee. The load-bearing passages in the submitted records agree with the independently read implementation and doctrine. Wired implementation and uninspected operation statuses are appropriate throughout. No report declares an evidenced-absence record; scoped findings about missing internal acceptance or model execution are supported by the inspected dispatch and implementation, not a search miss or missing run alone.

The workflow account follows a shipped handoff rather than joining unrelated APIs: tool guidance explicitly connects raw traces, review and supplied consolidation prose; independent later get/recall completes the artifact's delivery chain. SRC-1, tests/test_smriti_store.py and tests/test_smriti_mcp_integration.py support test intent and shipped callers, not successful execution. Failure after note persistence, retry hazards and caller-owned recovery follow from the inspected ordering. No internal agent delegation, automatic continuation or completed host task is attributed to Smriti.

I checked every Part of: relation as functional containment rather than identity. The shape/admission/lifecycle, selection/feedback, trace-review and diagnostic/rewrite parts preserve their valid runtime containers. The cross-route retention function is expressly not wholly contained in one parent. The reconciliation correctly supersedes EPI-OBJ-memory-body, EPI-OBJ-memory-meta, EPI-OBJ-trace-event and the epistemic reinforcement route by their memory counterparts. Referents, evidence and affected findings support all four amendments; no values are silently replaced. All memory integration issues receive dispositions. Doctrine/implementation discrepancies are preserved rather than mislabelled as analyst disagreements. No unresolved cross-report conflict or missing required part was identified.

Consequential omission questions and stopping decision

The frozen tracked tree and producer/consumer dependencies motivated three additional challenges to the central account:

  1. Could a shipped driver, prompt or evaluator own semantic synthesis, automatic recall supply or acceptance outside the listed wrappers? The complete implementation, README library examples, quick-start host configurations and all tests show caller-led operations; no additional shipped semantic controller or end-to-end model evaluator was identified. Host implementations remain excluded as in the boundary. The implemented-memory account holds; actual host scheduling and semantic reliance cannot be compared.
  2. Could alternate reload, graph or maintenance paths defeat the account of requested selection and retained provenance? I traced filesystem admission through parsing/scanning, transient and saved indexes, alias/wikilink consumers, direct access marking and repair's independent module entry point. These paths are covered by the existing objects, routes and annotations. Neither a saved YAML reload consumer nor metadata-related graph traversal is established by the shipped implementation. Full-note retrieval remains distinct from compact recall.
  3. Could lower-level writes and composite failure paths invalidate broad durability, audit or semantic-admission claims? I traced direct library calls, remember's explicit branches, consolidation append, supersession ordering and trace-path construction. The reports already qualify each consequential counterpath. They do not promise universal auditing, verified provenance, transactional recovery or source-truth acceptance.

Further optional omission expansion stopped because these questions have supported dispositions, the material shipped implementation and caller paths have been traced, and no identified challenge remains that could change the retained conclusions without changing the frozen boundary. This is not an exhaustive security, dependency or retrieval-quality audit. Missing execution evidence, uncertain generic authorship and unavailable external consumption are already scoped uncertainties in the reports, not additional defects requiring a publication limit. The analysis supports implemented retention, selection and numerical feedback independently of unestablished benefit, reflection, autonomy, self-improvement or theory-builder iteration.

Blockers

none

Limits

none