FairDecision — Branching Memory for AI Conversations

01

What Branching Memory is

Any long conversation with an AI eventually runs into the same problem: the history either stops fitting into the context window, or turns into a "wall of text" that the model has to reprocess from scratch with every message. Branching Memory solves this not by truncating or compressing history, but by changing the underlying data structure — history is stored as a branching graph, not a list of messages.

• A graph instead of a linear log
• Immutable nodes — the past is never rewritten
• Return to any point in the conversation without losing other branches
• Reduced dependence on context window size

02

Why this doesn't depend on the model race

Models change every few months — GPT, Claude, Gemini, and their future versions. We deliberately avoid binding to any specific model: a minimal interface (text in, text out) means the memory graph works the same way with today's model and with the model that will appear five years from now.

• Truncation, summarization, RAG — existing industry practices
• Context rot — a separate problem belonging to the model itself
• Switching the executing model doesn't require revisiting the memory architecture
• Future model improvements become available automatically

03

Architecture: six layers

The system is built as six coordinated layers — from the storage structure to an independent check of the graph's integrity. Each layer describes a contract between components, not a single correct implementation.

The architecture is deliberately designed around the principle of a minimal, stable interface with the executing model (text in, text out), which makes the memory graph and the integrity layer (pollinator) independent of any specific model — including hypothetical future architectures that eliminate context rot at the model level itself. This is not a compromise, but a deliberate choice favoring the longevity of the surrounding infrastructure over the fast-turning generations of executing models.

• A graph instead of a flat log — node_id, parent_id, branch_id
• Context-assembly — a path through the graph, not a time slice
• Incremental replication — offline-first, delta sync
• Visualization — a tree, navigable across branches
• Model-agnostic compute layer — a stable interface
• Integrity layer (pollinator) — checks the graph's structural integrity

04

Data security and boundaries of responsibility

The server-side store is a privileged access point to a user's aggregate history and its vector representations, and therefore requires protection at the transport and storage level. Vector embeddings are not an anonymous representation of data: existing research shows original text can be partially reconstructed from an embedding without access to the text itself.

• Secure Server SSD — an explicitly flagged zone of higher requirements
• The embedding inversion risk is named explicitly, not hidden
• Specific protective measures are left to the implementation
• Conflict resolution for offline writes — an open question

05

What remains open

The most substantive and least disclosed part of the architecture is the precise algorithm for deciding where to branch rather than continue the current thread. We deliberately don't disclose it in this publication: the question is already formulated, and work on the answer is ongoing.

• The branching-point algorithm — subject of a future publication
• Integrity-layer (pollinator) parameters are not yet fixed
• Conflict-resolution mechanism for offline writes
• Protection of embedding representations — an implementation-level concern

What Branching Memory is

Why this doesn't depend on the model race

Architecture: six layers

Data security and boundaries of responsibility

What remains open

Models will come and go. Memory will stay.