Memory Wiki Plugin: Compiled Knowledge Vault with Provenance

memory-wiki is a plugin that ships with the system and turns long-term knowledge into a browsable wiki: fixed pages, evidence-backed claims, source tracking, overview boards, and digest formats readable by machines.

It does not take over from the active memory plugin. Tasks like recall, promotion, indexing, and dreaming remain with the memory plugin you have configured (memory-core, Honcho, or others). memory-wiki works alongside it, assembling knowledge into a wiki layer that is kept current.

Turn the plugin on before you try its CLI, tools, or runtime integration:

openclaw plugins enable memory-wiki
openclaw gateway restart

A practical guideline:

• memory_search for a single wide recall sweep across whatever corpora are set up
• wiki_search / wiki_get when you need wiki-focused ranking, provenance, or belief structure at the page level
• memory_search corpus=all to cover both layers in one request, provided the active memory plugin allows corpus selection

A typical local-first arrangement uses builtin memory for recall and memory-wiki in bridge mode for stable synthesized pages. The bridge-mode example under Configuration shows this setup.

If bridge mode reports that zero artifacts were exported, the active memory plugin is not currently surfacing public bridge inputs. Run openclaw wiki doctor first, then verify that the active memory plugin exposes public artifacts.

Vault modes

• isolated (default): its own vault, its own sources, no reliance on the active memory plugin. Pick this for a standalone, curated knowledge base.
• bridge: pulls 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 touching private plugin internals.
• unsafe-local: an explicit same-machine escape hatch for local private paths. Deliberately experimental and non-portable; use only when you grasp the trust boundary and genuinely need local filesystem access that bridge mode cannot offer.

Vault mode and vault scope are two independent decisions:

• vaultMode determines where wiki inputs originate.
• vault.scope decides whether all agents share one vault or each agent receives its own child vault.

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

While bridge mode is on, it can index, controlled by the bridge.* config toggle:

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

When bridge mode is running and bridge.readMemoryArtifacts is turned on, openclaw wiki status, openclaw wiki doctor, and openclaw wiki bridge import go through the active Gateway, so they see the same active memory plugin context as agent and runtime memory. With bridge disabled or artifact reads off, those commands stay local and offline.

Vault layout

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

Managed content lives inside generated blocks; human note blocks survive regeneration untouched.

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

Open Knowledge Format imports

openclaw wiki okf import ./bundles/ga4

Bring an unpacked Open Knowledge Format bundle into wiki concept pages. This fits well when a data catalog, documentation crawler, or enrichment agent already emits OKF: keep OKF as the portable exchange format, and let memory-wiki convert it into OpenClaw-native concept pages and compiled digests.

• non-reserved .md files count as concept documents
• every imported concept needs a non-empty type frontmatter field; a missing type triggers a missing-type warning and skips the file
• unknown type values are treated as generic concepts
• index.md and log.md are reserved and never imported as concepts
• broken or external markdown links stay as they are

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 produce structured relationships entries with kind: okf-link.

Structured claims and evidence

Pages contain structured claims frontmatter rather than only unstructured text. Each claim may include id, text, status, confidence, evidence[], and updatedAt. Every evidence entry can carry kind, sourceId, path, lines, weight, confidence, privacyTier, note, and updatedAt.

As a result, the wiki functions as a belief layer instead of a passive note collection. Claims can be tracked, scored, disputed, and traced back to their sources.

Agent-facing entity metadata

Entity pages include generic routing metadata that applies to people, teams, systems, projects, or any other entity type:

