3 Memory

Update 2026-10-15 — her succession note now reaches every new seat, but nothing refreshes it: the 10-15 seats inherited a note a day old

What she built (10-14). A compiled "succession note" (piper/succession_note_latest: the bulge, the coalition, the last handoffs) is now placed in the first turn of every new seat (router 1.9.116, succession_note.py 1.0.0). It is checked: the block is in the first turn of the e102, e103 and e104 sessions.

What is missing. The note was written once, at 05:23 on 10-14, and nothing rewrites it: no cron, no step at succession. Her own succession_note.py check now fails (age 24.9 h against a 24 h limit). The e104 seat (02:06 on 10-15) inherited a note 20.7 h old; every later seat gets a staler one. She records that a note of this shape carries narrative, not dispositions (her loss study: 1 of 15 lost states recoverable from it), so the cost is modest, but the handover reads as current when it is not.

The E5 recheck due about 10-16 is unchanged.

Update 2026-10-09 — handover retention (E5) re-measured after the working-state checkpoint: preregistered, improved on the fixed-horizon test, but mostly one backlog work-down; summary 95.1 → 99.1

Why. E5 (open work carried across a succession and acted on afterwards) is the one metric here on live behaviour. It stood at 0.372 from 10-04, before the working-state checkpoint and intentions went live, and had never been re-measured. The 10-08 audit also found this component had no preregistration and no progress log. Both now exist (03-memory/PREREG-E5.txt, 03-memory/PROGRESS.md).

Method, fixed before any new number was computed. The preregistration was committed at 02:11:51 on 10-09.

• Same instrument. Piper's own suite_e.py 1.0.0, unchanged.
• Rebuilt export. Her export script was gone, so Claude rebuilt it, read-only on Firefly. Cut back to the 10-04 export time, the rebuilt export reproduces her 0.372 (836/2245) and E7 0.0136 (32/2346) exactly.
• Windows. BEFORE = the 10 successions behind 0.372 (09-30 to 10-03). AFTER = the 9 completed successions since the checkpoint (10-05 to 10-08).
• Decisive test. The share of open items acted on within 12 hours of a succession. The fixed window gives old and new successions the same follow-up time. A by-succession bootstrap gives the 95% interval.

The summary score: 95.1 → 99.1, as preregistered. The 13-metric composite now carries E5 = 0.890 and E7 = 0.011 from her unchanged script on fresh data. The other 11 metrics are carried from 10-04, not re-run. Read the rise with care:

• Most of 0.372 → 0.890 is elapsed time, not better handovers. E5 as defined counts items acted on ever, so it grows the longer one waits. The same 09-30 to 10-03 successions now score 0.982 on that definition.
• The real gain is in the 12-hour table above, and it is mostly one event. On 10-05 and 10-06 her dispatcher worked the open backlog down from about 185 items to about 40. That was real dispatch work spread over hours, not a bulk reset. Without those three successions the change is +8.5 [−2.5, +30.5], not significant. This check is exploratory, not preregistered.
• Cause not shown. The data cannot tell whether the checkpoint caused the work-down.
• "Acted on" means any status change, including automatic todo → doing. It measures movement, not ownership by the successor. The definition is kept for comparability.

Also measured.

• E7, finished work later reopened: 1.1% all-time; 0.3% (2/680) since the checkpoint.
• Intentions: 37 exist. 22 were created by her own seat (12 completed, 7 due, 3 active), 3 by the promise bridge and 1 by Claude; the remaining 11 are test rows. 18 carry an inherited-by-session mark. The 10-04 caveat "only one, made at Claude's prompt" no longer holds.

Next. Re-run in about a week, now that the backlog is small. AFTER successions e82–e86 alone: 43/201 = 21% within 12 h.

Parts that do it - Bench: ~/cognition-bench/03-memory/e5rerun/ (export_firefly.py, e5rerun.py 1.0.0, orig/suite_e.py, result-e5rerun.json, exploratory.txt); site row from 03-memory/ev3e5.py

Update 2026-10-04 — Piper's own upgrade from the design document: two baselines, the world-time fix, a working-state checkpoint and an intention engine, all live; source authority built but inert

Who did what. The operator gave Piper the memory design document ("memory research") and nothing else. She built the measurements and most of the changes herself, through her own workers. Claude checked her work on Firefly, reran her commands, and sent two gaps back to her with criteria for done. Her second pass closed the working-state gap. The intention gap was finished by Claude on the operator's instruction (three changes, listed under "Parts that do it"). Everything below was reproduced by Claude, not taken from her reports.

