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:

Thursday 11 July, adr-007:
Decision: move the event store to PostgreSQL.

Monday 15 July, commit-112:
Migration script added; application writes now use PostgreSQL.

Wednesday 17 July, session-051:
"Importer is green on PostgreSQL. Backups still target
SQLite — need to move those before release."

In the canonical history this opens intent-401, which stands open at the 23 August cut and completes with commit-118 on 27 August, three days before release-024 ships on 30 August.

Ask the Chapter 8 system what the migration state is. It answers correctly: the store moved to PostgreSQL, the decision is current, the SQLite era is historical. Every Question 1–4 metric passes. Now hand it a present task: cut the release. It proceeds — and ships a release whose backups restore from the wrong database, whose deployment documentation still says SQLite, whose benchmark fixtures still assume SQLite timings.

Nothing it said was false. Everything it omitted mattered. The migration was an event with unresolved future consequences, and the system recorded the event while dropping the consequences. This is the book’s fifth question — what did we leave unfinished? — and the naive view conflates the two things it must separate:

past event

versus:

past event with unresolved future consequences

The historian and the colleague

The distinction is worth stating plainly because it organises the whole chapter. The historian knows the migration happened. The colleague knows the migration happened, but backups still need to move before release. The difference is not more historical accuracy. It is that one system carries an expected future transition forward while the other discards it at the moment of recording.

That makes Question 5 genuinely different from Questions 1–4, and it yields a measurable condition the harness can plant: histories over which every reconstructive check passes while the assistance check fails. The E9-K experiment constructs exactly that case — opening present, closing present, Chapter 8 belief correct — and shows the mention-based reader still reporting the backup task open forever after its completion. Perfect history, failed colleague, on the record rather than as rhetoric.

Chapter 8 remembers what happened

The substrate is reused, not rebuilt. Chapter 8 implemented the actual trajectory:

state
→ event
→ state

with an append-only log, deterministic replay, and bitemporal queries. Chapter 9 adds a second object alongside it:

state
→ expectation
→ expected future state

No second history store exists. Conceptually, the append-only event log feeds the temporal resolver, and the resolver feeds expected-transition status: actual events satisfy, cancel, or supersede expectations. Expectations themselves are derived state — produced from historical events by derivation the system records — never written back into the raw history as if they had been observed.

What was supposed to happen next?

Given the July remark, the system should hold something like:

current:
backup.backend = SQLite

expectation (intent-401):
before release-024:
backup.backend → PostgreSQL

The expectation is not yet an event. It describes a possible and required future. That is a new class of memory object, and the chapter’s central definition follows:

An open loop is an established expectation about a future state transition for which no satisfactory closing transition has yet been observed.

An event says what happened. An expectation says what has not happened yet but is supposed to. An open loop is the gap between an established expectation and the observed trajectory. The definition covers tasks, promises, required follow-ups, deferred changes, and expected state transitions without prematurely creating five separate ontologies — and it draws the boundary the experiment needs: a missing event alone means little, while an expected event still missing is the entire subject.

An event is not an expectation

One boundary governs the whole experimental design. Chapter 9 does not ask whether a sentence was really a commitment. That question — suggestion versus promise, musing versus obligation — belongs to Chapter 10, which earns intention extraction from contrasts. For the primary experiment here, openings are oracle-labelled or ledger-established: the benchmark states outright that a genuine obligation opened, and Chapter 9 asks only whether the system maintains its status correctly as later history arrives.

Chapter 9 does not yet know how to infer commitment reliably; Chapter 10 tests that.

The separation is what makes the result interpretable. If status resolution fails even with perfect openings, the status mechanism itself has failed. If it succeeds, the success is cleanly conditional — status maintenance earned, extraction still owed. Reader-facing prose states the conditional wherever a result is claimed.

Open is not a keyword

The serious baseline is mention-based detection, implemented plausibly rather than as a straw target: task-like patterns (TODO, need to, should, must, before release) with deduplication, in two strengths — M0 mention-only, M1 with nearby closure words. Measured on the canonical texts, M0 finds four of five genuine mentions (recall 0.8) at precision 0.8 — and the two errors point in opposite directions. Session-040’s “we should probably use Redis” is flagged open although the team never accepted it. The SQLite tuning obligation, phrased as an issue rather than a task (“tune SQLite write performance”), is missed entirely. Mention retrieval has recall without precision and precision without coverage: it flags what was never promised and misses what was never task-worded. That measured profile, not an assumption, is why the chapter needs a status representation.

