Mimir
“I remember everything—except why we thought naming the index after memory would prevent cache invalidation.”
Mimir is Pantheon Blueprint's architectural knowledge role, not a chatbot or single product. It closes two distinct gaps: AFFiNE keeps accepted durable knowledge human-readable as the canonical record, while Mem0 provides semantic retrieval from a disposable index without making search results authoritative. A controlled indexer derives Mem0 entries only from accepted AFFiNE revisions. This is a reference design: the required adapters and controls must be validated before a deployment relies on them.
At a glance
| Property | Description |
|---|---|
| Function | One knowledge role: human-readable canonical knowledge plus semantic retrieval |
| Reference tool(s) | AFFiNE fills the canonical-record gap; controlled indexing derives Mem0, which fills the semantic-retrieval gap |
| Authority | AFFiNE is the authoritative canonical record; Mem0 is disposable, rebuildable, and has no independent authority |
| Trust zone | Trusted knowledge |
What Mimir does
AFFiNE holds accepted, human-readable knowledge, including its canonical revisions. The controlled indexer derives Mem0 entries only from those accepted revisions. Mem0 is therefore a disposable semantic retrieval index: it helps find relevant material and can be erased and rebuilt from canonical content, but it is not a second source of truth.
Mimir organizes canonical knowledge with a hybrid Mimir knowledge model: a Capacities-inspired conventional object model starts with exactly seven primary types: Project, Area, Person/Organisation, Topic, Decision, Source, and Procedure. PARA-like dashboards are navigation views rather than exclusive folders. Canonical entity pages pair GBrain-style rewritable current understanding and state with an append-only evidence timeline, while LLMWiki-style synthesis is used only for research ingestion.
For an important claim, Ody first retrieves candidate references from Mem0 and then reads the corresponding canonical AFFiNE content. If AFFiNE and Mem0 disagree, AFFiNE wins. This retrieval flow and the source metadata expected of the index are described in the architecture and Mimir search contract.
How Mimir interacts
Ody requests Mimir operations through Heimdall, which applies the caller, classification, and tool policy before a permitted search or canonical read. Mem0 returns references and relevance, while AFFiNE supplies the canonical content used in material answers; Heimdall mediates access to both rather than making either component an autonomous agent.
Muninn reviews durable conversation material and proposes provenance-bearing candidates or drafts through Heimdall; acceptance remains subject to the applicable review policy before AFFiNE becomes canonical. Huginn only stages untrusted external evidence and cannot directly promote that material into canonical knowledge. Once a revision is accepted in AFFiNE, the controlled indexer may update Mem0 from it; neither Muninn nor Huginn writes directly to the retrieval index as an authority source.
What Mimir does not do
Mimir does not treat indexed excerpts, relevance scores, or external captures as canonical facts. It does not let Mem0 authorize AFFiNE writes, and it does not let agents bypass Heimdall for general knowledge operations. It also does not silently replace, delete, or supersede canonical knowledge; those changes require the applicable review or retention policy.
Readiness
Use the central readiness and assurance model for Mimir's gates, maturity claims, and evidence expectations. Durable knowledge, recoverability, and access controls are defined in the Mimir knowledge model, backup model, and security model.