OpenClerk boundary

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

Boundary and evidence

OpenClerk is in scope as a memory/knowledge/context-engineering system, not an enclosing agent runtime. Its intended use is to govern coding agents' retained Markdown knowledge through a local command interface, agent instructions, citation-bearing retrieval and document lifecycle operations. Its shipped instructions serve an external model-driven agent; the absence of an enclosing model loop in the core CLI does not make this merely an unrelated Markdown utility (SRC-1, README.md, skills/openclerk/SKILL.md, docs/agent-contract.md).

OpenClerk gives coding agents a local, citation-bearing knowledge runtime over Markdown. Canonical Markdown stays the authority; generated indexes and optional modules stay derived. --- README.md

The boundary is whole-system: the shipped CLI and demo callers, runner actions, local client and SQLite storage, Chronicler session planning and context consumption, skills, optional module integration, examples, and evaluation/maintenance drivers. It is not restricted to the store API. The CLI dispatches document, retrieval, clerk, configuration and module commands; the document runner separates mutating actions from read-only requests and opens the corresponding local client (SRC-1, cmd/openclerk/main.go, internal/runner/document.go, internal/runclient/local.go).

Initial tracing covers the retained-state loop. Document creation writes canonical content, synchronizes it into derived state, and reloads the registered document. Vault synchronization scans Markdown and imports it in batches. Retrieval calls the client search API; the SQLite implementation supplies lexical search and token fallback. Chronicler consumes that retrieval for task context and passes explicit session files to artifact candidate planning. These are included shipped consumers, not excluded applications (SRC-1, internal/infra/sqlite/documents.go, internal/infra/sqlite/sync.go, internal/runner/retrieval.go, internal/chronicler/chronicler.go).

if err := s.syncDocumentFromDisk(ctx, relPath, input.Title); err != nil { return domain.Document{}, err } return s.getDocumentByPath(ctx, relPath) --- internal/infra/sqlite/documents.go

The agent-facing contract describes the larger cycle: obtain context, perform application work outside OpenClerk, then submit explicit session evidence for planning and approved document changes. This establishes the intended consumption path, not proof that a deployed agent follows the contract (SRC-1, docs/agent-contract.md).

1. Do the work outside OpenClerk.
2. After work, pass an explicit session note, handoff, or inbox artifact to the read-only openclerk clerk planning surface.
3. Apply durable writes only through approved openclerk document lifecycle APIs. --- docs/agent-contract.md

The shipped evaluation harness is included. Its driver prepares scenario state, installs a variant, builds the runner, seeds data, invokes scenario turns and verifies results, including carrying a session ID across turns. Excluding it merely because it invokes Codex would omit a shipped producer and consumer of knowledge state (SRC-1, scripts/agent-eval/ockp/codex_runner.go).

Frozen scope and limits

The evidence is the acquired repository at full commit 092fb98d243c2d9d95867ad04618ebce88983552, with applicability cutoff 2026-10-16. HEAD matched the supplied pin and the checkout had no reported changes. Overall evidence is code-grounded source inspection; no target execution, provider invocation or new experiment was performed. The source register covers the repository at that commit, not only the initially inspected files.

External dependencies include the coding-agent host and its model provider, local filesystem and SQLite implementation, optional Ollama or Gemini embedding services, and OCR tooling. Their integration code, manifests and skills belong to this boundary; external implementations, credentials, service operation and user vaults do not. This prevents conclusions about host scheduling or model reasoning, actual provider reliability/privacy behavior, OCR accuracy, or deployment-specific knowledge quality. The adapter explicitly names Ollama and Gemini and imports SQLite; the product lists its optional OCR module (SRC-1, modules/semantic-retrieval-adapter/main.go, README.md). No external source was acquired.

No required source access gap was found. Available files not yet inspected are distinguished below from deliberate exclusions. Inclusion means they remain available for later investigation at the same pin, not that all their claims or code paths have already been checked. In particular, bundled evaluations are not automatically observed-run evidence, and design documents do not establish executable behavior.

Top-level coverage

All rows refer to SRC-1 at the frozen revision. Paths in directory rows identify material responsibilities, not an evidence allowlist.

Source register