OpenViking report verification

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

Verification

The current reports support a bounded implementation account. The earlier account-template admission blocker is repaired. No material blocker remains; the incomplete producer inventory remains a publication limit.

I read the complete supplied members, their types, correction answers, structural check, previous verification and governing contracts. The memory answer reports a correction; the other answer files are empty. The structural check says none. I judged the current findings against SRC-1 rather than treating the earlier verdict or analyst checks as evidence of correctness. Checkout HEAD equals the revision in boundary, and its status is clean. I inspected the tracked top-level tree and searched/read the source paths named below. No target code, tests, examples, services or model calls were executed. These checks establish implementation support and attributed design, not observed operation, successful recovery or benefit. The complete-artifact, partial-loop boundary remains appropriate.

Correction and dependent findings

The memory Write side, coverage inventory, MEM-OBJ-memory-index and integration issues now distinguish managed template editing from persisted-template consumption. I independently traced SRC-1, openviking/session/memory/account_templates.py: deployment-default completion, editable top-level and field descriptions, locked-field rejection, validation, size limit, staged publication/reset and registry loading. I also checked the managed PUT delegation in openviking/server/routers/admin.py.

The code permits description, eligible content-template and selected existing-field description changes. It rejects changed embedding-template values against defaults. Well-formed older persisted configurations remain readable; their consumption is not a managed editing permission. The current memory account expresses this distinction, including its index consumer. It does not replace the defective assertion with an unsupported alternate edit path. The separate RT-RTE-config-patch remains a runtime-settings mechanism, not template admission. The reconciliation correctly connects these findings without repeating the withdrawn capability or inferring another update path. The memory correction answer is sustained; the previous blocker is dismissed because its defective claim and dependencies were corrected, not merely caveated.

Runtime records and guarantee strength

• RT-CMP-query-planner, RT-CMP-account-vlm, RT-CMP-account-embedder and RT-CMP-rerank-client: checked account role selection, current-resource proxies, embedding configuration fingerprints and rerank configuration/use in SRC-1, openviking/config/vlm.py, openviking/config/embedding.py, openviking/models/rerank/__init__.py, openviking/models/rerank/volcengine_rerank.py, openviking/session/compressor_v3.py and openviking/retrieve/hierarchical_retriever.py. Separate computation roles are supported. Config/model strings do not establish immutable weights, and inaccessible provider mutation remains uninspected rather than absent.
• RT-OBJ-query-plan, RT-RTE-session-search, RT-RTE-direct-find, RT-CLM-scoped-retrieval and RT-BAP-planner-dispatch: checked the HTTP/service handoff, planner parsing, caller-scope restoration, concurrent query execution, global candidate retrieval, deduplication, optional rerank and metadata-only alternate. SRC-1 anchors: openviking/server/routers/search.py, openviking/server/auth/__init__.py, openviking/service/search_service.py, openviking/retrieve/intent_analyzer.py, openviking/storage/viking_fs/_semantic.py, openviking/storage/viking_fs/_access.py, openviking/storage/viking_vector_index_backend.py and openviking/retrieve/hierarchical_retriever.py. Exception fallback does not cover a successfully parsed empty query list. QUICK and filter-only paths differ from session planning. ROOT and bypass-ACL filters differ. The protocol claim is scoped query construction with a backend contract, not deployed isolation or answer correctness.
• RT-RTE-context-assembly, RT-RTE-plugin-recall and RT-BAP-recall-context: followed exclusions, quota gathering, tier/token estimates, rewrite status and client selection to synthetic host output. SRC-1 anchors: openviking/retrieve/context_assembler/pipeline.py, openviking/retrieve/context_assembler/gather.py, openviking/retrieve/context_assembler/budget.py, examples/memory-plugin-shared/lib/recall-core.mjs, examples/opencode-plugin/lib/memory-recall.mjs and examples/opencode-plugin/package.json. no_relevant suppresses rendered recall and cooling despite retained entries; the client also suppresses injection. Digest preference can hide original fragments. Canonical shared source plus prepack supports source wiring, not packaged execution or host compliance.
• RT-OBJ-session-commit and RT-RTE-session-commit: checked intent/raw archive persistence, enqueue, retained-root/readiness publication and accepted return in SRC-1, openviking/session/session.py, plus service/compressor and openviking/session/memory/extract_loop.py handoffs. Resume handles done/failed/readiness/order and malformed/empty input. Extraction advertises provider-selected tools, executes callbacks and extends its iteration bound for repair/refetch. The Python protocol is an AST-interpreted DSL, not ordinary shell execution (openviking/session/memory/extraction_output_protocol/python_protocol.py); the report does not claim a complete security audit. Acceptance is not extraction completion. Restart-oriented protocol support is valid without an exactly-once or physical-rollback guarantee.
• RT-RTE-skill-admission: SRC-1, openviking/session/compressor_v3.py, openviking/session/train/components/policy_optimizer.py and openviking/session/train/components/skill_policy_updater.py support conditional text-gradient planning and skill application. Deletes and writes can have partial errors while the returned policy snapshot stays old. Instruction admission is supported; numerical training, actual theory criticism and exercised improvement are not established.
• RT-OBJ-config-settings, RT-RTE-config-patch and RT-BAP-config-model: SRC-1, openviking/config/manager.py and VLM/embedding consumers support validation, persistence, publication and ordered notification with later resource reselection. Manager behavior does not itself prove HTTP authorization, concrete durability, notification compensation or deployed model identity. Local-dev ROOT and localhost configuration behavior in openviking/server/auth/plugins/dev.py supports the report's configuration-policy qualification, not a network-isolation invariant.

