MaluDB: Long Term AI Memory
Storage is solved. Memory is not. The expensive failure is not losing the record. It is reusing knowledge without the context that made it safe.
Co-author, not repo owner
I am a named co-author on the open preprint published on Zenodo (May 2026), alongside nine other researchers. I contributed through AI Master Community working sessions on architecture and requirements brainstorming. I do not own the MaluDB repository or lead its implementation.
This case study explains the problem the paper addresses and why it matters to my work. The inspectable artifact is the preprint, not a codebase I maintain.
Systems keep the record and drop the context
Organizations already store records, documents, tickets, logs, and messages. The harder failure is reuse. When a team or an agent pulls an old number, a prior decision, or a half-remembered policy, they often lack the evidence behind it, when it was true, who was allowed to see it, why the decision was made, and how it linked to the work around it.
Humans patch around that gap with meetings and memory. AI agents make it worse: they reuse at scale, with confidence, and without a built-in habit of checking provenance, permissions, or temporal validity. The result is not just wrong answers. It is expensive mistakes that look authoritative.
A memory-native DBMS, not another document store
The preprint proposes a Memory DBMS: a database management system for long-term institutional memory shared by humans, applications, and AI agents. Instead of treating memory as search over files, it defines Memory Objects that carry the metadata required for safe reuse:
- Source links and provenance. Where a claim came from and what chain of evidence supports it.
- Temporal validity. When something was true, so stale context does not pass as current fact.
- Permissions and audit records. Who could see it, who changed it, and what was allowed at the time.
- Confidence, precision, and lifecycle state. How strong the record is, how specific it is, and whether it is draft, active, or retired.
- Workflow relationships. How a memory object connects to the decisions, tickets, and processes around it.
The paper also lays out the object model, retrieval model, security and governance requirements, implementation requirements, and an evaluation plan for a scalable Memory DBMS.
The missing memory layer can be specified concretely
For my positioning, this work demonstrates systems-level thinking at the infrastructure boundary: not prompts and demos, but the requirements for durable, governable memory in human-AI workflows. The proof is public and inspectable. Anyone can read the preprint, challenge the architecture, and see whether the specification holds up.
It also shows I can contribute to serious research collaboration and put my name on work I am willing to defend in the open, with the limits stated plainly.
Where the honesty line sits
- This is a preprint and architecture proposal, not a shipped database or production deployment.
- The paper presents an evaluation plan, not benchmark results or live performance claims.
- It is co-authored research with nine other authors. It is not a solo build and I am not the implementation lead.
- There is no public reference implementation I maintain today. The artifact you can inspect now is the paper on Zenodo.
- Judgment stays human. The design preserves provenance and permissions so people can audit what AI reuses, rather than trusting retrieval at face value.
The preprint on Zenodo
The canonical public artifact is the open-access preprint. Read it, check the claims, and decide whether the memory layer is specified tightly enough to build against.
A public GitHub implementation may follow later. Until then, this page links only to what is published and inspectable today. Start a conversation →