{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaz76p6detgcjbe3lwhedx6auz3ds46m542p2jjf3i4kvo6bwuane",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3ml6isu45teg2"
  },
  "path": "/t/spiralbase-memory-landscapes-efficient-recall-and-spiral-cortex/175778#post_1",
  "publishedAt": "2026-05-06T09:01:30.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "SPIRALbase, Part 2: A Working Memory for the Landscape",
    "SPIRALbase, Part 3: SPIRAL Cortex and Policy-First Memory"
  ],
  "textContent": "I just published Part 3 of the SPIRALbase series. The broader theme is memory as a landscape not only as lookup.\n\nPart 1 introduced SPIRALbase as an associative memory landscape: memory is not just a list of stored chunks, but a structured terrain where a query can settle near related traces. Part 2 added a working-memory layer: something that can hold, protect, bridge, and release parts of that landscape without rewriting the whole system. See articles in the end of this post for further information.\n\nPart 3 asks what this could look like inside a larger AI stack. The basic idea is a division of labour:\n\n  * exact retrieval finds literal files, documents, tests, and references\n  * SPIRALbase / Hybrid-J supplies associative recall by proximity in the memory landscape\n  * a policy or agent proposes the action\n  * SPIRAL Cortex gates and arbitrates when memory is allowed to influence that action\n  * trace export makes the route auditable afterwards.\n\n\n\nOne motivation is efficiency. In the companion essay, I sketch the intuition that a tuned memory landscape should not need to re-read every stored token every time it recalls something. A query should be able to enter the landscape and settle into the relevant region. The numerical comparisons there are analytical estimates, not benchmark claims, but they point to the architecture I am trying to build: memory that grows in depth without making every recall proportionally heavier.\n\nThe concrete use case in this article is software development. A coding agent may fix the visible failing test but miss a hidden subsystem obligation. In the current SWE-bench protocol-gap experiments, same-subsystem semantic memory can sometimes supply that missing convention, while wrong-memory and lesion controls stay inert.\n\n## Discussion\n\nI would be especially interested in discussion around the broader framing:\n\n  * Does “memory as a landscape” seem like a useful alternative to context-window accumulation?\n  * Is software development a good first use case for testing associative recall plus exact retrieval?\n  * What would make the energy/recall-efficiency argument convincing as an empirical benchmark rather than an analytical estimate?\n  * What should a small public reproduction bundle include?\n\n\n\nThis is a research intro, not a model-release claim. The goal is to make memory systems more inspectable: what was retrieved, why it mattered, whether it changed the answer, and whether the effect disappears when the memory path is lesioned.\n\nAnyways, thank you for reading this far.\n\nBest regards,\nRobin\n\n## Articles\n\n[1] [SPIRALbase, Part 2: A Working Memory for the Landscape]( SPIRALbase, Part 2: A Working Memory for the Landscape ). Hugging Face.\n\n[2] [SPIRALbase, Part 3: SPIRAL Cortex and Policy-First Memory](SPIRALbase, Part 3: SPIRAL Cortex and Policy-First Memory)",
  "title": "SPIRALbase: memory landscapes, efficient recall, and SPIRAL Cortex"
}