All these findings retain wired implementation and uninspected operation as separate statuses. Optional model fallbacks are best effort; scoped retrieval and restart preparation are protocols. The reports do not promote them to observed or deployment-wide guarantees.

Memory parts and consumer authority

• MEM-OBJ-memory-file, MEM-OBJ-memory-index and MEM-RTE-memory-application: checked body/MEMORY_FIELDS serialization, versions, lineage, append-only versus grouped merge, per-field preservation, unresolved-upsert/delete protection and index handoff. SRC-1 anchors: openviking/session/memory/utils/memory_file_utils.py, openviking/session/memory/streaming_memory_updater.py and openviking/session/memory/memory_updater.py. Index abstracts strip links and truncate bodies; optional template rendering differs from complete body retention. Successful writes can coexist with errors. The report correctly separates computational admission, physical I/O and per-item human approval; it claims neither atomicity nor truth certification.
• MEM-OBJ-archive-overview, MEM-OBJ-checkpoint and MEM-RTE-session-reconstruction: SRC-1, openviking/session/session.py and openviking/session/checkpoints.py support terminal-boundary selection, failed/missing overview limits, active-message budgeting, cumulative/legacy checkpoint differences and server-owned anchors. Checkpoint count/empty checks and truncation do not establish semantic fidelity or human authorship. Later text is returned by value; older raw history is not automatically replayed in the normal current-format path.
• MEM-OBJ-tool-result and MEM-RTE-tool-externalization: SRC-1, openviking/session/tool_result_store.py and openviking/session/tool_output_externalizer.py support separate raw storage, stubs/ref metadata, existing-source substitution and copied extraction-only hydration. Reject, preview-only and hydration-failure branches justify the recoverability qualifications. Readable display text does not establish that an opaque payload or full reasons survive in the foreground context.
• MEM-OBJ-case, MEM-OBJ-trajectory, MEM-OBJ-experience and MEM-RTE-experience-maintenance: checked separate products, first-message case alternate, trajectory reread, experience estimation and persisted versus dry-run policy application. SRC-1 anchors: openviking/session/compressor_v3.py, openviking/session/train/components/trajectory_analyzer.py, openviking/session/train/components/gradient_estimator.py, openviking/session/train/components/policy_updater.py and openviking/session/memory/experience_lineage.py. Completed read traces yield lineage tags, not proof of compliance. Text-policy revision supports later selection, not improved capacity or a formulated explanatory theory.
• MEM-OBJ-recall-ledger and MEM-BAP-ledger-selection: checked SRC-1, openviking/retrieve/context_assembler/ledger.py. Raw JSON persistence, turn/detail selection, URI-only exemption, malformed/ahead-of-clock handling, four-times-dedup pruning, 500-URI cap and nonfatal I/O support selector bookkeeping. This additional inspection narrows runtime's ledger uncertainty without contradicting its wider lifetime limits.
• MEM-RTE-resource-withdrawal: SRC-1, openviking/storage/viking_fs/_ops.py, openviking/service/fs_service.py and openviking/service/resource_memory_link_service.py confirm vector removal before filesystem deletion and service cleanup afterwards. The bridge attempts commit, rescans, directly unlinks and checks residual references. The function name does not override ordering; lower-level removal lacks the service bridge. Universal derivative revocation and already-injected text retraction remain unsupported, as stated.
• MEM-RTE-bot-recall and MEM-BAP-experience-reminder: SRC-1, bot/vikingbot/agent/memory.py and bot/vikingbot/agent/context.py support top-case/link routing, dedup/exclusions, character budgeting and user-role reminder delivery. The reported recalled URI list need not equal bodies fitting the budget. Local MEMORY.md/HISTORY.md methods do not complete the bot producer/reload account.

