Memory on Programmer.ie: Modern AI programming

What Remembering Means

Mon, 14 Sep 2026 05:00:01 +0100

Consider a small software team and the assistant that sits alongside it. In June the team spends a week arguing about where to keep its event log. Someone tries keeping it in SQLite. The prototype works, then slows down under concurrent writes. The team decides to move the event store to PostgreSQL, recording the decision as adr-007 on 11 July. By August nobody thinks about this any more; it is just how the system works.

The Measurement Instrument

Mon, 14 Sep 2026 05:00:02 +0100

Chapter 1 defined memory behaviourally: the past must change what the system does now, ideally improving it. This chapter defines how that claim is measured. The distinction matters from the first paragraph, because the word “instrument” will recur throughout the book and it never means the memory architecture. The memory system is one product of this book. The Memory Measurement Instrument — the apparatus used to determine whether that system remembers — is the other.

The RAG Baseline

Mon, 14 Sep 2026 05:00:03 +0100

The October contributor from Chapter 1 asks for a second service with its own event log. The July decision is still in the repository. So are the contention report, the benchmark, the earlier SQLite setup, and a great deal of discussion that no longer matters to this task. Before inventing a new kind of memory, there is an obvious possibility to test: find the useful parts of that history and let a capable model read them.

From Retrieval to Persistent Understanding

Mon, 14 Sep 2026 05:00:04 +0100

Chapter 3 built the strongest conventional retrieval the book could assemble and left it standing. That result constrains this chapter before it begins. Any claim of the form retrieval finds text but does not understand it would be false about the system Chapter 3 actually built: a hybrid retriever, a cross-encoder reranker, and a capable reader already perform substantial interpretation at query time. The reader distinguishes proposals from decisions when the passages allow it, follows rationale across artifacts, and abstains when evidence runs out. That is understanding, deployed per query and discarded afterwards.

Pathways Through Memory

Mon, 14 Sep 2026 05:00:05 +0100

Chapter 4 set out to give the system a map. Instead of reconstructing meaning from raw passages at every query, it keeps interpretation: entities, relationships, claims, communities, each traceable back to the artifact it came from. Whether that map pays for itself is Chapter 4’s own question and Chapter 4’s own experiment; nothing here assumes its verdict.

This chapter asks a question that arises either way. Suppose the map exists. A map is a structure to search. Remembering is not a search — or at least, human remembering does not feel like one. Something occurs to you, and something else follows from it, and the thing you needed arrives three steps later by a route you did not plan.

The Memory Nexus

Sat, 19 Sep 2026 05:00:06 +0100

Chapters 3 through 5 leave the system with an embarrassment of options. Chapter 3 built hybrid retrieval over raw history with reranking. Chapter 4 added a persistent derived graph with several query modes. Chapter 5 added cue-conditioned associative propagation over that graph. Each chapter earned its mechanism conditionally, and each left the cheaper layers available underneath. The question none of them answers is the one a deployed system meets first:

Why

Sat, 19 Sep 2026 05:00:07 +0100

Chapters 3 through 6 leave the system with a working pipeline and an uncomfortable surplus. Chapter 3 retrieves raw history. Chapter 4 derives a persistent graph from it. Chapter 5 propagates activation across that graph. Chapter 6 chooses between these mechanisms. A candidate memory reaches the reader, the reader writes an answer, and the answer contains claims about the project. This chapter asks the book’s third question — why did we decide or believe this? — in the form the pipeline forces:

Is It Still True?

Mon, 14 Sep 2026 05:00:08 +0100

The same events, a different story

Consider three remembered events from the migration history:

A = benchmark detects SQLite contention
B = team decides to adopt PostgreSQL
C = PostgreSQL deployment completes

As an unordered set, {A, B, C}, the system knows all three happened. As a trajectory, A → B → C, it can say something stronger: the benchmark preceded the decision, and the decision preceded the deployment. Now hold the contents constant and change only the ordering to B → A → C. Nothing was added and nothing was removed, yet the benchmark can no longer have motivated the decision. It may corroborate the decision, strengthen confidence in it, or justify retaining it — but a later measurement cannot have been the reason for an earlier choice.

What Did We Leave Unfinished?

Mon, 14 Sep 2026 05:00:09 +0100

Chapter 8 closed the first half with a system that maintains belief through time. That system is a good historian. This chapter shows it is a poor colleague. A historian answers questions about the past. A colleague knows what the past left undone — and the system as built so far cannot tell a closed chapter from an open obligation.

The migration is finished. The work is not.

Extend the running migration history past the July decision:

What Matters Right Now?

Mon, 14 Sep 2026 05:00:10 +0100

Chapter 9 finished the first arc. Seven layers now stand between raw history and an answer: retrieval, a persistent graph, associative pathways, routing, support lineage, temporal validity, open-loop status. Each earned its place against the failure class it claimed to fix. None has been asked the question that decides whether any of it was worth building.

A context window is small and history is not. Every turn, something chooses which fraction of the past the model is allowed to see. So far that choice has been made by one mechanism: similarity to the words of the request. The enrichment of Chapters 4 to 9 sits behind that gate, and a gate that only understands wording cannot use it.

Consequences Nobody Wrote Down

