The retraction path is where this design earns its keep. Zomer's worked example starts with three observations: an attacker controls one object, that object points to a second object, and the second object is a kernel object. A rule derives that the attacker controls a kernel object [6]. The derivation is stored, not just its result. So when later debugging disproves the pointer relationship, the engine drops the conclusions that stood on it and leaves alone any conclusion a second independent path still supports, and it can print a provenance tree for either outcome [6].
That is ordinary program-analysis discipline: record facts, derive through explicit rules, track dependencies, recompute only the affected results [5]. The interesting choice is where the boundary sits. The model still reads source code, debugger output and natural-language notes; once those become structured facts, the deterministic engine owns them [5]. Temporal facts keep the history, so a primitive can be viable across one interval and invalid after a later observation, and the log answers both what is believed now and why a dead path was explored [8]. This comes from someone doing static analysis, fuzzing and binary exploitation for a living; Ubuntu credits Zomer and Alexandra Sandulescu with two speculative-execution kernel flaws, CVE-2023-0458 and CVE-2023-0459 [17].
Now the numbers, which are claims about somebody else's workload. LongMemEval and LoCoMo are conversational-memory benchmarks, not vulnerability investigations [10]. Zomer reports 0.533 F1 on LoCoMo across three runs [14]. The score closest to his stated goal is the LongMemEval knowledge-updates category at 0.579 in a representative run [12], which sits 0.116 above the project's own overall LongMemEval F1 [3]. For any of that to predict behaviour in your agent, your workload has to be question answering over chat sessions where the relevant facts are already written as sentences. A multi-hour session in a large codebase is not that; there the facts have to be pulled out of a debugger first [3].
Which is exactly what the weak result measures. Multi-session came in at 0.211 against PropMem's 0.582, roughly 36 percent of it [13][2], and Zomer traced many of the misses to extraction failures, stating the limit plainly: a perfect rule engine cannot reason over an event the LLM never converted into a fact [13]. A perfect rule engine over an empty fact table is very fast and very quiet. The same shape shows up in the inference misses, where compressing a conditional preference into a simple tuple discards the qualifier [15]. That is schema work, not engine work, and it is where the adoption time goes.
The repository is MIT-licensed and ships an MCP server, so wiring it into Claude Code or Kimi CLI is not the cost [9]. The cost is the fact schema, the rules, and the retrieval you keep running anyway, because Lemmalog holds structured facts alongside the original source text, embeddings and lexical search [16]. Zomer's framing of the split is narrower than the pitch a vendor would make here: similarity search answers which old information looks relevant, the deductive state answers which conclusions remain supported [16]. He also concedes the extraction model can still encode a bad fact, and argues the gain is that the resulting state is inspectable and corrections have mechanical consequences once the error is found [7].
In my context that is the right trade: long analysis sessions where a revived wrong belief is expensive, and where I am willing to write the rules myself. If the job is remembering what a user said three sessions ago, the published scores point elsewhere [11].
