Related Pages

Related topics: Storage, RAGFS, Embeddings, and Retrieval, Server, Python/Go SDKs, Rust CLI, and Web Studio, Agent Integrations, VikingBot, Deployment, and Community

Overview and Core Concepts

What OpenViking Is

OpenViking is an open-source context database that combines Retrieval-Augmented Generation (RAG) with semantic search. It is designed to give AI agents and applications a persistent, structured, and queryable memory layer, exposed through a unified filesystem-style interface. The project positions itself as a "Context Database MCP (Model Context Protocol) server" that can serve as long-term memory for AI agents and applications. Source: examples/k8s-helm/README.md:9-10

The project's scope spans resource ingestion, hierarchical storage, semantic retrieval, session management, and an extensible parser/plugin ecosystem. It provides both a Python SDK and a Go SDK, an HTTP server, a CLI, a web frontend (Web Studio), a conversational agent (Vikingbot), and several pre-built integrations for host environments such as Claude Code, Codex, and OpenClaw. Source: sdk/go/README.md:1-10, npm/cli/README.md:1-15

Core Integration Modes

OpenViking currently exposes three common integration paths, as documented in the basic usage example:

For anything beyond a one-process local demo, the project recommends HTTP server mode. Source: examples/basic-usage/README.md:21-29

The server is launched with openviking-server, optionally with --with-bot to enable Vikingbot endpoints used by the sessions UI. Source: web-studio/README.md:25-34

The Viking URI and Context Layers

A defining concept of OpenViking is the viking:// virtual filesystem, which is the canonical addressing scheme for all resources, sessions, and memories stored in the system. Operations such as ls, tree, read, abstract, overview, find, grep, glob, rm, mv, and stat all operate against this URI space. Source: npm/cli/README.md:5-19

Resources are organized into three semantic levels (L0, L1, L2):

• L0 (Abstract): a short functional description used for fast retrieval; stored as .abstract.md per directory. Source: openviking/parse/parsers/README.md:103-108
• L1 (Overview): a detailed directory overview, including file structure analysis and key entity indexes; stored as .overview.md. Source: openviking/parse/parsers/README.md:103-108
• L2 (Detail): the original full content, accessed via read. Source: openviking/parse/parsers/code/README.md:18-23

