MCMA-OpenMemory report verification

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

Verification

The reports support a bounded implementation account, with two local limits below. I read every declaration, annotation, epistemic ledger row and reconciliation disposition. The supplied structural report says none; all four correction-answer files are empty. There are no correction arguments to accept by presumption. I independently inspected source rather than treating the analysts' checks as verification. Git HEAD equals the revision in boundary.md; the tracked top-level tree agrees with its coverage table. All source inspection below is SRC-1 implementation at that revision, except the identified documentation. No target program, provider, test or example was executed.

Runtime and admission

I traced AskService from canonical recall through exact assessment, semantic discovery/selection, generation and capture, then followed its CLI and web callers. RT-RTE-ask-answer correctly separates generation from embedding calls, captures unverified/0.5 by default, and preserves an existing exact record rather than replacing it after generation. The strict assessment rejects disputed/retracted and never-direct records before evaluating confidence, validation and freshness. Immutable and always-policy branches have the qualifications described by EPI-RTE-knowledge-assessment. SRC-1: packages/core/src/Ask/AskService.php, packages/core/src/Knowledge/KnowledgeRecord.php, packages/core/src/Knowledge/KnowledgeService.php, packages/core/src/Semantic/SemanticIndexService.php.

The public answerFromTopK method trusts supplied reusable metadata; the report explicitly bounds the ordinary AskService route to topK-produced input. Inspection of the separate semantic answer method and the CLI caller did not reveal a contrary ordinary metadata-admission policy. I did not turn public array acceptance into a claim of an unauthenticated web bypass. The broad-request return suppression is a local omission, detailed below.

The consequential canonical countercase is supported and reachable, not just a missing parameter in an unused API. Web construction enables BroadMemoryRecallBuilder by default; supported broad-recall question syntax reaches canonicalRecall. Actor-readable matching confirmed canonical content maps to verified/0.95 with stale=false, independently of strict knowledge assessment and currentRequired. Knowledge-only retraction therefore does not establish canonical withdrawal. This supports the distinction retained by RT-RTE-ask-answer, MEM-OBJ-explicit-memory and EPI-RTE-knowledge-validation. SRC-1: packages/core/src/Web/WebApplication.php, packages/core/src/Context/BroadMemoryRecallBuilder.php.

I checked explicit capture's organizer input, output parser, structural validator, fallback and canonical-before-mirror ordering. RT-RTE-explicit-capture and RT-OBJ-organizer-instructions correctly distinguish a preservation request from a semantic check. Confirmed canonical and verified mirrored labels do not establish post-transformation human review. Mutation target resolution, ambiguity rejection, tombstones and separately caught mirror/index failures support RT-RTE-memory-mutation. Approval classifies before storing the new interaction validation; approveKnowledge can validate existing knowledge without replacing its answer. The reports preserve that consequential distinction in RT-RTE-interaction-approval. SRC-1: packages/core/src/Memory/ExplicitMemoryService.php, packages/core/src/Memory/MemoryMutationService.php, packages/core/src/Interaction/InteractionArchiveService.php.

Retained objects, selection and authority

The memory declarations distinguish the manifest/index, knowledge answer and eligibility metadata, canonical source/organization metadata, interaction transcript, conversation discovery index, thematic derivative, vectors, traces, inspector catalog and vault. Their source anchors support their storage, lineage and actual consumers. I traced Library initialization, updates, current-hash lookup and manifest replacement; CLI authoring/read dispatch; StorageMigrator copying before manifest publication; knowledge capture/validation/replacement; and semantic indexing, refresh, removal and later selection. These support MEM-RTE-library-authoring, MEM-RTE-knowledge-editing, MEM-RTE-semantic-maintenance and MEM-BAP-knowledge-reuse, without implying cross-object transactions or measured benefit. SRC-1: packages/core/src/Library.php, packages/core/src/Cli/CliApplication.php, packages/core/src/Storage/StorageMigrator.php, packages/core/src/Agent/Librarian.php, packages/core/src/Knowledge/KnowledgeService.php, packages/core/src/Semantic/SemanticIndexService.php.

