{"slug": "memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes", "title": "Memory Engineering Is a Promotion Pipeline, Not a Pile of Notes", "summary": "A developer's memory engineering system for AI assistants uses a promotion lifecycle with explicit rejection rules, treating memory like code review. The system, documented in 'ai-assistant-dot-files', requires human approval before promoting candidate records to durable knowledge, and includes expiration for stale items. The design prioritizes quality over quantity, with a YAGNI approach to retrieval infrastructure.", "body_md": "A lot of AI memory systems start with the same temptation:\n\n\"Just save the useful thing.\"\n\nThat sounds harmless until the knowledge base becomes a junk drawer. Half the notes are too specific, a few are duplicates, some are obsolete, and nobody knows which ones the agent should trust.\n\nIn `ai-assistant-dot-files`\n\n, the memory system is deliberately slower.\n\nIt uses a promotion lifecycle:\n\n`Capture -> Candidate -> Audit -> Approve -> Index -> Retrieve -> Expire`\n\nThat lifecycle is documented in `docs/runbooks/memory-engineering.md`\n\n, and the important word is not \"capture.\"\n\nIt is \"candidate.\"\n\nThe framework has a durable memory layer: Knowledge Items in `shared/knowledge/`\n\n, ADRs in `docs/adrs/`\n\n, the domain dictionary, team topology, a feature archive, and a registry at `shared/memory-registry.json`\n\n.\n\nBut a lesson from a delivery does not jump straight into `shared/knowledge/`\n\n.\n\nIt first becomes a Candidate Record.\n\nThat record has required fields:\n\nThen `memory-engineer`\n\naudits it:\n\nOnly after that does a human approve the destination.\n\nThe design is intentionally similar to code review. Durable memory changes future behavior, so they deserve a paper trail.\n\nOne of my favorite parts of the memory runbook is that it has explicit rejection rules.\n\nDo not promote a memory when it is:\n\nThat makes \"zero candidates promoted this cycle\" a healthy result, not a failure.\n\nThis is where memory engineering starts to look less like note-taking and more like gardening. The point is not to preserve every leaf. The point is to keep the soil useful.\n\nThe lifecycle also includes expiration.\n\nA Knowledge Item can become stale when the underlying code, agent, or pattern changes. It can be superseded by a better KI. Or usage analytics can show that it never appears in context manifests, which may mean it is not useful or just badly tagged.\n\nThe repo does not delete those blindly. Expired KIs move to `shared/knowledge/expired/`\n\nwith a note.\n\nThat choice matters because a wrong memory is still evidence. It tells you what the team used to believe.\n\nThere is a runbook for LightRAG integration at `docs/runbooks/lightrag-integration.md`\n\n.\n\nThere is intentionally no implementation.\n\nThat is not an omission. It is a YAGNI decision.\n\nThe current retrieval path is smaller: `search-ki`\n\nsearches Knowledge Items and ADRs; `query-memory`\n\nworks across the broader memory registry. The repo currently has 4 portable Knowledge Items, so building a bigger retrieval subsystem before the corpus needs it would add moving parts without solving an observed bottleneck.\n\nThe runbook exists so the future integration has a shape if the need becomes real.\n\nThat is the kind of \"not yet\" I trust: documented, intentional, and reversible.\n\nThe memory system fits into a larger governance model.\n\n`docs/AGENT_REFERENCE.md`\n\nlists every one of the 24 agents and names what checks its work: a structural\n\ncontract, a downstream reviewer, a human approval gate, or an aggregate metric.\n\nSome gaps are real and stated plainly. For example, `test-driven-developer`\n\ndeliberately bypasses the full review chain for speed. The doc does not pretend otherwise.\n\nThat same honesty shows up in memory.\n\nThe system does not claim every remembered thing is true forever.\n\nIt asks:\n\nThose are small questions, but they change the shape of the system.\n\nIf you are adding memory to an AI workflow, I would start here:\n\nThe hard part of memory is not remembering.\n\nIt is staying worth remembering.", "url": "https://wpnews.pro/news/memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes", "canonical_source": "https://dev.to/orieken/memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes-3eee", "published_at": "2026-07-08 00:08:10+00:00", "updated_at": "2026-07-08 00:28:44.564459+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "ai-infrastructure", "ai-research"], "entities": ["ai-assistant-dot-files", "LightRAG", "Knowledge Items", "ADRs", "memory-registry.json", "AGENT_REFERENCE.md", "memory-engineer", "test-driven-developer"], "alternates": {"html": "https://wpnews.pro/news/memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes", "markdown": "https://wpnews.pro/news/memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes.md", "text": "https://wpnews.pro/news/memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes.txt", "jsonld": "https://wpnews.pro/news/memory-engineering-is-a-promotion-pipeline-not-a-pile-of-notes.jsonld"}}