• entityType: for instance person, team, system, project
• canonicalId: consistent identity key across aliases and imports
• aliases: names, handles, or labels that map to the same page
• privacyTier: arbitrary string; public counts as no-review, while any other value (such as local-private, sensitive, confirm-before-use) gets flagged in reports/privacy-review.md
• bestUsedFor / notEnoughFor: short routing hints
• lastRefreshedAt: source-refresh timestamp, distinct from page edit time
• personCard: optional person-specific routing card (handles, socials, emails, timezone, lane, ask-for, avoid-asking-for, confidence, privacy tier)
• relationships: typed edges to related pages (target, kind, weight, confidence, evidence kind, privacy tier, 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

Compile reads wiki pages, normalizes summaries, and saves a machine-facing snapshot in OpenClaw's shared SQLite plugin state. Runtime code relies on the lifecycle-owned owner snapshot to load SQLite during async prompt preparation; synchronous prompt assembly never parses Markdown or accesses cache files. Compiled output also supports first-pass wiki indexing for search/get, claim-id lookup back to owning pages, 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 clears the owner immediately; a separate compiler process requires plugin lifecycle refresh so the daemon can confirm the new durable publication. ChatGPT import rollback records post-import edits before compile and keeps their recovery paths in plugin state, so an interrupted rollback can reconcile the recovery directory and report the same preserved pages on retry. Target recovery finishes before a persisted process-restart fence. After that point, retries rebuild derived indexes, dashboards, and compiled caches without rewriting source pages or moving or deleting recovery artifacts. A later normal compile may refresh machine-managed Related blocks. This covers in-process failure and process restart after ordinary filesystem calls return. It does not guarantee write ordering across kernel or host power loss. A pathname write racing fence persistence either remains after a successful fence or is preserved under recovered/ by a pre-fence retry. Writes through a file descriptor opened before an import-owned inode is classified and unlinked are not guaranteed and may be lost. 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:

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

Three corpora: wiki, memory, all.

• wiki_search / wiki_get rely on compiled digests as the initial filter whenever feasible
• claim ids point back to the page that owns them
• contested, stale, and fresh claims affect how results are ranked
• provenance labels carry through into the final output

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

When a search hit lands on a structured claim, wiki_search includes matchedClaimId, matchedClaimStatus, matchedClaimConfidence, evidenceKinds, and evidenceSourceIds within its details payload. For text output, compact Claim: and Evidence: lines are emitted whenever they exist.

Agent tools

Beyond that, the plugin adds a non-exclusive supplement to the memory corpus, letting shared memory_search and memory_get access the wiki when the active memory plugin supports corpus selection.

Browsing the wiki in the Control UI

The Control UI offers direct browsing of the compiled wiki: head to the Memory page, then Dreams → Diary → Memory Wiki. This tab groups synthesis, entity, and concept pages, along with source and report pages that contain claims, open questions, or contradictions, showing per-page counts and a full-vault page breakdown, and opens complete page content inline. Raw sources and reports lacking that metadata still factor into the breakdown but don't appear as cards; pull them up from the Imported Insights sub-tab, which surfaces what external-history imports uncovered before promotion.

Both sub-tabs become visible once the plugin is enabled; in agent-scoped vault setups they reflect the selected agent's own vault. The UI goes through the plugin's gateway methods (wiki.overview, wiki.get, wiki.importInsights); inline page previews rely on wiki.get, the same lookup agents use through the wiki_get tool.

Prompt and context behavior

With context.includeCompiledDigestPrompt turned on, memory prompt sections gain a compact compiled snapshot drawn from plugin state: top pages only, top claims only, contradiction count, question count, confidence/freshness qualifiers. It's opt-in since it alters prompt shape; it primarily matters for context engines or prompt assembly that explicitly consume memory supplements.

Configuration

Place config 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 receives its own wiki. Within this setup, vault.path acts as a parent directory, and OpenClaw appends the normalized agent identifier:

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

The outcome is ~/.openclaw/wiki/support and ~/.openclaw/wiki/marketing. When vault.path is not specified at the agent level, the parent directory takes the default of ~/.openclaw/wiki. Consequently, the default main agent retains the current ~/.openclaw/wiki/main path.

Agent tools, compiled prompt digests, and the wiki supplement reachable via memory_search / memory_get pull the vault from the active agent context. CLI operations rely on the configured default agent unless --agent <agentId> is supplied. Gateway requests in a multi-agent environment still depend on the agentId field.

In bridge mode, an agent-scoped import only accepts a public memory artifact if its agentIds names the selected agent. Artifacts belonging to a different agent, lacking ownership metadata, or carrying an unknown owner are ignored. Global scope preserves the original shared-artifact behavior.

Warning

Adjusting vault.scope will not duplicate or divide an existing vault. At the agent level, an explicitly set vault.path turns into a parent directory, so plan to move or import current pages before switching production agents. Always back up the vault beforehand.

Per-agent vaults form a same-process knowledge boundary, not an OS-level security barrier. Plugins and unsandboxed tools with host filesystem access can still reach another agent's directory. Consider sandboxing or separate Gateway profiles when agents do not trust one another.

Example: builtin memory + bridge mode

Choose this when you want builtin memory for recall and memory-wiki for a curated knowledge base. Each layer remains focused: memory-core scans memory notes and eligible session sources, while memory-wiki assembles stable entities, claims, dashboards, and source pages.

{
  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,
          },
        },
      },
    },
  },
}

Builtin memory stays responsible for active recall, memory-wiki remains scoped to compiled pages and dashboards, and the prompt shape is left untouched until compiled digest prompts are switched on deliberately.

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 lives in 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

With vault.renderMode set to obsidian, the plugin outputs Markdown that works with Obsidian and, if you want, uses the official obsidian CLI to check status, search the vault, open a page, run a command, or jump to the daily note. None of that is mandatory; the wiki functions fine in native mode without Obsidian.

Agent-scoped vaults can still take Obsidian-friendly Markdown, but configuration validation blocks obsidian.useOfficialCli: true when vault.scope: "agent" is present. The obsidian.vaultName setting applies globally, so there is no way to assign a separate Obsidian vault per agent. Rely on the wiki tools and CLI operations instead, or run an Obsidian-managed wiki at global scope.

Recommended workflow

Keep the active memory plugin for recall

The configured memory backend keeps ownership of recall, promotion, and dreaming.

Enable memory-wiki

Begin with isolated mode unless bridge mode is something you specifically need.

Use wiki_search / wiki_get when provenance matters

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

Use wiki_apply for narrow syntheses or metadata updates

Do not manually edit managed generated blocks.

Run wiki_lint after meaningful changes

Picks up contradictions, open questions, and provenance gaps.

Turn on dashboards for stale/contradiction visibility

Configure render.createDashboards: true (the default).

Related docs

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