Conversation selection rereads actor-visible archived answers after owner-index discovery; multi-memory selection rereads and reassesses records; broad recall has its own less restrictive policies. Byte accounting, field clipping and durable originals support request-driven context reconstruction, not a live-window compaction or isolated-worker mechanism. I followed all three shipped generation serializers through their final reference payloads. Empty collections are omitted, uncertainty metadata is delivered, and system instructions request untrusted-reference treatment. RT-RTE-context-supply and RT-BAP-memory-reference correctly withhold compliance and complete-prompt/token guarantees. SRC-1: the three builder files under packages/core/src/Context/, packages/connectors/local/src/OllamaGenerationProvider.php, packages/connectors/local/src/LlamaCppGenerationProvider.php, packages/connectors/aws/src/BedrockConverseGenerationProvider.php.

All six runtime model-component records describe configurable inference endpoints, not archive-resident weights or exact weight pins. Their generation/embedding methods support the limited finding that inspected requests do not update weights. Opaque provider internals remain unresolved. Inspection also confirms the separate permission and vault consumers: actor-aware checks have denial force, raw APIs require a trusted host, and secret callbacks are capabilities rather than an established model-memory route. This supports RT-CLM-permission-scope, RT-BAP-policy-decision, RT-RTE-permission-change and MEM-OBJ-vault. SRC-1: the six connector files named by the component records, packages/core/src/Library.php, packages/core/src/Security/PermissionEngine.php.

I checked archive/index production and later reads, thematic topic selection, clipping and supersession, and trace/catalog production and inspection. The qualification-loss example in EPI-RTE-thematic-summary follows the inspected excerpt function; it is a source deduction, not an observed run. Canonical recall excludes thematic derivatives despite confirmed maturity. The catalog's hash-only skip can preserve time-stale eligibility metadata, as MEM-RTE-inspector-snapshot states. These mechanisms support derived organization and diagnostics, not automatic factual acceptance or diagnostic-driven self-revision. SRC-1: packages/core/src/Interaction/InteractionArchiveService.php, packages/core/src/Interaction/InteractionCatalogService.php, packages/core/src/Interaction/ThematicSummaryService.php, packages/core/src/Context/ContextTraceService.php, packages/core/src/Context/BroadMemoryRecallBuilder.php.

Epistemic and workflow dispositions

The epistemic inventory and ledger preserve acquisition versus production, checking versus disposition, retention versus post-acceptance integration, and operational labels versus factual warrant. The indeterminate model-transformation classifications are appropriate without concrete input/output evidence. Thematic extraction is source-supported reshaping with a fidelity limit, not independently warranted derivation. EPI-CLM-knowledge-policy accurately attributes docs/KNOWLEDGE-REUSE.md as doctrine, including its metadata-not-proof qualification and the narrower exact-miss diagram. EPI-RTE-answer-replacement and EPI-RTE-catalog-classification retain distinct proposers, checks and consequences. No observed accepted ampliative result, improved capacity or exercised self-improvement is inferred from retention alone. The validation-route delegation wording has the local limit below.

I followed browser sessionStorage, submit/error handling, polling, the GET lookup, archive discovery and result reconstruction for WF-RTE-request-recovery. Its Part of: relation to RT-RTE-web-request is genuine containment. Pending is an unsuccessful archive lookup, not a job-state observation; recovered output omits original context/decision fields. Independent trace/archive attempts after ordinary asking support the remember=false countercase. Billing reservation, settlement and abort are wrapper protocols, not exactly-once delivery. Installer existing-tree preservation and FPM restart support the operator-owned deployment route, RT-RTE-deploy-checkout, without an autonomous updater claim. SRC-1: apps/web/public/app.js, packages/core/src/Web/WebApplication.php, packages/core/src/Interaction/InteractionArchiveService.php, packages/core/src/Billing/BillableAskService.php, packages/core/src/Billing/BillingRequestContext.php, install.sh.

