I built an AI memory engine in 10 days, then needed a project to prove it works

Hi, questions for you (perhaps they help guide a revamp of your marketing):

1) what benefits are there to my AI's memory having the property of being able to prove, cryptographically, what was stored and when? My first reaction is that this sounds like something that is probably expensive to achieve but that I don't intuitively grok the benefits of.

2) why should I allow you to decide the type system of my knowledge, and how flexible is your system to the possibility that you've got it wrong and this typeset is not the right design?: "Types include: fact (stable truths), state (mutable context), event (dated milestones), procedure (proven workflows and corrections), relation (links between concepts), domain, and task."

3) RE: "Session bootstrap is a single MCP tool call — memory_session_bootstrap — that loads relevant atoms, active procedures, Markov predictions, and conflicting facts at the start of every session. You pass your objective and it returns a pre-ranked, token-budgeted context block. Bootstrap uses both Markov arcs and knowledge graph edges for scoring" - it seems like bootstrapping sessions can be a very preference-based, personalized thing, in other words - different developers have a different opinion about what matters. Unless you can prove that your bootstrap methodology achieves some higher benchmark than any random person off the street's bootstrap technique/instructions to an agent, then I find it hard to trust this and want to pay for it over just writing my own agent instructions and triggering them with a CLI command or alias.

Hi HN, entityone here. Short version of how this exists: I was pair-programming with an LLM and got tired of re-explaining the same context every morning. So I spent about ten days building it a memory. Atoms (named, versioned strings) hashed into a SHA-256 Merkle tree, an RFC 6962 consistency proof so I could verify the tree evolved honestly, and a Prediction-by-Partial-Matching model over the recall sequence so it pre-fetches the next atom before I ask. Sub-millisecond recall. I was very pleased with myself. Then I hit the problem that is, in hindsight, extremely funny: I had built a memory system and had nothing to remember. A proof of honesty over an empty tree proves nothing. You cannot evaluate a memory substrate on a toy. It needs a real project with real bugs, real corrections, real state that changes under you and lies to you. So I built one. The "test harness" turned into an actual SaaS — billing, provisioning, DigitalOcean orchestration, the works — written almost entirely with the same AI, using the ten-day memory engine as its long-term memory the entire time. Roughly eight months. The product became the experiment. The experiment became the product. I am aware this is backwards. A few things I did not expect: corrections become durable (the first time I told it "ask, don't guess," it stored that as a procedure and it's loaded on every session since); bug shapes are retrievable (a three-hour crash-loop debug is now one atom it reaches for first); and the compounding is real but slow — marginal for a few weeks, then around 200–300 atoms it flips and sessions start with it already knowing what I'd have re-explained. It's MCP-native (Claude, Cursor, Cline connect with no SDK), there's a REST API, and a 3D Merkle-tree visualiser because I wanted to watch the proofs. Honest limitations: the 64% Markov next-atom hit rate is measured on my own sessions — yours will differ, and I'd like more external numbers. It's single-tenant by design (your own substrate), so no shared-corpus magic across customers. And the discipline is on the human: it only knows what you bother to make it remember. Repo: github.com/wjm2202/Parametric-Memory. Happy to get torn apart in the comments — the Merkle and PPM internals are the fun part to argue about.

Months of working with this second brain has proven to me this needs to be shared with the world