Files
story/docs/viking-memory-integration.md
T

37 lines
5.8 KiB
Markdown

# Viking managed memory integration
Configured collection: `memory`, resource `mem-3a1174a1`, project `default`, Beijing endpoint. The existing collection has emotional-companionship extraction rules `event_v1` and `profile_v1` (assistant isolation enabled). This is the managed Viking memory service, not OpenViking.
## Runtime
API and worker accept `VIKING_MEMORY_RESOURCE_ID`, `VIKING_MEMORY_COLLECTION_NAME`, `VIKING_MEMORY_API_KEY_FILE`, `VIKING_MEMORY_EVENT_TYPE` and `VIKING_MEMORY_PROFILE_TYPE`. An empty resource ID disables the integration. An empty collection name keeps the compatibility startup-prefetch path. The API key is a server-only file; it is never returned to a device or written into a firmware image. The endpoint is HTTPS; redirects are disabled. Error logs contain status/code, never vendor response bodies or transcripts.
Terminal conversation extraction requests also enqueue an independent `conversation.viking_sync_requested` outbox event. The worker submits final user and assistant turns with AddSession. Frozen transcript/memory consent and current subject/memory/transcript eligibility are checked. No user-only or diagnostic assistant-only conversation is submitted. The database remains the source of full transcripts.
User identity is SHA-256 of the tenant and subject UUIDs, prefixed `u_`; it survives device restarts and changes of device binding. Assistant identity is the stable platform companion ID, currently shared across platform persona versions. Every conversation has a distinct `c_<conversation UUID without hyphens>_<batch>` session identifier. Batches contain up to 100 messages. A retry uses the same identifier; a late transcript revision replaces that conversation's batch. Audit digests avoid rewriting unchanged successful submissions. Initial indexing/extraction is asynchronous.
At hardware session creation the API resolves the currently bound subject and revalidates memory consent. It returns a per-user, non-secret native memory description containing the collection name, hashed user ID, stable assistant ID, extraction-rule names, limit and transition words. Firmware maps this description to Volcano `Config.MemoryConfig`; Volcano therefore retrieves topic-relevant memories for every turn. A different subject binding produces a different hashed user ID. The Viking API key stays on the platform worker and is used only for writes, platform search and erasure.
The dynamic device update also enables `S2SConfig` while retaining `LLMConfig` for hybrid orchestration. S2S App ID and token live in the Volcano bot configuration and in root-owned server recovery files, never in device session responses or firmware. The device supplies only per-session dialog/persona fields. Existing in-call memory search remains as a compatibility path for deployments without a configured native collection.
There are no database migrations. Native subtitle callbacks remain in device-probe mode; the reliable device transcript upload supplies these sessions. Pending memory extraction is independent of streamed audio playback.
## Lifecycle and limits
Current consent withdrawal immediately gates future Viking reads/writes. Subject privacy erasure calls scoped event/profile deletion before completing the provider-index deletion subtask. Vendor extraction is asynchronous; late vendor extraction after an erasure request needs follow-up reconciliation before treating provider erasure as fully verified. Individual locally curated-memory deletion does not delete independently extracted Viking events/profiles. For the present integration, use the Viking console for editing or deleting those derived entries; a unified platform memory-management UI is not implemented. Do not describe the existing local memory list as a complete Viking list.
Automatic extraction begins on conversation completion/failure and final transcript delivery. A sudden power-off relies on the existing heartbeat recovery to close the conversation. Native retrieval is available again after every restart because identity comes from the platform binding, not device RAM. Full historical backfill is explicit; enabling the integration does not automatically export all past conversations.
## Verification
Deployment on 2026-09-06: API and worker `0.79.0-rc.s2s-memory1`; callbacks remain `0.78.3-rc.subtitle-memory3`. Readiness returned 200. Current symlink points to `/opt/data-terminal-cloud/releases/0.79.0-rc.s2s-memory1`; rollback uses `0.78.4-rc.viking1`. The Volcano bot uses S2S hybrid mode, and `VoiceChatRoleForRTC` has both required Viking policies. The pre-update bot configuration is stored in the protected first-version backup.
One real conversation (`157f866d-c364-4ae8-b169-50ca07024e5a`, three final messages) was explicitly queued for backfill. Viking produced two event memories, and the production service retrieved 76 characters of startup memory. Synthetic event/profile entries were deleted and subsequent queries returned zero. Device power-cycle/spoken recall is pending user verification; server retrieval alone is not proof of successful audible recall.
- Real API-key calls verified against the configured collection: AddSession, event search, profile search.
- Synthetic test used a separate user namespace; no test preference is attached to the real user.
- Tests cover vendor result scope filtering, error redaction, stable identity/session IDs, native per-user filter mapping, scoped deletion, SQL outbox deduplication, late transcript replacement, frozen consent, cross-tenant rejection, and subject-bound startup context.
- A dedicated PostgreSQL/Redis environment is used for integration tests, separate from production data.
Official API references: https://www.volcengine.com/docs/84313/1783353 , https://www.volcengine.com/docs/84313/2100967 , https://www.volcengine.com/docs/84313/2100966 , https://www.volcengine.com/docs/84313/1783358 , https://www.volcengine.com/docs/84313/1783359 .