The memory annotations preserve the original referents. Manual extraction uses live messages and a manual_extract location in SRC-1, openviking/service/session_service.py; it is not proof of queued-commit parity. Skill package processing writes content/auxiliary metadata and hands off a lease in openviking/utils/skill_processor.py. OpenCode state serializes uncaptured parts but omits captured parts in examples/opencode-plugin/lib/memory-session.mjs. These are supported additions with their remaining limits, not replacements for runtime identities.

Epistemic license and policy succession

EPI-OBJ-memory-fields, EPI-OBJ-experience-instructions, EPI-OBJ-recall-digest and EPI-OBJ-trajectory-evaluation separate assertions, imperatives, digest bullets and evaluation output. SRC-1, openviking/prompts/templates/memory/preferences.yaml, openviking/prompts/templates/memory/experiences.yaml, openviking/prompts/templates/retrieval/recall_rewrite.yaml and their implementation consumers support those distinctions. Schema requests establish intended output, not actual warrant or delivered system-prompt authority.

I read SRC-1, openviking/retrieve/context_assembler/rewrite.py and traced EPI-RTE-digest-contract through normalization/status and the assembly/client consumer. Its allowed-URI false-assertion counterexample is valid as a source deduction: membership and bullet shape are checked, source proposition support is not. EPI-RTE-memory-guards has refetch/resolution/patch applicability checks and one patch-repair opportunity, not a final semantic-validity invariant. SRC-1, openviking/session/memory/extract_loop.py and openviking/session/memory/tools.py support the limited model-visible provenance and checks.

EPI-RTE-memory-write and EPI-RTE-memory-withdrawal correctly isolate operational upsert admission and dependency-guarded disposal. The replace counterexample follows directly from SRC-1, openviking/session/memory/merge_op/replace.py; openviking/session/memory/memory_updater.py supplies partial failure and lineage controls. None is a truth acceptance criterion. EPI-RTE-memory-consolidation uses existing directories rather than archive input; SRC-1, openviking/service/memory_compile.py and openviking/session/memory/consolidation_context_provider.py support its exploration/apply route. Requested preservation does not prove preservation.

EPI-RTE-rollout-feedback correctly distinguishes supplied evaluation, evaluator dispatch and post-extraction existence fallback. SRC-1, openviking/session/train/components/trajectory_analyzer.py and openviking/session/train/components/gradient_estimator.py support feedback timing and confidence consumption. The fallback's entailed proposition is only list existence, not rollout success. EPI-RTE-policy-training has a consequential successor consumer: SRC-1, openviking/session/train/engine.py, openviking/session/train/components/policy_trainer.py and openviking/session/train/pipeline.py support locked reload/plan/apply and returned-policy sequencing. Evaluation-only reporting supplies no universal score-threshold admission/rollback rule. Positive succession wiring coexists with independent theory, learning, reflection, autonomy and exercised-improvement unknowns.

EPI-CLM-agent-knowledge, EPI-CLM-reusable-experience and EPI-CLM-memory-benefit accurately attribute SRC-1, README.md and the experiences schema. Reported benchmark gains do not supply registered observed runs, component attribution or transfer evidence. The ledger's implemented architectural status is compatible with wired implementation/uninspected operation. Indeterminate content relations preserve the absence of actual semantic input/output evidence without inferring conjecture merely from model generation. No report declares an evidenced absence or an exhaustive negative.

Workflow, containment and reconciliation