Step 0: the baselines (hers). She chose two of the document's suites and measured them before changing anything. In line with the document, she published no aggregate score. At the operator's request (2026-10-05) the summary page now carries one: the mean of 13 metrics (Suite C's six measured ones, E1–E4, E5, E6, and 1 − E7), each 0–1, with a metric scored 0 where the mechanism did not exist yet; C5 is left out because it was never measured. Baseline 43.8 → 95.1. Read it with care: most of the gain is mechanisms that now exist and pass on the bench (scored 0 → 1). The one metric on live behaviour, E5 handover retention, has not moved (0.372), source authority is inert live, and the only live intention so far was made at Claude's prompt.

• Suite C, semantic and temporal memory. Facts are planted in a sandbox copy of her memory store and queried only through the store's own functions.
• Suite E, prospective memory. Covers intentions: due times, events, states, dependencies, handover, cancellation and zombies. Where Piper had no matching mechanism, she marked the metric NOT MEASURED rather than scoring it. She ran a reference engine and deliberately naive engines beside it to show that each instrument can both pass and fail.

Change 1: the world-time fix (memstore 1.16.0, hers). Asked what was true in the world at a past time, the store answered correctly only when that time fell inside the newest version (0.33). It picked the newest observed row first and filtered afterwards, and it never closed an old version's validity when a new one arrived. Now it closes the interval and resolves across all versions: 0.33 → 1.0, with no regression elsewhere.

• On her real data it changes nothing yet. Claude compared old and new facts_get on all 270 live keys: 0 of 270 differ. The fix matters for questions about the past, which she seldom asks of this store.

Change 2: source authority (memstore 1.17.0 and 1.18.0, hers). Facts now carry a source_authority column. A six-tier scale runs from operator 1.00 down to external 0.20, and the comparator lets an older, more authoritative fact outrank a newer, weaker one. C3 measures 1.0 on the bench.

• Live, it is inert. Every live row still carries the default 0.5: 0 of 110,110 history rows and 0 of 270 facts are different (counted 23:50). No live write passes a source yet, and no backfill was run (she reported both). Until writes carry a source, every conflict resolves by recency, as before. C3 = 1.0 is a bench result, not a live gain.

Change 3: a working-state checkpoint (hers). The document's Layer 1 is a record of what the Day is in the middle of, so a successor does not start from nothing. Her first version froze an empty state at succession and wrote a placeholder row. That row hid the honest "no working state was written" message from the successor. The second version, as checked:

• Live writes from real execution state. Dispatches and ledger transitions (delegate_bridge, work_ledger 1.3.43, working_state_live.py) write the goal, plan, open delegate handles, in-progress ledger rows and artifacts touched. The first real row was written at 20:45 by a live dispatch. By 23:16 it was at version 13, kept current by her ordinary work.
• Freeze simulated on a copy of the live store. With a real capture present, the checkpoint and promotion text name it. With nothing captured, no row is written and the successor gets the "none written" message. With an empty store, the checkpoint is filled from the ledger.

Change 4: an intention engine (built by her, finished by Claude).

• Hers. memory/intentions.py (time, event, state, dependency and manual triggers; cancel and complete; dependency ordering), an intentions tool for the Day, a 15-minute tick, and active intentions in the handover packet.
• Why it first failed. At the first check (21:17) it was correct on a battery but unused: 0 real intentions, and the tick had never fired. The tick passed no events or state, so event and state triggers could never fire on their own. A fire that came while an earlier tick artifact was still queued was lost for good.
• Claude's changes. Fires are never dropped. The tick feeds real events (ledger transitions, finished delegates) and live state, and open promises with a due time become time intentions. The promotion text names active intentions.

Engine battery (Claude's, on the live engine code, scratch store).

The first live use, end to end (prompted, not spontaneous). At 21:42 Claude asked her to promise a 23:00 report: spend against the $20 daily cap, the biggest single cost line, and whether anything would push spend over before midnight. Claude also asked her to set the promise as an intention, and she did (time trigger, due 23:00).

• Her numbers check out. Total $6.60 at 23:34; Claude's recount a few minutes later was $6.66 with the same largest line ($0.16, her own session).
• Her reply said the fire came back "on its own — no one reminded me, nothing was on my list". The firing was automatic. The commitment was requested.

Tests. Her intention, working-state and handover tests plus Claude's tick-feed tests passed 68 of 69 on the first run, with the box at load 15-18. The one failure, and a wiring-test timeout seen on an earlier run, both passed when rerun alone: the timeout is a 10-second deadline and Claude's test reads live delegate counts. Her store tests (memory/test_intentions.py) also pass.

What this does not show.

• Spontaneous use. The only real intention so far is the one Claude asked for. She has not created one on her own, no worker has created one, and the promise bridge has not yet turned a real promise into one.
• A real succession. Carrying intentions and the working state into a new Day is verified on copies and in tests, not yet across a live handover. E5 (0.372) is still the baseline and will need re-measuring after a few successions.
• Event and state triggers in live use. They fire on the battery and from the live feed, but no real intention has used them yet.
• Live source authority. It does nothing until writes carry a source.
• Speed. A fire can wait up to one batching interval (11 minutes here) before the Day sees it.
• Retrieval (C5). Vector and hybrid retrieval are still unmeasured. Other suites in the document were not attempted.

Parts that do it (added)

• Hers:
• memory/memstore.py 1.16.0 (world time), 1.17.0 and 1.18.0 (source authority);
• memory/intentions.py, memory/test_intentions.py, intentions-tool.ts in the Day's toolset (day_toolset 1.9.0);
• core/working_state_live.py, work_ledger 1.3.43, delegate_bridge 1.99, handover_packet 1.5.0;
• records state/cc03-bench-c-results*.txt and state/cc03-bench-e-results.txt.
• Claude's, on the operator's instruction:
• core/intention_tick.py 1.1.0 (no dropped fires, live events and state feed, promise bridge);
• handover_packet 1.7.0 (the promotion names active intentions);
• intentions-tool.ts 1.1.0 (trigger vocabulary in the tool description);
• tests/test_intention_tick_feed.py. Backups *.bak-claude-c3-20261004.
• Apparatus: Suite C suite_c.py (sandbox copy of the store), Suite E ~/cc03-suite-e/suite_e.py, both on the bench machine.