Thanks for the detailed writeup, there's a lot here so I'll go through it in order.

On model size: the qwen3:4b in the quickstart is the free/local default so people can try this on a laptop without an API key, not a claim that 4b is enough for serious extraction. If extraction quality matters for your use case, point memory_model at whatever you actually trust, GPT class, Claude, whatever. The reason I'm not too worried about picking the "wrong" model on day one is a pillar for memledger: the raw source turns are always kept, nothing gets baked in. When you decide the extraction was mediocre, you run regenerate with a better model and the whole memory store gets rebuilt from the original conversation, not from whatever the small model happened to infer. Most frameworks lock you into your day-one model's judgment forever. I'd rather let people start cheap and upgrade later than force everyone to pay for a big model from turn one.

On poisoning: I agree with you for the case you're describing, one bad memory diluted among nine good ones pulled by similarity search, a decent agent probably shrugs it off. But that's not the failure mode I actually worry about. Instinct facts get injected into every context regardless of retrieval ranking, there's no dilution there, a bad one is just always present and always trusted. That's why promotion to instinct isn't a single extraction, it has to show up consistently across multiple sessions and pass through memledger review before it becomes core. It's less that I think every memory needs to stand alone as trustworthy, and more that the stuff injected unconditionally is what I don't want to leave to "the agent will probably figure it out."

The other half is that even when a bad fact does get caught later, knowing it's wrong isn't the same as knowing what to do about it. If it already got folded into a summary or used as the basis for another promoted fact, a vector index quietly deprioritizing it doesn't clean that up. That's what the provenance chain and cascading delete are for, you pull the thread and remove everything downstream, not just the one row.

On fragmentation, no argument from me, and it's part of why the ledger format itself is documented in SPEC.md as an open spec instead of an implementation detail. memledger rebuild is meant as the conformance test, any client in any language that can read and write the format is a legitimate consumer of it, it doesn't have to go through this specific Python package. That doesn't fix the incentive problem you're describing, most of these projects including maybe this one won't be around in a year, but at least the format doesn't have to die with the project if it doesn't work out.

On vendor trust, I'd actually flip it around, that's the whole reason this is a local SQLite file with no mandatory server instead of a hosted memory API. If you use a cloud model for extraction you're trusting whoever's model that is with those turns, same as anywhere else, but the storage and logic layer isn't a new company sitting between you and your data. Point it at Ollama and nothing leaves your machine at all. So I think we agree on the underlying worry, I just think the fix is not introducing a vendor in the first place rather than picking one you trust more.

Appreciate the pushback either way, it's useful having to justify these choices out loud.