WF-RTE-session-capture and the workflow account support the conditional OpenCode v1 sequence. I checked SRC-1, examples/opencode-plugin/index.mjs, examples/opencode-plugin/lib/memory-session.mjs, examples/opencode-plugin/lib/memory-recall.mjs, examples/memory-plugin-shared/lib/batch-send.mjs, examples/memory-plugin-shared/lib/pending-queue.mjs and examples/memory-plugin-shared/lib/retryable.mjs: parallel injection/recall, event state, serialized flush, batch fallback, queue writes/replay and commit handling. Queued messages can count as captured; commit need not await complete transmission; queued commit status does not check enqueue success. The report keeps these facts beside the delivery claim. Local retry ownership differs from server archive recovery. Neither establishes end-to-end exactly-once or eventual delivery.

I checked all declared Part of relations: archive overview/checkpoint belong to the archive container; reconstruction is its later-context branch; digest output/checking belong to assembly; extraction guards and updater write/delete are submechanisms on the commit path. Reuse by other producers does not make every use part of commit. The cross-kind digest output relation is explained. File/assertion-field and experience-policy/instruction-content records have different operative scope rather than identical referents. All declarations and their anchors/statuses were considered in the groups above; no unsupported supersession is proposed or needed.

The reconciliation preserves the valid containers, parts and adjacent routes. Added ledger coverage, withdrawal ordering, fallback evaluation and capture recovery do not contradict runtime positives. Requested system-prompt injection differs from the implemented bot user-role reminder. Template consumption differs from template edit permission. No current unresolved inter-report conflict or missing conflict evidence was identified. Reconciliation makes no verdict of truth, benefit or uniform lifecycle from these convergences.

Omission questions and stopping decision

The frozen tracked tree and producer/consumer dependencies guided selected challenges beyond record anchors: could another server producer invalidate the caller-triggered commit account; could resource processing generate memory outside captured conversation; could another shipped consumer change delivery authority; and does the claimed guidance editing surface admit the stated changes? The template challenge is resolved by the correction above. Bot and OpenCode consumers have different selection/delivery paths, already represented; the selective workflow does not claim to exhaust them.

For producer alternatives, I independently searched SRC-1, openviking/server/routers/sessions.py, openviking/service/session_service.py and openviking/service/session_auto_commit.py. Message writes and idle scanning can schedule automatic commit. The service's scheduling point is explicit:

task = asyncio.create_task(self.run_auto_commit(session_id, ctx, reason=reason_hint)) --- openviking/service/session_service.py

SRC-1, openviking/storage/queuefs/add_resource_processor.py, openviking/service/resource_service.py and openviking/service/resource_memory_link_service.py establish an additional reason/resource-context producer through the session family:

await self._resource_service._link_resource_reason_memory( result=result, ctx=ctx, reason=msg.reason, source_name=msg.source_name, ) --- openviking/storage/queuefs/add_resource_processor.py

The bridge constructs a user-role message in a fixed reason session and requests commit. That role is not proof of ordinary human conversational provenance. Current memory limitations and reconciliation explicitly leave these producer triggers/provenance incomplete rather than claiming exhaustive coverage. This supports the retained inventory limit below, not a blocker against the selected submission protocol.

Further optional omission expansion stopped because the selected consequential questions have supported dispositions and no identified material contradiction remains without one. Native storage, gateway, parser/privacy/watch behavior, bot write/compaction loops, other integrations and concrete evaluator variants remain partial or uninspected. The supported retrieval/admission/delivery findings survive; uniform lifecycle, complete producer/admission, oracle, rationale, deployed behavior and efficacy comparisons remain withheld. Additional repository surfaces alone do not warrant extending this bounded account into a whole-system audit, and unsearched behavior is not evidenced absence.

Blockers

none

Limits

• The selected producer inventory remains incomplete around RT-RTE-session-commit, MEM-RTE-memory-application and the resource lifecycle in MEM-RTE-resource-withdrawal. SRC-1 inspection of server message-write/idle auto-commit and resource-addition reason-to-session production establishes additional triggers and input provenance, as retained above. The current reports do not claim exhaustive triggers, so the selected commit/search/workflow conclusions hold. Readers should withhold a complete producer/admission comparison, equivalence of all producer policies, and the inference that resource-derived memory enters only through captured user conversations. Full parser/watch and lifecycle behavior remains uninspected.