Memory Wiki: Compiled Knowledge Vault with Provenance and Dashboards

memory-wiki is a preinstalled plugin that turns persistent knowledge into a browsable wiki: deterministic pages, structured claims backed by evidence, provenance tracking, dashboards, and machine-readable summaries.

It does not take over the active memory plugin. Recall, promotion, indexing, and dreaming remain managed by whatever memory backend is in use (memory-core, QMD, Honcho, and so on). memory-wiki runs alongside it and assembles knowledge into a maintained wiki layer.

Activate the plugin before using its CLI, tools, or runtime integration:

openclaw plugins enable memory-wiki
openclaw gateway restart

Practical rule:

• memory_search for one broad recall pass across whatever corpora are configured
• wiki_search / wiki_get when you want wiki-specific ranking, provenance, or page-level belief structure
• memory_search corpus=all to span both layers in one call, when the active memory plugin supports corpus selection

A common local-first setup: QMD as the active memory backend for recall, and memory-wiki in bridge mode for durable synthesized pages. See the QMD + bridge mode example under Configuration.

If bridge mode reports zero exported artifacts, the active memory plugin is not currently exposing public bridge inputs. Run openclaw wiki doctor first, then confirm the active memory plugin supports public artifacts.

Vault modes

• isolated (default): own vault, own sources, no dependency on the active memory plugin. Use this for a self-contained curated knowledge store.
• bridge: reads public memory artifacts and event logs from the active memory plugin through public plugin SDK seams. Use this to compile the memory plugin's exported artifacts without reaching into private plugin internals.
• unsafe-local: explicit same-machine escape hatch for local private paths. Intentionally experimental and non-portable; use only when you understand the trust boundary and specifically need local filesystem access bridge mode cannot provide.

Vault mode and vault scope are separate choices:

• vaultMode chooses where wiki inputs come from.
• vault.scope chooses whether all agents use one vault or each agent gets a child vault.

vault.scope: "global" is the default and preserves the existing single-vault behavior. Use vault.scope: "agent" with isolated or bridge mode when agents must not share wiki pages, compiled digests, search results, or writes. Agent scope cannot be combined with unsafe-local mode because those configured private paths are not agent-owned inputs. Configuration validation rejects this combination.

Bridge mode can index, per bridge.* config toggle:

• exported memory artifacts (indexMemoryRoot)
• daily notes (indexDailyNotes)
• dream reports (indexDreamReports)
• memory event logs (followMemoryEvents)

When bridge mode is active and bridge.readMemoryArtifacts is enabled, openclaw wiki status, openclaw wiki doctor, and openclaw wiki bridge import route through the running Gateway so they see the same active memory plugin context as agent/runtime memory. If bridge is disabled or artifact reads are off, those commands keep local/offline behavior.

Vault layout

<vault>/
  AGENTS.md
  WIKI.md
  index.md
  inbox.md
  entities/
  concepts/
  syntheses/
  sources/
  reports/
  _attachments/
  _views/
  .openclaw-wiki/

Managed content stays inside generated blocks; human note blocks are preserved across regeneration.

• sources/: imported raw material and bridge/unsafe-local-backed pages
• entities/: durable things, people, systems, projects, objects
• concepts/: ideas, abstractions, patterns, policies (also the landing spot for OKF imports)
• syntheses/: compiled summaries and maintained rollups
• reports/: generated dashboards

Open Knowledge Format imports

openclaw wiki okf import ./bundles/ga4

Import an unpacked Open Knowledge Format bundle into wiki concept pages. Good fit when a data catalog, documentation crawler, or enrichment agent already produces OKF: keep OKF as the portable exchange artifact, let memory-wiki turn it into OpenClaw-native concept pages and compiled digests.

• non-reserved .md files are concept documents
• each imported concept requires a non-empty type frontmatter field; missing type produces a missing-type warning and the file is skipped
• unknown type values are accepted as generic concepts
• index.md and log.md are reserved and never imported as concepts
• broken or external markdown links are left unchanged

Imported pages flatten under concepts/ so existing compile, search, get, and dashboard flows see them without a second wiki tree. Each page keeps the original OKF concept ID, source path, type, resource, tags, timestamp, and full producer frontmatter. Internal OKF links rewrite to the generated wiki concept pages and also emit structured relationships entries with kind: okf-link.

Structured claims and evidence

Pages contain structured claims frontmatter rather than being purely freeform text. Each claim may incorporate id, text, status, confidence, evidence[], and updatedAt. Each evidence entry can hold kind, sourceId, path, lines, weight, confidence, privacyTier, note, and updatedAt.

This design turns the wiki into a belief layer instead of a passive collection of notes. Claims can be tracked, scored, challenged, and traced back to their sources.

