Supermemory report verification

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

Verification

The pinned reports support publication of a bounded public-integration account. Both earlier epistemic blockers are repaired. One additional documented memory interface is missing from the partial inventory; its consequences are retained below as a limit, not a system-level negative. The supplied artifact check reports no structural failures. I read all supplied members, types, correction answers and the previous verification. I reviewed every declaration and annotation, its source anchors, evidence layer and status, all three declared Part of: relations, the three supersessions and the reconciliation's conflict dispositions. This semantic review does not substitute for the engine's citation and quotation checks.

The boundary remains supported. SRC-1's checkout HEAD equals the reviewed revision and its working tree is clean. Direct reading of apps/docs/self-hosting/overview.mdx confirms that the downloadable engine is from a separate non-public codebase. Public caller wiring does not expose backend extraction, ranking or maintenance implementation. No target code, test or example was executed; no service was called or additional source acquired. Component records correctly keep generation endpoints, extraction models and embeddings separate, retaining version and mutability uncertainty rather than asserting fixed weights or observed training.

Correction review. The two epistemic answers say the author separated OpenAI preparation from the Vercel cache and conversation import from derived graph facts. I independently inspected SRC-1, packages/tools/src/openai/middleware.ts, especially both preparation functions and the returned facade. Chat forwards enhanced messages; Responses forwards cleaned input and enhanced instructions. Both have separate no-text and caught-error branches. The source search finds no Vercel MemoryCache reference in this module. EPI-OBJ-openai-context therefore names the actual transient payload within RT-RTE-openai-call, not RT-OBJ-memory-cache. Its cross-kind containment is explained and supported. The inventory, ledger and bounded conclusion now preserve this distinction. The earlier cache blocker is discharged.

Direct reads of SRC-1, packages/tools/src/vercel/middleware.ts and packages/tools/src/conversations-client.ts, confirm conversion of selected conversation content and appended assistant text into role-labelled document text. They do not establish import of already-derived graph facts. The revised authority-route ledger assigns MEM-OBJ-document-content to this acquisition. Its bounded conclusion separately cites MEM-RTE-engine-dreaming for the opaque document-to-fact stage. The earlier lineage blocker is discharged without weakening supported later retrieval findings. The broad EPI-OBJ-memory-facts remains a container, not a substitute for every object along that chain.

Runtime controls and alternate branches. Independent tracing of SRC-1, packages/tools/src/vercel/index.ts, packages/tools/src/vercel/middleware.ts, packages/tools/src/shared/memory-client.ts, packages/tools/src/shared/prompt-builder.ts, packages/tools/src/shared/memory-context.ts and packages/tools/src/tools-shared.ts, supports RT-RTE-vercel-call, EPI-RTE-memory-format and RT-BAP-memory-context. I checked generation and streaming, strict versus default fallback, no-text mode branches, new-user versus continuation reuse, both save predicates and final serialization. The five-second control requests abort; it is not an SDK-independent wall-clock guarantee. Save is not awaited by the returned generation or stream flush. Owned delimiter replacement is not truth validation or model compliance. Full-mode normalization can suppress a dated duplicate in favor of static text; query mode omits the profile before deduplication. Custom templates remain separately indeterminate.

The earlier string-content branch precedes structured tool filtering. The runtime correctly describes that branch without claiming a demonstrated supported-input bypass through external provider types. Data URLs become placeholders at serialization. Neither tool exclusion nor image eligibility establishes semantic redaction or image understanding. These qualifications preserve the supported implementation findings.

Independent reads of SRC-1, apps/mcp/src/server/index.ts, apps/mcp/src/server/auth/index.ts, apps/mcp/src/server/space.ts, apps/mcp/src/server/space-state.ts, apps/mcp/src/server/prompts/context.ts, and the forgetting handler, plus searches of server upload preparation and explicit-space save/setter branches, support the MCP route distinctions. RT-RTE-mcp-forget checks direct IDs and exact content differently from approximate candidates; no mandatory human gate follows from two calls. RT-RTE-upload-session consumes a stored capability before forwarding, rather than repeating account authentication at upload. Transactional consumption does not establish exactly-once remote ingestion. Explicit namespace arguments bypass active selection, while RT-BAP-space-selection describes only a durable routing default. API-key caching, external namespace authorization and host placement of the requested context prompt remain correctly qualified.

Memory and epistemic findings. The source passages in the declared records support separate document, fact, profile, eligibility, file and cache objects. Direct graph/review documentation reads and targeted processing, profile, withdrawal and connector searches under SRC-1 confirm the consequential distinctions in MEM-RTE-engine-dreaming, MEM-RTE-inference-review, MEM-RTE-source-maintenance, MEM-RTE-semantic-forget and MEM-RTE-connector-sync. Document indexing can precede graph readiness. Review changes search eligibility and inference flags; it does not require an evidence-consuming truth decision or pre-search quarantine. Permanent document deletion, soft forgetting, review undo, semantic preview/apply drift and connector preservation at disconnect are different contracts. Backend propagation is not inspected enforcement. The PM/payment example in apps/docs/concepts/graph-memory.mdx supports the specific ampliative classification in EPI-RTE-graph-dreaming, not one classification for all extraction.