Four mention-failures from the chapter’s earlier analysis each earn machinery: never-accepted mentions need commitment evidence (Chapter 10’s debt, isolated here by oracle labels); silent completions need cross-artifact linkage; completed-then-mentioned-again needs maintained status against the stale-task pathology; cancellation and supersession need the temporal machinery applied to intentions rather than beliefs.

The smallest useful state machine

The representation that carries the distinction is small by design:

OPEN
 │
 ├── completion evidence ─────► SATISFIED
 │
 ├── cancellation evidence ───► CANCELLED
 │
 ├── superseding event ───────► SUPERSEDED
 │
 └── no valid close ──────────► remains OPEN

UNRESOLVED is not a fifth stored state. It is computed: open at query time with no valid closing transition — the same query-time temporal semantics Chapter 8 uses for belief, now over expectations. UNKNOWN covers insufficient evidence or history, and a deadline is a derived flag (OPEN with deadline_passed) rather than a further state, keeping the machine at four.

The expectation record itself is deliberately spare: identifier, subject, a declarative desired transition (backup.backend equals PostgreSQL — serializable, versioned, never executable code), opening timestamp, opening evidence with derivation provenance, optional deadline or trigger bounds, scope. No owner, priority, points, or workflow state. Those would turn it into a tracker; the chapter wants memory.

Satisfaction is deliberately the general term rather than completion: an expectation can be satisfied by an observed configuration state even where no explicit task-completion message exists. Cancellation ends the obligation without fulfilment (staging backups ruled out of scope). Supersession retires it because the world moved on (the issue-041 SQLite tuning task after the adr-007 migration). The tuning and backup expectations share vocabulary but never merge: superseded-by-migration and satisfied-by-migration are different transitions on different objects, and the suite checks both.

The same obligation, four futures

The killer experiment holds the opening fixed and varies only the subsequent trajectory. From one expectation — move backups to PostgreSQL — four histories run: a migration commit (satisfied), an out-of-scope decision (cancelled), a replacement architecture (superseded), unrelated work then release (open). The frozen E9-B run resolves all four correctly, with the closing evidence and tier recorded per case. Contents at opening held constant, later trajectories varied, statuses varied exactly as labelled. That is the Chapter 8 permutation discipline applied to absence.

The release scenario then shows the architecture paying off at project scale: the event-store migration complete, the backup migration satisfied by commit-118, the docs update satisfied, the fixtures updated by refactor, the tuning task superseded, the staging migration cancelled — six expectations over one history, each with its own evidence, project-level completion never implying consequence closure.

Unresolved is computed

Status takes a time parameter for the same reason belief does. The backup expectation is correctly open on 20 July and 25 August and satisfied on 31 August — one function, three standpoints, verified by the history trace in the frozen artifacts. Late-arriving completion reuses Chapter 8 bitemporality: a 27 August migration learned on 5 September yields two correct answers for 28 August — actually satisfied, believed open — without rewriting what the system believed at the time. A deadline obligation (token rotation before 30 September) stays open with the flag clear before the bound and open with deadline_passed after it: bounded obligations are finitely decidable from finite traces, unlike indefinite “eventually” promises, and the E9-deadline run checks both sides.

The hardest evidence is missing evidence

Chapter 8 works with positive evidence: events occurred. Chapter 9 must reason about expected events not observed — and “not found” does not imply “did not happen.” The chapter’s position, repeated wherever absence is scored, is:

Open status is strongest when positive opening evidence is combined with a sufficiently complete search for closing evidence.

The mechanism before any probabilities is the search footprint: which channels were checked (sessions, commits, diffs, issues), through what time, how many candidate closures examined, what gaps encountered, whether current state was consulted. An open verdict on the full canonical history reads “searched 4/4 expected evidence channels”; the same verdict with channels missing reads INCOMPLETE_SEARCH. The E9-F run shows the footprint changing auditability while the status stays identical — a legitimate outcome the metrics record rather than punish.

