WeKnora boundary

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

Boundary and evidence

This run examines WeKnora as the shipped knowledge system, including its own application callers, not merely its retrieval API. Its intended use is document understanding, retrieval and model-assisted work over knowledge bases. The primary target class is memory/knowledge/context-engineering system; the shipped ReAct engine is an included runtime responsibility rather than an excluded host. The boundary kind is whole-system. SRC-1, README.md, describes the three consumption modes:

Use RAG to look things up, the agent for multi-step tasks, and the wiki to organize knowledge. All three work on the same knowledge bases. --- README.md

The classification is also implementation-grounded. The server builds its own dependency container and HTTP application (SRC-1, cmd/server/main.go). Document upload stores the source file, creates a knowledge record, and enqueues document processing (SRC-1, internal/application/service/knowledge_create.go). Processing distinguishes retrieval admission from completion of enrichment (SRC-1, internal/application/service/knowledge_process.go):

knowledge.EnableStatus = "enabled" --- internal/application/service/knowledge_process.go

The scope includes the state-producing and state-consuming sides: document and URL ingestion, connector synchronization, parsing and chunking, indexes, enrichment, wiki ingestion and revision, long-term memory, stored conversations, RAG, model/tool execution, permission checks, user interfaces, SDKs, integrations, maintenance queues and evaluators. Source-native names and storage boundaries should be traced by later jobs rather than treating all retained state as one memory store.

In particular, the enclosing application belongs to this target. The agent caller supplies stored history, recalls long-term memory, installs a checkpoint sink and invokes the engine (SRC-1, internal/application/service/session_agent_qa.go). It is not legitimate to infer the absence of cross-turn persistence from inspecting the inner engine alone:

// AgentEngine is the core engine for running ReAct agents. // // History persistence note: the engine is stateless across turns. Conversation // history is rebuilt from the DB once per turn by the caller // (see service.LoadAgentHistory) and passed into Execute as llmContext. The // engine therefore does not maintain its own cache, system-prompt store, or // cross-turn buffer. --- internal/agent/engine.go

The reload path is part of the inspected boundary, not an assumed external consumer (SRC-1, internal/application/service/agent_history.go):

checkpoint := loadContextCheckpoint(ctx, messageRepo, sessionID) --- internal/application/service/agent_history.go

Memory also has application-owned write and read paths. The turn handler records explicit statements and schedules extraction; a background worker issues a model call; subsequent agent turns recall retained content into the prompt (SRC-1, internal/handler/session/qa.go, internal/application/service/memory/extract.go, internal/application/service/session_agent_qa.go). Minimum anchors for the write-to-later-consumption boundary are:

h.memoryService.ScheduleExtraction(ctx, assistantMessage.SessionID, assistantMessage.ID, assistantMessage.ModelID) --- internal/handler/session/qa.go

response, err := chatModel.Chat(ctx, []chat.Message{ --- internal/application/service/memory/extract.go

engine.SetMemoryPrompt(recall.Prompt) --- internal/application/service/session_agent_qa.go

Wiki generation and queue recovery are included maintenance responsibilities, not external authoring. The wiki worker calls a chat model; pending wiki operations have a recovery path in the container (SRC-1, internal/application/service/wiki_ingest.go, internal/container/recover_pending_wiki_tasks.go). Shipped retrieval instructions also govern consumption, including the instruction to verify underlying passages for exact evidence (SRC-1, config/prompt_templates/agent_system_prompt.yaml):

• For exact quotes, numbers, or code, verify the underlying source passage rather than relying on document metadata or a generated overview. --- config/prompt_templates/agent_system_prompt.yaml

Evaluation is in scope. The shipped evaluator drives the knowledge QA pipeline and records retrieval, reranking and response metrics. This is executable evaluation machinery, not evidence of a successful evaluation run (SRC-1, internal/application/service/evaluation.go):

err = e.sessionService.KnowledgeQAByEvent(ctx, chatManage, types.Pipline["rag"]) --- internal/application/service/evaluation.go

Frozen evidence and limits

The single evidence source is SRC-1 at 234aa948db29c10f5ed4b7939285c7b3711c5d4c; checkout HEAD was verified against acquisition. The applicability cutoff is 2026-10-15, the supplied run date. No claim concerns later revisions, live hosted deployments or the current contents of linked websites. The evidence tier is code-grounded, with repository documentation and prompts separately supporting declared intent. No target code, tests, services or model calls were executed.

External model providers, storage/database servers, Redis, parser services, sandbox providers, browsers and external MCP services are dependencies. Their shipped adapters and configuration belong to the boundary; their independently deployed internals do not. This exclusion prevents claims about provider fidelity, deployed isolation, remote durability, actual model compliance or end-to-end operational reliability. The DeepSeek Harness plugin and MCP API bridge are included shipped clients; the external runtimes consuming them are not attributed to WeKnora (SRC-1, packages/dsh-weknora/src/index.ts, mcp-server/weknora_mcp_server.py). The mini-program likewise submits source URLs and chat requests to WeKnora, rather than constituting an excluded application (SRC-1, miniprogram/utils/request.js).

There is no established source-access gap: the Git source is available. Inspection is a boundary survey, not an audit of every file. Unread implementation branches, alternate backends and platform-specific paths remain available for later jobs at this pin. They are not declared unavailable and do not justify negative capability claims. No observed execution trace or causal experiment has been established; tests and fixtures support inspection of intended checks, not observed success.

Top-level coverage

Every tracked top-level entry is classified below. Grouped rows classify each named entry identically. Included directories name material paths or responsibilities; inclusion is functional scope, not a claim that every file was read. “Survey” denotes tree or targeted source-search inspection; “read” denotes bounded source passages. There are no unavailable top-level entries. All paths in this table belong to SRC-1.

Source register