Most personal-memory systems begin with chunks and embeddings. OpenHuman's Memory Tree begins with a different question: how can a growing source be compressed repeatedly without losing the path back to evidence?

The result is not primarily a nearest-neighbor index. It is a hierarchical compaction engine with provenance-preserving leaves.

Bucket sealing as incremental compaction

A source is ingested into leaf nodes. Leaves accumulate in a level-zero bucket until the bucket reaches its sealing condition. The system then summarizes that bucket into a level-one node. Enough level-one summaries can in turn be sealed into a higher-level summary, producing a cascading tree.

A stale partial bucket can also be sealed. Without that rule, the tail of an inactive source would remain outside the summary hierarchy forever.

This gives the tree several useful properties:

  • updates affect a local branch instead of rewriting one global summary;
  • previously sealed nodes remain stable;
  • upper levels provide low-cost navigation;
  • original leaf spans remain available as provenance;
  • compaction work can be queued outside the interactive retrieval path.

The model performs lossy semantic compression. The tree engine constrains where that loss occurs and keeps the evidence addressable.

Retrieval is a traversal protocol

The retrieval API reflects the data structure. A caller can walk candidate nodes, drill_down into a promising branch, and fetch_leaves when it needs source-level evidence. Source queries and entity search provide additional entry points.

This is different from asking a vector store for top-k chunks and hoping they form a coherent explanation. The upper summary answers “which region of this source is relevant?” The lower leaf answers “what was actually written?” A good response should use both.

An important freshness correction is required here. Older public descriptions refer to three tree kinds: source, topic, and global. The current internal architecture says topic and global trees were removed. The active design builds source trees and uses an entity index to connect and navigate information. Treating the older three-tree diagram as current would obscure a meaningful simplification in the codebase.

Why source ownership matters

A global semantic tree is tempting because it promises one unified memory. It also makes provenance and incremental maintenance harder. Source trees preserve ownership: a meeting transcript, a document, and a note collection can each evolve without forcing one global re-clustering pass.

Cross-source retrieval can still happen through entities, but the primary hierarchy remains grounded in its source. This reduces the chance that a synthesized topic node becomes an authoritative fact without a clear origin.

The runtime boundary supports that model. OpenHuman is a React application inside Tauri, but the Rust core is authoritative. Service and domain sets own memory construction, queues, retrieval, and related state. The UI is a client of that runtime, not the owner of the memory pipeline.

For a local-first product, this matters. Closing a view should not abandon an ingestion job. A Markdown or Obsidian-facing representation should be inspectable without becoming the only source of runtime truth.

The failure mode is summary drift

Hierarchical memory does not eliminate hallucination. It can amplify it. If a level-one summary drops a qualifier, a level-two summary may confidently compress the already-distorted version.

The countermeasure is not merely a better prompt. Retrieval must be willing to descend. Product interfaces should expose the summary-to-leaf path, and evaluation should test whether an answer's final claims remain supported by leaf text.

There is also a policy question: which facts are allowed to be compressed? Names, legal constraints, medical details, or explicit user commitments may need a non-lossy lane rather than ordinary summary propagation.

Personal take

OpenHuman's design will resonate with researchers, knowledge workers, archivists, and privacy-sensitive users who want memory they can inspect and move. They do not merely want a system that “knows them”; they want to see how that knowledge was constructed.

The market opportunity is a trust interface for personal AI: source paths, summary diffs, deletion propagation, and the ability to mark memories as non-compressible or disputed. For sensitive personal data, visible provenance may become a stronger moat than another model upgrade.

My concern is that summary drift can become an invisible autobiography. The system may not invent a dramatic falsehood; it may repeatedly decide which details are worth preserving until its compressed version of a person becomes the only version consulted. Personal memory systems should allow contradictory interpretations to coexist. Human history is not a database migration toward one canonical row.

Sources