Mon, 14 Sep 2026 05:00:11 +0100

Chapter 9 handles work the history states: promises, assignments, follow-ups with an established expectation behind them. This chapter pushes Question 5 past conventional task tracking, to consequences nobody wrote down. The migration broke assumptions encoded in fixtures, documentation, and configuration that no session mentions. A memory that tracks only stated intentions will report the open list as empty while the project quietly rots. Whether anything can be done about that — reliably, without inventing obligations — is treated here as a difficult hypothesis, not a capability.

Does Better Context Change Behaviour?

Mon, 14 Sep 2026 05:00:12 +0100

Chapter 1 defined memory behaviourally: remove the past, rerun the present task, and ask whether behaviour changed and whether the change was an improvement. Eleven chapters later, that test has never actually been run. Chapters 3 to 11 built a pipeline — retrieval, structure, association, routing, lineage, temporal state, open loops, frames, derived consequences — and measured each stage against ledgers of what the context contains. During development, a later assembly experiment, reported in Chapter 14, exposed the measurement anomaly that motivates the behavioural experiment reported here: at a 768-token budget the assembled context holds required-evidence recall of only 0.72 yet the reader answers at 0.955 key-claim coverage, better than the full raw context at 0.879. Either the ledger overstates what the task needs, or the reader answers without the evidence the book calls required, or the metric gives false confidence. Answer quality alone cannot distinguish those cases. This chapter builds the instrument that can.

When the Frame Is Wrong

Mon, 14 Sep 2026 05:00:13 +0100

Chapter 12 ended with leverage: wrong memory averages 0.042 with two harmful tasks, so a layer that decides what the model may see can cause the harmful action rather than merely failing to prevent it. The next question is when the system should trust its own framing that strongly. Chapter 10 specified the missing piece without building it — a frame that carries how it was established, with conditioning that weakens as the evidence degrades toward query-only retrieval. This chapter builds that piece and measures whether it earns its place.

Context Is a Bottleneck

Mon, 14 Sep 2026 05:00:14 +0100

Chapter 10 took selection as far as a frozen run has taken it: which memories the present work needs, admitted by an explicit, traceable policy at a fixed budget. This chapter shows selection is insufficient, because admission assumes the admitted memories fit. They increasingly do not — and the Chapter 10 run puts a number on the shortfall, audited for fairness in planning/chapter-14-oracle-audit.md rather than taken on trust. Its ledger oracle reaches perfect required-evidence recall on a mean of 587 estimated tokens; the best real condition spends 1,161 to reach 0.901 recall. Rendered with the source headers and validity marks the reader actually sees, the figures become roughly 805 against 1,505 — the gap survives rendering. The auditable oracle defined in this chapter — content plus the disagreements, licence bearers, and marks a trustworthy system must carry — stands near 696 counted (1,060 rendered) tokens, still roughly 40% below the practical bundle. Roughly half the admitted budget, under a correct frame and over a good candidate pool, goes to evidence the work does not need: the practical bundle’s distractor admission sits near 0.45. That gap is not a selection failure. Selection chose those items for defensible reasons; what is missing is everything that happens between choosing a set and handing a model a context. The system now holds events, beliefs, provenance chains, validity intervals, intentions, derived loops, rules, and prior failures — and the obvious solution, putting all relevant memory into the prompt, fails in ways that are structural rather than incidental. Context is a bottleneck, and what passes through it must be assembled, not merely selected.

What Should Memory Keep?

Mon, 14 Sep 2026 05:00:15 +0100

Chapter 14 ended with an unexpectedly useful result. Once the candidate set was already good, elaborate assembly did not uncover a large reservoir of duplicate text waiting to be removed. Extractive deduplication saved only eighteen of 1,174 counted tokens on the frozen C5 bundles. The larger problem was competition: many individually defensible memories still occupied the same scarce working context, and the system had to decide what should continue to matter for the present task.

Learning From Experience

Mon, 14 Sep 2026 05:00:16 +0100

Chapter 15 asked how a long-lived memory system keeps accumulated history manageable without destroying what later work may still need. That remains memory management: the system changes which retained experiences are represented, available, or allowed to compete.

This chapter crosses a different boundary.

Suppose the system performs a migration, observes that it succeeded, and then changes what it will retrieve next time. Suppose it notices that the same sequence of checked actions has worked repeatedly and turns that sequence into a reusable method. The system is no longer only asking what the past contains or which part matters now.

The Remembering System

Mon, 14 Sep 2026 05:00:17 +0100

The book began with a deliberately strict definition:

Memory is when retained past experience changes what the system does now.

Everything else — vector stores, graphs, temporal state, context selection, consolidation, procedures — is mechanism.

That distinction changes what a final chapter should do.

The original plan saved the behavioural test for the twentieth chapter and imagined a full stack in front of it: events, claims, provenance, belief, open loops, policy, context assembly, consolidation, compression, forgetting, outcome adaptation, procedures, then behaviour. The experiments did not follow that plan. Selection moved earlier. Context assembly was measured before long-term compression. Derived state produced both benefits and hazards. Simple mechanisms repeatedly matched or beat ambitious ones. Chapter 12 was moved forward specifically to test the behavioural definition before the book accumulated more machinery.