Positioning¶

Readers show up asking “is this like X?” — where X is usually a chatbot memory layer, a vector database, or a wiki-plus-AI. This page answers that directly, so nobody has to infer the category from feature names.

luplo is not in the same category as any of those. It overlaps on surface (there is a store; there are embeddings; there is a query API), and the overlap is where the confusion lives. The axes below are where the difference is.

Eight axes¶

Axis	A generic AI-memory tool	luplo
Unit of storage	A fact about a user	A decision + its reasoning, made by a team
Retrieval	Vector-first (semantic search)	`tsquery` + glossary expansion first; vectors only rerank
Mutation	Facts are updated or deleted in place	Items are immutable; changes create a new row via `supersedes_id`
Relationships	Flat store; at most parent/child	Typed edges — `depends`, `blocks`, `supersedes`, `conflicts`
Graph traversal	None, or single-hop	Five-hop CTE traversal on Postgres (`lp impact`)
Contradiction detection	Current fact vs new fact only	Full decision history vs new decision
Write trigger	AI runtime writes implicitly (“I’ll remember that”)	Human writes explicitly via CLI or MCP tool call; AI reads
Time dimension	Current state only	Change history is the asset; `items_history` + `audit_log`

One-sentence contrast¶

A generic AI-memory tool remembers “this user owns a cat.” luplo remembers “on March 2nd we chose Postgres, because X, over alternative Y, and three decisions depend on this one.”

Both are valid storage shapes. They solve different problems. Mixing them into one tool produces a worse version of each.

Why the axes fall where they do¶

Every row in the table is an expression of the five refusals. The short version:

Vector-first refusal pins retrieval on tsquery. Vectors can still help — but only to reorder candidates retrieval already found, never to invent new ones.
Decision immutability refusal pins mutation on supersede-not-edit. The history is the audit trail; overwriting destroys the lesson.
Typed-and-bounded-edges refusal pins relationships on named types, and graph traversal on a five-hop ceiling. A graph that needs a layout engine to read is a model that has already lost.
Not-a-general-memory refusal pins the unit of storage on engineering decisions. User preferences, conversation history, and arbitrary facts belong in other tools.
Honesty-over-coverage (operational commitment) pins the contradiction check on “full history vs new write”, because a new decision that contradicts an old one is information the user must see before they commit it.

When luplo is the wrong tool¶

Three categories luplo is not trying to serve:

User preferences / personalization. If the thing you want to remember is “this user prefers dark mode” or “this user dismissed the tutorial”, a chatbot memory layer or a plain key-value store is the right shape. luplo’s immutability will fight you.
Document drafting / collaborative editing. A wiki or Google Docs is the right shape for “we are editing this paragraph together”. luplo stores the decisions that come out of that process, not the prose you iterated on to produce them.
Ticket queue. Linear, Jira, or GitHub Issues is the right shape for “here is a bug with a priority and an assignee”. luplo’s task item type exists for task lineage (who decided this should be done, why, what it connects to) — not for weekly sprint management.

Using luplo for these will work, but badly. The feedback loop will feel wrong: you will want to edit items it forbids you to edit, the five-hop ceiling will feel arbitrary, and the “decision + rationale” shape will feel like overhead.

When luplo is the right tool¶

The short version: when six months later somebody will ask “why is X like that?” and “what else depends on it?” — luplo is the place that answers both.

Specifically:

Small to medium engineering teams that make irreversible technical calls (framework choice, data shape, auth scheme) and need the reasoning to outlive the person who made it.
Solo developers building something durable enough that they will forget their own reasoning inside a month.
OSS projects that want a public, append-only log of why the codebase looks the way it does.