Planned extension of Soul · March – September 2027

Soul Lineage
correctable memory for AI agents

AI assistants now remember things across weeks. When a remembered fact turns out to be wrong, you can fix that one entry. Everything the assistant concluded or did because of it stays in place and keeps being used. Soul Lineage records what was derived from what, so a correction shows exactly what needs a second look.

Design stage · not built yet Builds on Soul 4.0.2 (npm, MIT, 373 tests) Local-first · one SQLite file · no telemetry

The problem

A correction today reaches one entry. Its consequences stay.

A concrete example from a coding assistant with long-term memory:

What happens when a premise is revoked Monday a fact is remembered, Tuesday a conclusion is drawn from it, Wednesday an action is taken, Thursday the fact is corrected. Today only the fact is corrected. With Soul Lineage the conclusion and the action are flagged for review. TODAY Mon · memory "Customer runs PostgreSQL 14" Tue · conclusion "Feature X won't work, migrate" Wed · action Migration script, pull request Thu · correction "It is actually PostgreSQL 16" stays unmarked, keeps being used nobody knows it rests on the error WITH SOUL LINEAGE revoked premise "Customer runs PostgreSQL 14" doubtful · needs review "Feature X won't work, migrate" doubtful · needs review Migration script, pull request report "1 conclusion and 1 action affected" Dry run first · limits on how far doubt spreads · a person decides · nothing is deleted automatically
Today the correction replaces one entry. With lineage, what was built on the wrong premise becomes visible and goes to review.

The idea itself is old: truth maintenance systems (Doyle 1979, de Kleer 1986) withdraw conclusions when an assumption is retracted. What is new is the setting. A language model does not reliably say which facts in its context it actually used. What was delivered into the context is knowable; what was really used is not. Current memory systems for LLMs (Letta/MemGPT, Mem0, LangMem, Zep/Graphiti) store and retrieve, and some expire facts over time, but none records which memory went into which conclusion or action.

What exists today

The foundation is shipped and tested. The propagation does not exist.

Soul is a local-first memory server for MCP clients such as Claude Code, Claude Desktop, Cursor and Windsurf. On npm since February 2026, seven releases, MIT licensed, used daily by its author.

CapabilitySoul 4.0.2Note
Provenance per memoryyessource type, confidence and status on every entry
Contradictions made visibleyesdisputed pairs instead of silent overwrites
Correction links what it replacesyessingle step only (supersedes)
Log of which memories went into which contextyeskept 90 days today, for retrieval measurement
Runs, receipts and episodes for executed workyesreceipts are self-attested, and say so
Link from a context to what was produced in itnothe missing edge
Revocation that reaches dependent conclusions and actionsnothe planned work

Quality evidence in the repository: 373 tests, coverage thresholds enforced in CI on Node 20, 22 and 24, a smoke test against the real packed tarball, five SIGKILL crash tests, migration and restore probes, a threat model, and a README section called "What Soul is not".

What will be built

Three pieces, in the open

1 · capture

Dependency edges

When something is stored or run in a context, Soul records which memories were delivered into that context. Clients can also declare the premises they used. Edges carry their kind: retrieved, declared or confirmed.

2 · revoke

Bounded doubt

Revoking or correcting a memory starts with a dry run that shows the affected set. Reachable conclusions and actions are marked doubtful within policy limits and go to the review queue. Marks resolve when the premise is confirmed or retracted.

3 · share

Open specification

The edge schema and propagation rules are published separately from the code (CC-BY), so other memory systems can implement them. A small preregistered benchmark is published whatever the result.

Timeline

MilestoneContentDone by
M1Written specification, additive schema migration behind the existing backup gateApril 2027
M2Automatic capture of dependency edges, links from contexts to runs and episodesMay 2027
M3Revocation, traversal, doubt marks, conservative default policyJuly 2027
M4MCP tools ("what depends on this?", revoke with dry run), scale and crash tests up to about one million edgesAugust 2027
M5Small benchmark with two model families, Soul 5.0 release, specification v1.0September 2027

About 450 hours, done by one person alongside a full-time job, the same way Soul was built so far.

Honest limits

What this will not claim

  • Retrieved is not the same as used. Edges from delivery are a superset of true dependencies. That errs on the safe side, but it over-marks. Finding out what a model really relied on is a research question; this phase measures it only in a small benchmark.
  • Doubt can spread too far. That is why every revocation starts as a dry run, propagation has limits, and nothing is deleted automatically.
  • No quality claim before measurement. Soul's README still says no model benchmark results exist yet. That sentence changes only when a preregistered measurement exists, including if the result is negative.
  • Not built yet. This page describes a plan. Nothing here is released until it is on npm and in the repository.

Who

Christian Bucher

Self-taught developer in Vienna. I built and maintain Soul alone, in the evenings and on weekends next to a full-time job, and start university (business informatics) in autumn 2027. I use AI coding assistants as tools and remain responsible for architecture, tests, review and releases.

Soul on GitHub · npm · Roadmap · About (English) · christian140903@gmail.com