This tiered design allows retrieval to first match at L0 for recall, then escalate to L1 for orientation, and finally to L2 for full content, which directly addresses community concerns about token consumption and cost optimization (Tracking #744). Source: openviking/parse/parsers/README.md:110-120

Resource Ingestion and Parsers

OpenViking accepts a wide range of source formats through a registry-based parser architecture. Registered parsers include:

• TextParser — .txt, .log, .csv, .tsv, .json, .yaml, .yml, .xml, .ini, .cfg, .conf
• MarkdownParser — Markdown content
• PDFParser — PDF files, with optional MinerU API backend
• HTMLParser — .html/.htm using readabilipy for noise removal
• CodeRepositoryParser — code repositories with syntax highlighting and .gitignore awareness
• MediaParser — images, audio, and video formats

Source: openviking/parse/parsers/README.md:30-62

All parsers ultimately normalize content to Markdown, which is then passed through MarkdownParser for structural processing. This produces a uniform tree in AGFS (the underlying storage) with .abstract.md and .overview.md at every directory level. Source: openviking/parse/parsers/README.md:91-108

A two-stage pipeline separates parsing from semantic processing via a SemanticQueue. Each parser writes to a temporary directory, and a TreeBuilder finalizes the tree by moving files into AGFS and enqueuing work bottom-up. Source: openviking/parse/parsers/README.md:142-158

Plugin Ecosystem and Agent Integrations

OpenViking ships with reference plugins that turn it into the long-term memory layer for several agent hosts:

• Claude Code Memory Plugin: hooks SessionStart, UserPromptSubmit, Stop, PreCompact, and SessionEnd; auto-recall injects memories via additionalContext; commits extract structured memories on PreCompact and on SessionStart for ended sessions. Source: examples/claude-code-memory-plugin/README.md:1-25
• Codex Memory Plugin: a parallel hook design for OpenAI's Codex, using session id cx-<codex_session_id>, with incremental capture on Stop and commit on PreCompact. Source: examples/codex-memory-plugin/README.md:1-12
• OpenClaw Plugin: an HTTP-only client that uses a pure-JS zip library to upload directories via /api/v1/resources/temp_upload; it never sends local filesystem paths to the server directly. Source: examples/openclaw-plugin/README.md:1-7

Vikingbot, built on the Nanobot project, is the project's own agent runtime. It exposes seven dedicated OpenViking tools: openviking_read, openviking_list, openviking_search, openviking_add_resource, openviking_grep, openviking_glob, and openviking_memory_commit. It also reads model configuration from the vlm section of ov.conf, so the provider does not need to be re-declared. Source: bot/README.md:1-15, bot/README.md:67-77

Deployment and Community Direction

For production workloads, OpenViking publishes a Helm chart targeting Kubernetes 1.24+ and Helm 3.8+, with configurable LoadBalancer annotations for major cloud providers. Source: examples/k8s-helm/README.md:1-30

The community has flagged several themes that shape the project's direction. Issue #55 requests a "Memex" personal knowledge assistant demo to showcase full capabilities end-to-end. Source: community context, Issue #55. Issue #591 documents a real compatibility regression in the OpenClaw plugin that caused conversations to hang, illustrating the importance of versioned plugin contracts. Source: community context, Issue #591. Issue #744 tracks token-consumption and embedding-cost optimizations, which align with the project's L0/L1/L2 layered retrieval design. Source: community context, Issue #744. Issue #394 proposes zero-knowledge context proofs to guarantee the integrity of long-term agent context, a longer-term direction for the protocol. Source: community context, Issue #394.

See Also

• Architecture
• Context Types
• Context Layers
• Viking URI
• Plugin Integrations
• Server Deployment

Related Pages

Related topics: Overview and Core Concepts, Server, Python/Go SDKs, Rust CLI, and Web Studio, Agent Integrations, VikingBot, Deployment, and Community

Storage, RAGFS, Embeddings, and Retrieval

OpenViking's persistence and retrieval layer is the foundation that turns a heterogeneous collection of files, web pages, code repositories, and conversational turns into a queryable context database. This page explains how that layer is organized, how embeddings are produced and indexed, and how retrieval APIs expose the result to SDK, HTTP, MCP, and CLI clients.

1. RAGFS: The Virtual Filesystem at the Core

OpenViking exposes every resource through a single virtual filesystem identified by the viking:// URI scheme. Underneath that scheme sits RAGFS (Retrieval-Augmented File System), a content-aware filesystem that augments ordinary files with semantic metadata and a three-tier context model.

The three tiers are produced by the parser subsystem and persisted alongside each file:

• L0 — Abstract: a short description of a directory or file, stored as .abstract.md alongside the entry. Useful for quick summaries in search results.
• L1 — Overview: a medium-detail structural description, stored as .overview.md, listing children, key entities, and section boundaries.
• L2 — Detail: the full original content, loaded on demand.

Source: openviking/parse/parsers/code/README.md:18-30. For directories, the parser builds a hybrid layout where a small section may merge into its parent when it has no further children, and TreeBuilder.finalize_from_temp() moves the assembled tree from the parser's temporary directory into RAGFS and enqueues semantic processing bottom-up. Source: openviking/parse/parsers/README.md:24-30.

2. Storage Subsystems

RAGFS is composed of several cooperating storage modules under openviking/storage/:

The CLI surface reflects this split: file operations (ls, tree, read, write, rm, mv, stat, get) act on RAGFS entries, while export / import move entire trees through ovpack. Source: npm/cli/README.md:6-26.

The HTTP server mirrors the same surface for remote clients. Local file and directory uploads go through the /api/v1/resources/temp_upload endpoint rather than passing absolute paths across the wire, and directory uploads are zipped client-side first. Source: examples/openclaw-plugin/README.md:8-10.

3. Embedding Pipeline

After parsing, each resource is enqueued for semantic processing. TreeBuilder finalizes the temporary tree by moving files into RAGFS and pushing them onto the SemanticQueue, which processes nodes bottom-up so that children are embedded before their parents. This ordering matters because directory-level L0/L1 summaries depend on the embeddings and metadata of their contents. Source: openviking/parse/parsers/README.md:24-30.

Embedding configuration is supplied through the embedding section of the OpenViking configuration. In the Helm chart, the dense embedding provider is configured via openviking.config.embedding.dense.api_key, and the chart's cloudProvider value drives LoadBalancer annotations across AWS, GCP, and other providers. Source: examples/k8s-helm/README.md:36-50.

Token consumption and embedding cost have become a recurring community concern. Tracking issue #744 ("Token Consumption & Cost Optimization Tracker") explicitly categorizes community reports about API call costs and embedding processing, and the Claude Code memory plugin ships tunables to keep both recall and capture paths within budget:

• OPENVIKING_COMMIT_TOKEN_THRESHOLD (default 20000) gates client-driven commits.
• OPENVIKING_RESUME_CONTEXT_BUDGET (default 32000) caps the archive overview fetched on session resume.
• OPENVIKING_CAPTURE_MAX_LENGTH (default 24000) limits sanitized capture text.

Source: examples/claude-code-memory-plugin/README.md:30-60.

4. Retrieval Interfaces

OpenViking offers several retrieval modes, exposed uniformly through the Python SDK, HTTP API, CLI, and MCP tools:

• find — semantic retrieval with scoring, used for "give me the most relevant memories and resources".
• search — context-aware retrieval (marked experimental in the CLI) that combines semantics with structural cues.
• grep — regex content search over viking:// files.
• glob — file-pattern discovery for known file names or extensions.

Source: npm/cli/README.md:6-26 and examples/claude-code-memory-plugin/README.md:16-30.

The basic usage example exercises this stack end to end: client.add_resource(...) triggers ingestion, client.wait_processed(...) blocks until the SemanticQueue finishes, then client.find(...), client.abstract(...), client.overview(...), and client.read(...) walk the L0/L1/L2 tiers. Source: examples/basic-usage/README.md:42-58.

Web Studio, the React/Vite frontend, depends on the same HTTP surface (default http://127.0.0.1:1933) and additionally requires VikingBot endpoints for the sessions UI, which only become available when the server is started with --with-bot. Source: web-studio/README.md:8-22.

5. Community Concerns Touching This Layer

Two community issues are directly relevant to anyone working on storage and retrieval:

• Context integrity (#394) proposes "Zero-Knowledge Context Proofs" so that an agent can verify the integrity of recalled context. This is a normative request aimed at the storage and retrieval boundary, not a current implementation.
• OpenClaw compatibility (#591) reports a real failure mode where the memory-openviking plugin causes conversations to hang after OpenClaw 2026.3.12; the root cause is reported to be outside OpenViking but the symptoms surface as silent retrieval hangs. Operationally, this is a reminder that retrieval timeouts (OPENVIKING_TIMEOUT_MS, OPENVIKING_CAPTURE_TIMEOUT_MS) must stay under the surrounding hook timeouts. Source: examples/claude-code-memory-plugin/README.md:50-60.
• Maintainer map (#1082) routes storage and retrieval questions to specific reviewers — useful when filing PRs against openviking/storage/*.

See Also

• Parsers and Resource Ingestion
• MCP Integration
• Server Mode Quick Start
• Authentication and Multi-Tenancy

Related Pages

Related topics: Overview and Core Concepts, Storage, RAGFS, Embeddings, and Retrieval, Agent Integrations, VikingBot, Deployment, and Community

Server, Python/Go SDKs, Rust CLI, and Web Studio

OpenViking is shipped as a layered product surface: a Python-based HTTP server at the core, lightweight HTTP clients in Python and Go, a native Rust CLI, and a React/Vite Web Studio. Together they form the "outer ring" that lets external systems and human operators interact with the viking:// filesystem, retrieval, sessions, and memory pipeline without depending on the embedded SDK.

1. OpenViking HTTP Server

The OpenViking Server is the canonical deployment target for shared, multi-session, multi-agent workloads. Web Studio does not embed storage, indexing, retrieval, task queues, or the VikingBot runtime — it must connect to a running OpenViking Server (web-studio/README.md:1-15).

Default contract:

If the server is started without --with-bot, core APIs (resources, search, tasks, system status) continue to work, but /bot/v1/* returns 503 and the Web Studio sessions page cannot provide real chat behavior (web-studio/README.md:22-35).

The server also exposes a native MCP endpoint for tool-based hosts. The Codex memory plugin, for example, wires Codex directly to OpenViking's /mcp streamable HTTP endpoint with Bearer auth, exposing search, store, read, list, grep, glob, forget, add_resource, and health — no local MCP server process is required (examples/codex-memory-plugin/README.md:1-10).

2. Python SDK (`openviking-sdk`)

openviking-sdk is the small package for users who only need to call an existing OpenViking server over HTTP. It deliberately avoids the heavier local-runtime, server, and CLI dependencies of the main openviking package (sdk/python/README.md:1-5).

• PyPI package: openviking-sdk
• Import name: openviking_sdk
• Exports: AsyncHTTPClient, SyncHTTPClient
• Requires: Python 3.10+ and a reachable server (e.g. http://127.0.0.1:1933)

Configuration precedence (highest wins): explicit constructor arguments → environment variables (OPENVIKING_URL, OPENVIKING_API_KEY, OPENVIKING_ACCOUNT, OPENVIKING_USER, OPENVIKING_ACTOR_PEER_ID, OPENVIKING_TIMEOUT) → ovcli.conf (default ~/.openviking/ovcli.conf, override via OPENVIKING_CLI_CONFIG_FILE) (sdk/python/README.md:18-30).

Authentication distinguishes a user_key (normal data access) from a root_key (administrative). The root_key does not directly work with tenant-scoped APIs such as add_resource, find, or ls unless account and user are also passed (examples/basic-usage/README.md:67-77). The basic-usage example demonstrates the canonical SDK flow: initialize, add a resource, browse viking://, wait for semantic processing, load L0/L1/L2 context with abstract/overview/read, run find and grep, and finally create a session and append messages for later memory extraction (examples/basic-usage/README.md:55-90).

3. Go SDK

The Go SDK is published as a module under sdk/go/. Its examples/basic_usage/main.go script exercises the full surface in a single run: create a temporary Markdown file, import it as an OpenViking resource, read and update it, run semantic retrieval, exercise watch and skill management APIs, create a multi-message session, commit it, poll the memory extraction task, and search both user and peer-scoped memories (sdk/go/README.md:1-15). This makes it the recommended integration path for Go services that need to participate in OpenViking's memory and skill workflows.

4. Rust CLI (`@openviking/cli`)

The CLI is distributed as a native Rust binary under the @openviking/cli npm scope, with per-platform packages such as @openviking/cli-darwin-arm64 and @openviking/cli-darwin-x64 (npm/cli/README.md:75-82). It mirrors the server's filesystem and retrieval surface as commands.

The tui command provides an interactive file explorer over the viking:// tree, and chat connects to the locally running VikingBot agent. Note that add-resource accepts directories containing common code, documentation, and config extensions (.py, .js, .ts, .go, .rs, .java, .cpp, .json, .yaml, .toml, .csv, .rst, .proto, .tf, .vue) in addition to media and document formats (examples/openclaw-plugin/README.md:1-5).

5. Web Studio (React/Vite Frontend)

Web Studio is a static single-page application built with React and Vite. It provides resource management, retrieval, bot-backed sessions, and operational diagnostics, but it is intentionally thin: there is no embedded OpenViking storage, indexing, retrieval, task queue, or VikingBot runtime inside the bundle (web-studio/README.md:1-10). All state lives behind the OpenViking Server's HTTP API.

flowchart LR
    User[Operator / Browser] -->|HTTPS| Studio[Web Studio<br/>React + Vite]
    Studio -->|HTTP 1933| Server[OpenViking Server<br/>openviking-server]
    Server --> Bot[VikingBot<br/>--with-bot]
    PySDK[Python SDK<br/>openviking-sdk] -->|HTTP| Server
    GoSDK[Go SDK<br/>sdk/go] -->|HTTP| Server
    RustCLI[Rust CLI<br/>@openviking/cli] -->|HTTP| Server
    MCP[MCP Hosts<br/>Claude Code / Codex] -->|/mcp streamable HTTP| Server

The same server therefore serves Web Studio, all language SDKs, the CLI, and arbitrary MCP hosts. Plugins for Claude Code, Codex, and OpenClaw are additional client surfaces that connect to the same server-side /mcp and resource APIs (examples/claude-code-memory-plugin/README.md:1-15, examples/codex-memory-plugin/README.md:1-10, examples/openclaw-plugin/README.md:1-10).

6. Operational Notes and Known Issues

A few cross-cutting concerns surface repeatedly in community discussions:

• Server must be up for any client surface. The CLI, Python/Go SDKs, and Web Studio are pure HTTP clients; they do not spawn a local server. If openviking-server is not reachable, health and status commands will fail.
• Bot endpoints require --with-bot. VikingBot tools such as openviking_read, openviking_search, openviking_memory_commit (7 dedicated tools) only resolve to a live backend if the server was started with bot support (bot/README.md:1-20).
• Plugin compatibility. Community issue #591 reports that upgrading OpenClaw to 2026.3.12 causes the memory-openviking plugin to hang conversations — the failure is reported as external to OpenViking's own server, but it underscores the importance of pinning the OpenClaw host version against the plugin's expected lifecycle hooks (afterTurn, assemble, compact) (examples/openclaw-plugin/README.md:1-10).
• Token and cost optimization. Tracking issue #744 collects user concerns about token consumption, API call costs, and embedding processing across all client surfaces. The split-SDK design (openviking-sdk vs. full openviking) and the native Rust CLI are partial responses: thinner client packages avoid pulling in heavy runtime dependencies when only HTTP calls are needed.

See Also

• Architecture overview
• Server Mode Quick Start
• MCP Integration Guide
• Authentication Guide
• VikingBot integration

Related Pages

Related topics: Overview and Core Concepts, Storage, RAGFS, Embeddings, and Retrieval, Server, Python/Go SDKs, Rust CLI, and Web Studio

Agent Integrations, VikingBot, Deployment, and Community

Overview

OpenViking ships a layered ecosystem beyond its core Python SDK: a bot runtime (VikingBot), first-class integrations with agent hosts such as OpenClaw and Claude Code, containerized deployment artifacts (Helm chart, Web Studio), and a growing set of demo applications. This page documents those surfaces and ties them to the community topics most frequently raised (integrity, token costs, maintainer mapping, and host-version compatibility). Source: bot/README.md.

VikingBot

VikingBot is an OpenClaw-style bot built on top of the Nanobot framework and tightly integrated with OpenViking for knowledge management and memory retrieval. Source: bot/README.md.

Core Capabilities

• Dual local/remote modes — VikingBot can operate against ~/.openviking/data/ directly or against a remote OpenViking server.
• Seven dedicated OpenViking tools — openviking_read, openviking_list, openviking_search, openviking_add_resource, openviking_grep, openviking_glob, and openviking_memory_commit. Source: bot/README.md.
• Three-level content access — L0 (summary), L1 (overview), L2 (full content) are surfaced through openviking_read.
• Automatic session memory submission — Conversation history is flushed to OpenViking on a configurable window (bot.agent.memory_window). Source: bot/README.md.
• External MCP server consumption — Third-party tools registered under bot.tools.mcp_servers appear as mcp_<server>_<tool> and are auto-bound when the agent starts. Source: bot/README.md.
• Provider Registry — A single ProviderSpec table (vikingbot/providers/registry.py) drives model matching, env-var injection, and LiteLLM prefixing; adding a provider requires only two edits. Source: bot/README.md.

Skills and Demos

VikingBot ships a skill system compatible with OpenClaw's SKILL.md format. Built-in skills cover GitHub, weather, summarization, tmux, and a skill-creator. Source: bot/workspace/skills/README.md.

A reference demo, Werewolf, lives at bot/demo/werewolf/ and exercises both bot-orchestrated and human-player modes. Source: bot/demo/werewolf/README.md.

Configuration and Security

Configuration lives in ~/.openviking/ov.conf (overridable via OPENVIKING_CONFIG_FILE) under the bot key, and shares storage, server, and VLM sections with the main OpenViking process. Source: bot/README.md.

Notable security defaults:

Source: bot/README.md.

Agent Integrations

OpenClaw Plugin

The @openviking/openclaw-plugin (2026.6.18) is a pure HTTP client — it never spawns a local subprocess; an OpenViking server must already be running. Sources: examples/openclaw-plugin/package.json, examples/openclaw-plugin/README.md.

Behavior centers on three hooks:

• assemble() — rebuilds preflight history under a token budget, converts latest_archive_overview into [Session History Summary], pre_archive_abstracts into [Archive Index], then runs a tool-use/result pairing repair pass.
• afterTurn() — appends only the newly added turn, stripping injected <openviking-context> and <relevant-memories> blocks, and triggers an async commit(wait=false) once pending_tokens crosses commitTokenThreshold.
• Safety — local files are uploaded via /api/v1/resources/temp_upload; directories are zipped in JavaScript before upload; filesystem paths are never sent to the server.

Source: examples/openclaw-plugin/README.md.

Claude Code Memory Plugin

Located at examples/claude-code-memory-plugin/, this plugin provides recall + capture + commit behavior governed by environment variables. Notable knobs:

Source: examples/claude-code-memory-plugin/README.md.

Integration Mode Comparison

Deployment

Kubernetes (Helm Chart)

The chart at examples/k8s-helm/ deploys OpenViking as a Context Database MCP server on Kubernetes 1.24+ / Helm 3.8+. It supports GCP and AWS via cloud-provider-specific LoadBalancer annotations and requires a Volcengine API key for embedding and VLM services. Source: examples/k8s-helm/README.md.

flowchart LR
    A[OpenViking Server :1933] --> B[Helm Chart Deployment]
    B --> C[Persistent Volume<br/>AGFS + Vector Index]
    B --> D[Service / LoadBalancer]
    D --> E[Agent Clients<br/>VikingBot · OpenClaw · Claude Code]
    E --> F[Web Studio :5173]

Web Studio

Web Studio is a React/Vite SPA that connects to a running OpenViking Server (default http://127.0.0.1:1933). It does not embed storage or VikingBot runtime. The sessions UI requires the server to be launched with --with-bot; otherwise /bot/v1/* returns 503. Required endpoints are GET /bot/v1/health, POST /bot/v1/chat, POST /bot/v1/chat/stream, and POST /bot/v1/feedback. Source: web-studio/README.md.

Community Topics

The community context surfaces four recurring themes the integrations page must reflect:

• Integrity standards (#394) — proposal for zero-knowledge context proofs to verify delivered long-term memory; relevant to both OpenClaw and Claude Code plugins, which currently rely on server-side trust.
• Demos (#55) — request for a Memex personal-knowledge-assistant demo beyond Werewolf; skill format at bot/workspace/skills/README.md is the existing scaffold for that direction.
• Maintainer map (#1082) — module ownership and PR routing for a growing codebase.
• OpenClaw 2026.3.12 compatibility (#591) — memory-openviking plugin causes conversation hangs after upgrade; plugin lifecycle (async commit, bypass env vars) is documented in examples/openclaw-plugin/README.md and examples/claude-code-memory-plugin/README.md.
• Token & cost optimization (#744) — drives defaults like OPENVIKING_CAPTURE_MAX_LENGTH=24000 and OPENVIKING_COMMIT_TOKEN_THRESHOLD=20000. Source: examples/claude-code-memory-plugin/README.md.

See Also

• examples/basic-usage/README.md — SDK and HTTP client fundamentals.
• openviking/parse/parsers/README.md — parser pipeline that backs resource ingestion across all integrations.
• bot/README.md — VikingBot configuration, provider registry, and security defaults.

Doramagic Pitfall Log

Found 10 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

1. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/volcengine/OpenViking/issues/2757

2. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/volcengine/OpenViking/issues/2734

3. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/volcengine/OpenViking/issues/2761

4. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/volcengine/OpenViking

5. Runtime risk: Runtime risk requires verification

• Severity: medium
• Finding: Project evidence flags a runtime risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: packet_text.keyword_scan | https://github.com/volcengine/OpenViking

6. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/volcengine/OpenViking

7. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/volcengine/OpenViking

8. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/volcengine/OpenViking

9. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/volcengine/OpenViking

10. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/volcengine/OpenViking