The four supersessions in reconciliation.md preserve referent identity: canonical memory, interaction archive, thematic object and thematic synchronization each match across reports. The knowledge container remains valid alongside its separately assessed answer and metadata parts. Direct knowledge editing's narrower epistemic routes are not duplicates of its entire memory route. Catalog classification's Part of: relation to interaction approval matches the source call. Neither a different prefix nor a shared storage location was used as identity evidence. No unsupported split, missing material part or unresolved inter-report conflict was found. The reconciliation retains the independent policies, cache limitations, partial failure and recovery qualifications rather than selecting stronger statuses.

Omission questions came from the frozen core/connector/test tree and producer-consumer dependencies, not just cited anchors. I checked whether CLI and low-level writes bypass generated defaults; whether broad recall or recovery can return outside strict freshness assessment; whether thematic trust flags or diagnostic traces have hidden generation/policy consumers; whether serializers omit material before delivery; and whether shipped evaluators establish answer truth or benefit. The CLI, public APIs and return branches are covered above. Searches for ContextTraceService, trusted_for_conclusions, thematic markers, vault consumption and identity-profile references in shipped packages/callers found no material challenge left without disposition. The SecurityAgent secret wrapper does not supply a deployed model consumer; the manifest profile pointer alone does not establish a profile-injection route. These search results are not a repository-complete absence finding.

I inspected the fake-provider fixture in tests/integration/ask-orchestration.php and thematic assertions in tests/integration/thematic-interaction-summaries.php as SRC-1 source programs, not passing runs or natural-language quality experiments. The compatibility README explicitly marks its material historical rather than active 1.0. Remote-adapter internals, exhaustive evaluator assertions and historical decryption remain outside this verification's detailed trace; portability, security and system-complete evaluator comparisons cannot be inferred. The reports already withhold those conclusions. Further optional expansion stopped because the selected questions have supported dispositions or the local limits below, and no identified material challenge remains undisposed. Source wiring, observed activation and causal benefit remain separate evidence levels.

The broad-request limit rests on these additional SRC-1 implementation passages, not on an executed fixture:

if (!$broadRecallRequested && ($exact['reusable'] ?? false) === true && isset($exact['answer'])) {

--- packages/core/src/Ask/AskService.php

if (!$broadRecallRequested && ($memoryAttempt['reusable'] ?? false) === true && isset($memoryAttempt['answer'])) {

--- packages/core/src/Ask/AskService.php

Blockers

none

Limits

  • RT-RTE-ask-answer, its Runtime account and the earlier-terminal-branch discussion in workflow.md underdescribe one forcing case: a recognized broad-recall request suppresses exact and semantic direct returns even when canonical recall finds nothing. SRC-1, packages/core/src/Ask/AskService.php, guards both returns with !$broadRecallRequested. A supported broad question can have reusable exact knowledge but no qualifying canonical item; it then reaches generation or provider-required instead of returning that exact answer. Withhold the inference that every reusable exact hit terminates, or that generation is reached only because knowledge is nonreusable. This local route-coverage limit does not change the supported strict metadata gate, canonical current-data countercase, optional-generation architecture or selected ordinary workflow.
  • The Delegated visibility field in EPI-RTE-knowledge-validation overstates embedding-provider visibility by saying it receives content for refresh. The inspected web confirmation path calls refreshStoredEntry, whose existing-vector preservation is evidenced in MEM-RTE-semantic-maintenance; it does not call embed. SRC-1, packages/core/src/Web/WebApplication.php, packages/core/src/Semantic/SemanticIndexService.php. Do not infer a model call or content transmission from that field for direct web validation. The validation-state admission, later eligibility effect and lack of a factual evaluator remain supported; the reports' broader indexing routes independently establish actual embedding calls.