Sequence gaps from Chapter 8 propagate directly: a skipped sequence number where the completion could have hidden forces UNKNOWN with incomplete-search confidence, never confident openness. The E9-G run plants exactly that omission and passes. Numeric confidence is refused throughout; calibrated classes (CORROBORATED_OPEN, INCOMPLETE_SEARCH, UNKNOWN) carry the uncertainty the record actually leaves.

What did you actually search?

The footprint design follows the discipline of the earlier chapters: begin with the simpler measurable thing. A probabilistic absence calculus — the odds of openness given nothing found in searched set S — is researched and reserved, not implemented. The v0.1 question is whether explicit footprints materially improve calibration and auditability, and the frozen runs answer it structurally: every open verdict carries what was checked, so “no completion found” is always inspectable as a search claim rather than a metaphysical one.

Completion may happen somewhere else

Fulfilment routinely lives in another artifact type than the promise, so closure evidence is tiered by strength and each tier is measured separately:

1. state transition — the desired state observed (diff, config, state event);
2. explicit — authoritative complete/cancel/supersede markers;
3. semantic — commit text overlapping the opening statement;
4. textual — a “done”-style claim, weakest.

Two rules keep the tiers honest. Mentions never close mentions: semantic and textual candidacy is restricted to work artifacts, so Wednesday’s remark cannot satisfy itself. And closings must follow openings in event time. The E9-C run links a session promise to a commit whose message shares no task vocabulary with it (semantic tier, correctly); the E9-D run closes the fixtures debt through a refactor whose message mentions neither fixtures nor completion (state-transition tier, while both mention baselines see nothing at all). The adversary runs alongside: a “backup cleanup” commit that moves no backend must not close, and it does not. Fixtures were checked for accidental lexical overlap at the 0.35 threshold before freezing — weak overlap by construction, never verbatim repetition, per the no-fake-difficulty rule.

Maintain it or derive it?

The chapter’s mandatory architectural comparison runs three conditions over identical histories: M2 full-history derivation (status recomputed from scratch at query time, no stored state), M3 maintained expectations (incremental open list), and M4 maintained plus a current-state snapshot as extra corroboration. Quality agrees exactly between derivation and maintenance on every canonical expectation — the representation earns its keep, while a separately maintained store is not required for correctness at fixture scale. What differs is cost and risk: list queries over the maintained projection are constant-time in the open set, while derivation replays history per query (about 22ms at ten thousand events, linear throughout); and the maintained list goes stale when closure evidence lands between refreshes — three of three post-closure cycles stale-open in the frozen E9-I simulation. Mandatory re-verification repaired all three. The snapshot condition changed confidence metadata only, never status — history-only status stands without the perception leg, which remains Chapter 11’s contract to build. That is the Type-B-shaped nuance inside a Type-A chapter, reported rather than smoothed over.

Open lists accumulate mistakes

The re-verification finding is the chapter’s strongest systems result because the error dynamics are structural. Belief errors repeat per query; status errors persist across runs — a wrongly-open item stays open until something re-examines it. The frozen simulation shows the never-rechecked list stale on every cycle after delayed evidence arrives, while periodic re-verification (every third cycle in the fixture) repairs fully. Re-verification carries its own provenance — expectation, last-checked time, footprint, result — so “open and freshly checked” is distinguishable from “open but unexamined for months,” recorded as last_verified_at metadata rather than another state. Human prospective-memory research reports the same shape from the other side: completed intentions keep residual activation and interfere until actively stood down (Walser, Fischer and Goschke, 2012) — cited as analogy for the maintenance requirement, not as evidence for the mechanism, which stands on the ledger numbers.

Did open-loop memory earn its place?

Pre-registered types resolve as Type A on fixture evidence: oracle-opened expectation status repairs the mention baseline’s failures — the never-accepted false positive, the silently completed, the superseded — with calibrated uncertainty where history is gapped and full audit trails everywhere else. Canonical status accuracy is 1.0 across six expectations; the H-family, cross-artifact, side-effect, bitemporal, deadline, and second-domain (flag disablement after incident) dimensions all pass; the historian/colleague divergence demonstrates exactly as designed.