Agent-facing entity metadata

Entity pages carry generic routing metadata suitable for people, teams, systems, projects, or any other entity type:

• entityType: for instance person, team, system, project
• canonicalId: a stable identity key that works across aliases and imports
• aliases: names, handles, or labels that all resolve to the same page
• privacyTier: an arbitrary string; public means no review is needed, while any other value (like local-private, sensitive, confirm-before-use) gets flagged in reports/privacy-review.md
• bestUsedFor / notEnoughFor: compact routing hints
• lastRefreshedAt: a timestamp for source refresh, separate from the page edit time
• personCard: an optional person-specific routing card containing handles, socials, emails, timezone, lane, ask-for, avoid-asking-for, confidence, and privacy tier
• relationships: typed edges pointing to related pages, including target, kind, weight, confidence, evidence kind, privacy tier, and note

For a people wiki, begin with reports/person-agent-directory.md, then open the person page using wiki_get before relying on contact details or inferred facts.

Entity page example

pageType: entity
entityType: person
id: entity.example-person
canonicalId: maintainer.example-person
aliases:
  - Alex
  - example-handle
privacyTier: local-private
bestUsedFor:
  - Example ecosystem routing
notEnoughFor:
  - legal approval
lastRefreshedAt: "2026-04-29T00:00:00.000Z"
personCard:
  handles:
    - "@example-handle"
  socials:
    - "https://x.example/example-handle"
  emails:
    - alex@example.com
  timezone: America/Chicago
  lane: Example ecosystem
  askFor:
    - Example rollout questions
  avoidAskingFor:
    - unrelated billing decisions
  confidence: 0.8
  privacyTier: confirm-before-use
relationships:
  - targetId: entity.other-person
    targetTitle: Other Person
    kind: collaborates-with
    confidence: 0.7
    evidenceKind: discrawl-stat
claims:
  - id: claim.example.routing
    text: Alex is useful for example-ecosystem routing.
    status: supported
    confidence: 0.9
    evidence:
      - kind: maintainer-whois
        sourceId: source.maintainers
        privacyTier: local-private

Compile pipeline

The compile step reads wiki pages, normalizes summaries, and stores a machine-readable snapshot in OpenClaw's shared SQLite plugin state. At runtime, the lifecycle-owned owner snapshot loads SQLite during async prompt preparation; synchronous prompt assembly never parses Markdown or reads cache files. Compiled output also supports first-pass wiki indexing for search and retrieval, claim-id lookups back to the owning page, compact prompt supplements, and report generation.

Source edits and vault restores become machine-facing only after the next compile. Restarting or refreshing the plugin lifecycle compares the vault's causally chained compile publication with SQLite and rejects a snapshot from a newer, rolled-back state. A compiler that started before the rollback cannot publish against the restored predecessor. Prompt preparation does not poll the vault or install file watchers. After rollback quarantine, a compile in the running process immediately clears the owner; a separate compiler process requires a plugin lifecycle refresh so the daemon can confirm the new durable publication. Compiled caches are rebuildable: cache rows from before publication epochs are treated as misses and replaced by the next compile; they are not migrated.

Dashboards and health reports

When render.createDashboards is enabled, compile maintains dashboards under reports/:

Search and retrieval

Two search backends are available:

• shared: use the shared memory search flow when it is available
• local: search the wiki locally

Three corpora exist: wiki, memory, all.

• wiki_search / wiki_get use compiled digests as a first pass when possible
• claim ids resolve back to the owning page
• contested, stale, and fresh claims influence ranking
• provenance labels survive into results

Search modes (--mode / tool mode param):

When a result hits a structured claim, the details payload from wiki_search contains matchedClaimId, matchedClaimStatus, matchedClaimConfidence, evidenceKinds, and evidenceSourceIds. If available, the text output adds compact Claim: and Evidence: lines.

Agent tools

The plugin also registers a non-exclusive memory corpus supplement, so shared memory_search and memory_get can reach the wiki when the active memory plugin supports corpus selection.

Prompt and context behavior

With context.includeCompiledDigestPrompt turned on, memory prompt sections append a compact compiled snapshot drawn from plugin state: only top pages, only top claims, contradiction count, question count, confidence and freshness qualifiers. This is opt-in because it changes prompt shape; it mainly matters for context engines or prompt assembly that explicitly consume memory supplements.

Configuration

