Active local-first research system
Muninn
Memory I could build on.
I built Muninn to solve a recurring problem across my projects: useful context needed to survive beyond one conversation, one session, or one model.
Keeping information was only part of the problem. I also needed to know where it came from, which project it belonged to, whether it conflicted with something newer, and when it should influence future work.
Muninn became my shared memory substrate. It gives the systems I build a way to preserve durable knowledge and recover relevant context, with explicit boundaries around scope, provenance, and the admission of new information.
Its story is closely tied to using it. Different projects place different demands on memory, and those demands expose the tradeoffs between remembering enough, retrieving too much, and carrying an old mistake forward.
Muninn has its own engineering identity because those problems deserve focused treatment. Its role in this portfolio is the memory system I built, use, and continue refining as the surrounding projects evolve.
Remembering includes provenance
Scoped records attach durable knowledge to a project or user and retain evidence references. Retrieval assembles bounded context; explicit write and admission paths keep remembering separate from choosing an action.
FRIDAY and LAILA NEXT have their own integration boundaries. Lexi’s earlier memory work contributed lessons, but its current personal memory is account-owned PostgreSQL with shared Muninn projection disabled. Muninn is not a runtime dependency of every project.
The system is used in controlled local workflows. Retrieval and migration surfaces continue to evolve; this is not a claim of a polished hosted memory service.