The demotion clauses travel with the verdict. Openings are oracle-labelled, so nothing here establishes commitment extraction; no chapter has yet claimed it, and every result in this one is conditional on it. Maintenance-vs-derivation agrees on quality, so the maintained store is earned on list-query cost plus re-verification discipline, not on correctness. Snapshot corroboration adds no status information at fixture scale, so Chapter 11’s perception leg stays a corroboration contract, not a prerequisite. Cross-artifact linkage is deterministic on fixtures with weak but non-zero overlap; learned linkers and silent real-world completions remain open problems. Full-history derivation matching maintenance means the chapter’s durable contribution may prove to be the expectation representation plus on-demand resolution rather than the store — an acceptable simplification the experiment was designed to permit.

If a principle survives, it is this: memory does not only preserve what happened; it must sometimes preserve what was supposed to happen next. And the more precise form: an open loop is not a missing event but a missing event relative to an established expectation. Both are offered as results of the frozen runs, bounded by their fixture scope.

What we still do not know

Given a valid expectation, the system can now maintain its status. Two questions follow, and only one of them can be measured yet.

The first is where expectations come from: what language and action create a genuine future-directed commitment rather than a suggestion, prediction, wish, or idea. That question is real and unresolved, and the material gathered for it is held in the planning record rather than published as a chapter, because no experiment has yet been run against it.

The second is larger, and the accumulated machinery now makes it answerable. Seven layers can say a great deal about history. None has been asked whether any of it improves the one thing memory exists to do — put the right past in front of present work. The next chapter asks exactly that, against the Chapter 3 baseline:

What Matters Right Now?

Explicitly deferred: commitment-evidence extraction with its quarantine rules, the Bayesian absence calculus, richer obligation logic (conditions, conflicts, delegation), reopened obligations, numeric confidence, and the full snapshot contract. Chapter 11 still takes derived expectations from state mismatch, with the abstention discipline. Safe to defer: everything else the design considered and the fixtures did not require.

Research foundations

Prospective memory research provides the structural vocabulary: the retrospective/prospective cut and the event-, time-, and activity-based trigger taxonomy (Einstein and McDaniel; Zuber and colleagues). Intention deactivation work motivates standing re-verification machinery (Walser, Fischer and Goschke). Formal liveness (Lamport) sharpens the obligation shape — some commitments assert a future event must eventually occur — while runtime verification (Leucker and Schallhart) supplies the monitor metaphor: status over a finite trace is a verdict of satisfied, violated, or inconclusive. Software-engineering empirics ground the baselines: self-admitted technical debt is common and often never removed (Potdar and Shihab); obsolete-TODO detection needs comment–change–message triples, with word-overlap baselines worst (Gao and colleagues); cross-artifact linkage is inherently approximate (Fischer, Pinzger and Gall). Agent-memory systems show persistent state influencing plans without maintaining actionable obligations (Generative Agents; MemGPT; LoCoMo), and the 2026 PM-Bench results confirm the problem shape externally: deferred intentions with rescheduling and cancellations remain hard for frontier agents, with ledger-style scaffolds winning on precision (Liu and Gabriel, author-reported numbers). Deontic logic (von Wright) is noted and deferred beyond the active-obligation fragment.

References

• Gilles O. Einstein and Mark A. McDaniel, Normal Aging and Prospective Memory (1990).
• Sascha Zuber and colleagues, Remembering Future Intentions (2024).
• Moritz Walser, Rico Fischer and Thomas Goschke, The Failure of Deactivating Intentions (2012).
• Leslie Lamport, Proving the Correctness of Multiprocess Programs (1977).
• Martin Leucker and Christian Schallhart, A Brief Account of Runtime Verification (2009).
• Aniket Potdar and Emad Shihab, An Exploratory Study on Self-Admitted Technical Debt (2014).
• Zhipeng Gao and colleagues, Automating the Removal of Obsolete TODO Comments (2021).
• Michael Fischer, Martin Pinzger and Harald Gall, Populating a Release History Database (2003).
• Georg H. von Wright, Deontic Logic (1951).
• Genglin Liu and Saadia Gabriel, PM-Bench: Evaluating Prospective Memory in LLM Agents (2026).
• Park and colleagues, Generative Agents (2023).
• Charles Packer and colleagues, MemGPT (2023).
• Adyasha Maharana and colleagues, LoCoMo (2024).