Place configuration under plugins.entries.memory-wiki.config:

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "isolated",
          vault: {
            scope: "global",
            path: "~/.openclaw/wiki/main",
            renderMode: "obsidian",
          },
          obsidian: {
            enabled: true,
            useOfficialCli: true,
            vaultName: "OpenClaw Wiki",
            openAfterWrites: false,
          },
          bridge: {
            enabled: false,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },
          unsafeLocal: {
            allowPrivateMemoryCoreAccess: false,
            paths: [],
          },
          ingest: {
            autoCompile: true,
            maxConcurrentJobs: 1,
            allowUrlIngest: true,
          },
          search: {
            backend: "shared",
            corpus: "wiki",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true,
          },
        },
      },
    },
  },
}

Key toggles:

Per-agent vaults

Assign vault.scope the value agent so each configured agent gets its own wiki. In this configuration, vault.path acts as a parent directory, and OpenClaw appends the normalized agent identifier:

{
  agents: {
    list: [{ id: "support" }, { id: "marketing" }],
  },
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          vault: {
            scope: "agent",
            path: "~/.openclaw/wiki",
          },
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
          },
        },
      },
    },
  },
}

This results in ~/.openclaw/wiki/support and ~/.openclaw/wiki/marketing. When vault.path is not specified at the agent level, the parent directory uses ~/.openclaw/wiki by default. The main agent thus retains the existing ~/.openclaw/wiki/main path.

Agent tools, compiled prompt digests, and the wiki supplement exposed through memory_search / memory_get resolve the vault from the currently active agent context. For CLI and Gateway calls in a multi-agent setup, explicitly pass the agent with openclaw wiki --agent <agentId> ... or include it in the Gateway request's agentId. If only one agent is configured, it is used as the default when no identifier is supplied.

In bridge mode, agent-scoped imports accept a public memory artifact only when its agentIds includes the selected agent. Artifacts belonging to another agent, those lacking ownership metadata, or those with an unknown owner are ignored. Global scope retains the existing shared-artifact behavior.

Warning

Switching vault.scope does not copy or split an existing vault. In agent scope, an explicitly configured vault.path becomes a parent directory, so move or import existing pages deliberately before switching production agents. Back up the vault first.

Per-agent vaults provide a same-process knowledge boundary, not an operating-system security boundary. Plugins and unsandboxed tools with host filesystem access can still read another agent's directory. Use sandboxing or separate Gateway profiles when agents do not trust each other.

Example: QMD + bridge mode

Use this approach when you want QMD for recall and memory-wiki for a curated knowledge layer. Each layer stays focused: QMD keeps raw notes, session exports, and extra collections searchable, while memory-wiki compiles stable entities, claims, dashboards, and source pages.

{
  memory: {
    backend: "qmd",
  },
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },
          search: {
            backend: "shared",
            corpus: "all",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
        },
      },
    },
  },
}

This arrangement leaves QMD responsible for live memory recall, memory-wiki dedicated to compiled pages and dashboards, and the prompt template unchanged until compiled digest prompts are deliberately turned on.

CLI

openclaw wiki status
openclaw wiki doctor
openclaw wiki init
openclaw wiki ingest ./notes/alpha.md
openclaw wiki compile
openclaw wiki lint
openclaw wiki search "alpha"
openclaw wiki get entity.alpha
openclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alpha
openclaw wiki bridge import
openclaw wiki obsidian status

The complete command reference is available at CLI: wiki, covering wiki okf import, wiki apply metadata, wiki unsafe-local import, wiki chatgpt import / wiki chatgpt rollback, and the entire wiki obsidian subcommand set.

Obsidian support

When vault.renderMode is set to obsidian, the plugin produces Markdown compatible with Obsidian and can optionally use the official obsidian CLI to check status, search the vault, open a page, run a command, or jump to the daily note. This feature is not required; the wiki functions in native mode without Obsidian.

Agent-scoped vaults can also use Obsidian-friendly Markdown, but configuration validation blocks obsidian.useOfficialCli: true when paired with vault.scope: "agent". The current obsidian.vaultName setting applies globally and cannot assign a separate Obsidian vault per agent. Instead, rely on the wiki tools and CLI operations, or keep a wiki managed by Obsidian in the global scope.

Recommended workflow

Keep the active memory plugin for recall

Recall, promotion, and dreaming remain under the control of the configured memory backend.

Enable memory-wiki

Begin with isolated mode unless bridge mode is specifically needed.

Use wiki_search / wiki_get when provenance matters

Choose these over memory_search when you need ranking specific to the wiki or a belief structure at the page level.

Use wiki_apply for narrow syntheses or metadata updates

Do not manually edit blocks that are generated and managed.

Run wiki_lint after meaningful changes

Identifies contradictions, unresolved questions, and gaps in provenance.

Turn on dashboards for stale/contradiction visibility

Use render.createDashboards: true (the default).

Related docs

• Memory Overview
• CLI: memory
• CLI: wiki
• Plugin SDK overview