Reliable long-term memory
An LLM writing into durable memory is an unreliable author. It invents, mislabels, restates, and contradicts. Frona is designed for these failure modes. Its ontology memory treats model output as a proposal, not a fact. Each claim must have evidence, use ontology terms, resolve to an identity, and pass graph validation before it becomes long-term memory.
The problem is correctness, not storage
These failures need different checks. A confidence score or another summary does not handle all four:
| Failure | What it looks like | PKM safeguard |
|---|---|---|
| Invention | The model invents a plausible detail. A rolling summary then preserves it as if it were established history and feeds it back into future conversations. | Grounding verifies exact source spans and excludes memory recall from positive evidence. |
| Mislabelling | The same concept appears under several improvised types or properties. | Classification works against the effective ontology and proposes missing vocabulary explicitly. |
| Restatement | Existing knowledge returns in different words or under another name, creating duplicate claims or splitting one identity across several entities. | Identity resolution and reconciliation connect aliases, fold duplicates, and preserve one evidence-backed identity. |
| Contradiction | A new claim conflicts with established knowledge, or an old value remains current after the world changes. | Reconciliation and graph validation preserve change history and reject an incoherent patch. |
Extracted claims do not go directly into long-term memory. A claim remains a proposal until Frona finds supporting evidence, classifies it, resolves its identity, and validates the complete change.
A rolling summary can carry mistakes forward. Frona checks new claims against the existing graph. As the graph grows, it contains more identities, types, aliases, relationships, evidence, and constraints that can expose a hallucination or other mistake. This improves resilience, but it does not guarantee that every claim is correct.
Short-term and long-term memory
Two memory tiers
During a conversation, an agent can call memory_remember to append a concrete note to short memory. These notes are immediate, unstructured, and ranked by time decay when injected into later prompts.
After a chat has been idle, background consolidation processes completed messages, interleaved short memories, task lifecycle records, and qualified tool evidence. Valid claims become atomic memories attached to typed knowledge entities. Procedural memories can also become reusable playbooks.
Atomic memories and Markdown pages
Atomic memories preserve individual claims and their evidence. Knowledge entities gather those claims around people, projects, services, places, topics, and procedures. Corrections preserve what changed instead of erasing it. On top, a wiki page turns the current entity state and relevant history into readable Markdown.
Evidence and grounding
Evidence is stored per atomic memory rather than collapsed into a single confidence score. Each item records its source type, exact quote when applicable, and whether the support was explicit, derived, or inferred.
User statements
A user's message can ground a claim directly. When the user confirms the preceding agent claim, PKM retains both the confirmation and the original agent provenance.
Agent statements
Agent prose alone is not proof. It needs independent support from a user, a task lifecycle record, or a successful evidence-bearing tool execution.
Tool results
Web search, web pages, and other successful tool results can support the agent's claim. Recall tools are deliberately excluded so remembered text cannot validate itself.
External notes
Synced user notes remain read-only, searchable pages. Their extracted memories retain the note path and quoted source as evidence.
Ontology catalogue and user extension
Frona does not use a single ontology as its universal base. It starts with a linked catalogue assembled from several bundled ontologies and vocabularies. Administrators can add ontology files to that catalogue. For each user, PKM selects the relevant portion of the catalogue and composes it with a user-owned schema delta.
Bundled ontology sources
| Ontology | Bundled release | Role in PKM |
|---|---|---|
| KBpedia and KKO | 2.50 | The broad reference-concept hierarchy. The KBpedia Knowledge Ontology provides the upper-level classes and disjointness used for classification and consistency checks. |
| Schema.org | 30.0 | Everyday entity types and the primary property vocabulary for structured attributes and relations. |
| FOAF | 0.99 | People, agents, organizations, accounts, and social relationships. |
| Dublin Core Terms | 2020-01-20 | General resource metadata, description, provenance, and document relationships. |
| SKOS | 2009-08-18 | Concept schemes, preferred and alternate labels, and broader or narrower concept relationships. |
The catalogue is searchable but is not loaded wholesale into every user's reasoner. PKM closes the user's selected terms over the required hierarchy to produce a smaller effective ontology. Standard terms are reused when they fit; Assemble proposes additions to the personal schema delta only when the catalogue does not express what the graph needs.
Propose before committing
Classification operates on a virtual entity set. Proposed types and schema edits are available to later stages without leaking into the live graph.
Resolve with provenance
Temporary name-only shells may help resolve a relation target, but a provenance-backed entity wins canonical identity and unsupported shells are not materialized.
Adjudicate as a batch
Assemble sees all undeclared terms together, allowing it to declare, align, merge, restrict, amend, or defer vocabulary before one commit.
Validate the final graph
The proposed schema and instance graph are tested together. Invalid patches are repaired, deferred, or rejected; suspect facts remain preserved outside current projections.
More checks over time
Every accepted identity, type, relation, and constraint becomes another anchor for judging future proposals. The graph accumulates checks instead of accumulating unverified prose.
Identity resolution in practice
“Mercury” appears in source context that supports classifying it as a planet.
The resolver reasons over the effective ontology and provisional types. Incompatible candidates such as an element or organization are removed.
Names, aliases, attributes, and relations decide whether the surviving candidate is the same entity. Otherwise the backed candidate keeps its own identity.
How a conversation becomes knowledge
The current stage sequence is explicit. Models handle structured judgment and authorship; deterministic code validates their output, reasons over the ontology, manages checkpoints, and performs storage operations.
Any failed stage stops the pass, parks its consolidation record, and resumes at that stage after backoff. Per-item work is banked as it completes, while live dirty sets make unfinished entities visible to later passes. If the retry budget is exhausted, PKM can recover from raw contributions or abandon the pass without advancing uncommitted work.
How agents retrieve memory
PKM does not paste the whole graph into every prompt. Small, high-value context is pushed automatically; longer concept pages and playbooks are pulled only when they are relevant.
| Surface | Delivery | Purpose |
|---|---|---|
| User profile | Pushed every turn | Live account name and timezone, enriched by learned attributes from the real people/me entity. |
| Short memory | Pushed, time-decayed and capped | Recent notes that may matter before or alongside consolidation. |
| Playbook index | Pushed, usage-ordered and capped | Advertises useful procedures by name, description, and absolute path. Truncation is marked explicitly. |
| Knowledge pages | Pulled on demand | memory_search returns internal pages and read-only external notes; the general read tool opens the returned absolute path. |
| Usage signal | Recorded on citation | memory_cite increments a page's use count, which helps frequently useful pages and playbooks rank higher. |
The foreground write surface is intentionally narrow: the agent has memory_remember, memory_search, and memory_cite. It cannot edit generated pages directly. Full pages are opened with the ordinary file-reading tool.
Memory browser
Open Memory from the user menu to explore the current graph. This browser is read-only and uses the same entity, relation, ontology, and evidence records that power agent retrieval.
Graph
Nodes are colored by ontology branch. Solid arrows are asserted relations, lighter lines are inferred, and dashed links connect pages built from shared atomic memory.
Search and browse
Browse all pages or use server-ranked search. Selecting a result focuses the node and its two-hop neighborhood without discarding the surrounding graph.
Page and structure
Read the authored Markdown, then inspect ontology types and ancestors, structured attributes, and incoming or outgoing asserted and inferred relations.
Atomic memory
Inspect the claims behind a page, including kind, disposition, episode data, replacement relations, source evidence, and links back to a source chat or task when available.
Vault synchronization and recovery
Internal Memory pages are agent-owned projections. PKM stores their exact Markdown content and revision before writing the filesystem mirror. At startup, reconciliation repairs missing or misplaced files, replaces stale copies from durable content, and removes stale duplicates by stable page identity without calling a model.
Obsidian synchronization is revision-aware. Edits to internal Memory pages are translated back into memory operations such as add, supersede, outdated, or erroneous. Notes outside the managed Memory directory are indexed as external, read-only pages: Frona may search, read, cite, and extract from them, but it does not write back to those user notes.
Enable and operate PKM
Fresh installations can select PKM during setup. Existing installations remain on the basic backend until an administrator changes the memory backend. Background work uses the memory model group and falls back to primary when that group is not configured.
Consolidation makes repeated structured-output and tool-use calls. Choose a reliable, cost-effective model that follows schemas consistently; the largest model is not automatically the best operational choice.
Users can inspect the active consolidation and recent history under My Settings → Memory. Reset removes derived PKM records and the managed Memory directory. Saved chats remain available to the normal schedule, and short memories are marked for processing again. The operation is asynchronous and cannot be undone, so back up the instance first.
| Default | Value | Effect |
|---|---|---|
| Sweep cadence | 60 seconds | Checks periodically for eligible users and chats. |
| Idle threshold | 5 minutes | Avoids consolidating a conversation still in progress. |
| Concurrency | 4 | Bounds parallel chat extraction and page authoring. |
| Search results | 8 | Caps pages returned by agent memory search. |
| Short-memory half-life | 14 days | Time-decays hot notes; entries below the configured threshold leave prompt context. |
| Stage attempts | 3 | Bounds retries before checkpoint recovery or a fresh later pass. |
See the Config File Reference for the complete memory configuration and Backups before making operational changes.