Producer-to-consumer reads of SRC-1, apps/mcp/src/server/client/index.ts, apps/mcp/src/server/tools/get-document.ts and shared formatting/mutation helpers support MEM-RTE-mcp-read, EPI-RTE-search-projection and EPI-RTE-mutation-checks. Search projection drops inference status while list projection retains flags; profiles flatten entries to strings. The memory-to-document fallback is real, but optional reload is not automatic grounding. Missing document status and direct memory ID are alternate mutation branches, not covered by the narrower status/preview gates. Equality and returned counts are protocol checks, not factual warrant. Formatting and mutation checking are correctly declared parts of their larger runtime routes.

Command-dispatch, read and edit source inspection in SRC-1, packages/tools/src/claude-memory.ts, and the complete simple example support MEM-RTE-claude-file, EPI-RTE-claude-files and MEM-BAP-file-reload. Reads use stored document content, replacement is literal and first-match, writes try update before add fallback, and rename writes the destination before source deletion. The example returns tool results to Claude once, not through an indefinite agent loop. LiveKit source inspection supports capture, scoped buffering/requeue, recall reuse and assistant-role insertion in MEM-RTE-livekit-session. Agent Framework hook and serialization reads support separately optional storage including system text in RT-RTE-python-context. These are wired paths with unobserved host/service operation, not adapter parity. Graph relation searches support the transformed display subset in MEM-CLM-graph-display, not validation of backend inference.

The graph-truth, review-confirmation and benchmark claims retain their attributed strength. SRC-1, apps/docs/memorybench/memscore.mdx, describes reference-answer judging with failures excluded from accuracy, not a product memory-admission oracle. Direct reading of .github/workflows/publish-tools.yml supports RT-RTE-publish-tools as an ordered version/build/compatibility/publication gate, not observed rollout or self-revision. No report promotes retention into proven improved capacity, reflection, theory-building or exercised self-improvement.

Workflow and reconciliation. Direct source tracing of SRC-1, apps/sdk-playground/src/lib/chat-handlers.ts, packages/tools/src/openai/tools.ts and apps/sdk-playground/src/app/api/chat/route.ts, supports the workflow account on RT-RTE-tool-loop. Tool calls within a response execute concurrently. A missing required string in valid object JSON can return an error for another iteration; malformed or blank original JSON can fail during uncaught trace reparsing. No-tool output terminates without an answer-quality gate. The eight-iteration bound and outer deadline do not roll back remote mutations. HTTP response construction is narrower than browser receipt or user acceptance.

The reconciliation correctly preserves identity supersessions for Claude files, their command route and inference review without changing analyst-owned values. Broader fact, dreaming and explicit-read containers need not be superseded by narrower parts. All three explicit containment fields are supported: OpenAI transient payload, Vercel formatting stage and framework mutation-check stage. No unresolved inter-report substantive conflict remains. Reconciliation's statement that correction answers were not supplied is not evidence about this invocation: epistemic answers are now supplied and were assessed above. Its current source/record connections do not depend on treating those answers as absent, so that local provenance sentence does not reopen either blocker or prevent the bounded account.

Omission search and stopping decision. I inspected the frozen top-level tree and package/application families, compared producer/consumer paths and searched alternative adapters and shipped guidance for context control and approval. The questions were whether another path defeats the adapter-specific cache account, establishes universal human approval, or changes the memory/control inventory. Mastra/VoltAgent hook searches and the shipped skill's destructive-tool guidance support the bounded distinction in MEM-CLM-adapter-variants, not equivalence or an enforced human gate. The additional apps/docs/smfs/ family supplies the local omission below. Its mount and shell-tool contracts fit requested read-back and software admission, but add distinct path-based extraction, virtual-profile and sync controls. They do not contradict the inspected JavaScript/Python routes or establish observed benefit. Further expansion stopped because the reports already withhold exhaustive inventory, all-adapter guarantees, global withdrawal and system-complete epistemic negatives. No identified material challenge remains without a disposition. Uninspected implementations and tests are not evidenced absences.

Blockers

none

Limits

• The memory coverage account, especially the exact-file route MEM-RTE-claude-file and derived-profile object MEM-OBJ-profile-summary, does not inventory the separate documented SMFS mount and Bash-tool interfaces. SRC-1, apps/docs/smfs/overview.mdx, apps/docs/smfs/mount.mdx and apps/docs/smfs/bash-tool.mdx, declare path-selected extraction, a virtual read-only profile, cached reads, queued writes and optional remote polling; the Bash tool also declares explicit refresh and configurable memory paths. This is a local omission from an explicitly partial inventory, not evidence against the recorded Claude-file or middleware mechanisms. Readers should withhold complete filesystem-interface, extraction-admission and sync/cache-control comparisons. Implementation, deployed compatibility and operation of these additional interfaces were not established. The documented contract supplies the minimum evidence:

  By default, files named user.md or memory.md are treated as memory paths. Drop those files anywhere in your mount and Supermemory generates memories from them automatically. --- apps/docs/smfs/mount.mdx

Every mount has a virtual file at the root called profile.md. It's auto-generated, read-only, and backed by Supermemory. --- apps/docs/smfs/mount.mdx

Local reads hit the cache. Local writes queue and push to Supermemory in the background. Remote changes are pulled on a poll. --- apps/docs/smfs/mount.mdx