5 Representation

Update 2026-10-09 — first upgrades: the self-registry now keeps itself current (47.5 → 74.0, critical 14/14), the code graph drops deleted files, and her state cards stop presenting registry ghosts as versions

A correction to the baseline first. On 10-08 the registry looked unread: "read for a decision 0 times". That counted only her direct reads. The perception card added in #1 reads the registry for any module it cannot find on disk. In her last ten sessions, 1,387 version lines on her cards came from that fallback, against 2,854 read from disk. Examples: "foundation: version 1.3.0", "games: version 1.0.0", for things with no source file. So the stale registry was reaching her decisions.

1. Self-registry reconciliation (the paper's Intervention 1). A new nightly job, registry_reconcile.py, compares every registry row with the code on disk:

• out-of-date rows take the disk version through her own record_version(), so the changelog stays truthful;
• rows for files that exist nowhere move to a component_versions_retired table: 20 of them, kept rather than deleted;
• the three missing critical components are registered.

Two dry runs, before anything was written, caught rules that would have retired real systems:

• the baseline's "backup" exclusion also matched the file recovery_backup.py;
• components that live outside the main code folders (freeroam, canvas, games) were read as phantoms.

Those components are now left alone and listed.

What is left. The remaining errors are mostly the 84 rows for components outside the main code folders, which the baseline counts as phantoms. Coverage is unchanged at 48%: every registry name becomes a word her card watches for, so registering the other ~285 modules waits until its effect on card noise has been measured. Her self-description (resume_full) is still 1 of 10 versions right; nothing here touched it.

2. Code graph cleanup (codegraph 1.3.0). The index now removes entries for files that have been deleted. The deletion check had failed in all six languages; the battery is now 7 of 7 in each. On her live index the first cleanup removes 31 deleted files (266 nodes, 2,427 edges). A read-only dry run beforehand confirmed every one of them is really gone.

3. Card wording (premise_card 1.3.1, also part of #1). A module known only from the registry is now shown as "registry entry only (records 1.0.0, date); no live source file found…", not as a version fact. Lines read from disk are unchanged.

Readout 10-16. The nightly runs should keep every critical component's registry entry within a day of its file.

Parts that do it - Firefly: memory/registry_reconcile.py 1.0.0 (cron registry_reconcile.py-5a17, 04:47), memory/codegraph.py 1.3.0, foundation/core/premise_card.py 1.3.1; backups *.bak-claude-*-20261009, registry tables memory/registry-tables.bak-claude-regfix-20261009.json - Bench: ~/cognition-bench/05-representation/regfix/ (PREREG-R1, dry runs, check A), cgfix/ (PREREG-C2), post/ (score)

Update 2026-10-08 — baseline: her self-registry is 47.5% right (critical components: 3 of 10 versions correct), and nothing she decides reads it; the code graph is 98.7% fresh but never forgets a deleted file

Claude ran the plan's first and third experiments. Both were preregistered (PREREG-A, PREREG-C, hashes in the bench). Everything on her machine was read-only; the snapshot is sealed on the bench machine.

Experiment 1: her model of herself against reality. Each row of her component registry was checked against the live code: does the component exist, is the version right, is the path right.

• The registry was last written on 09-29, 9 days ago. Stale rows were last touched a median of 27.9 days ago.
• The components that matter most are the most wrong. 11 of 14 critical components are present (missing: the work ledger, harness acceptance, spheres rites). Only 3 of 10 have the right version: router 1.9.4 vs live 1.9.105, bridge 1.6.1 vs 1.106.0, memstore 1.0.2 vs 1.21.1, codegraph 1.0.0 vs 1.2.0; hive, foundationd and the registry's own entry are stale too.
• 4 rows use a file path or extension as the component name.
• Her written self-description (resume) is worse. 62 version mentions, 10 checkable: 1 right, 9 stale. Its header says "Last updated 2026-09-22", although a 10-07 addendum exists.

Does any decision rely on it? This is the question that decides whether the staleness is damage. - The registry has been read for a decision 0 times by the agent. Its only reader in code is staged_promote, and the one entry it reads (the work-ledger schema version) is correct. - The resume was read 16 times, every time while she was editing it, last on 09-03. No code preloads it. - So this is drift that no decision has relied on yet, not cognitive damage. The danger is the day something starts trusting it.

Running old code. foundationd has been up 17.6 days and its file changed 1.8 days ago, so it runs the older version. piper-cli and brainstorm likewise. Her self-model cannot see this at all.

Experiment 3: the code graph. A battery of seven checks per language on small fixture repositories, plus a freshness audit of the live index. - All six languages parse correctly. "Four indexed" only means there is no Go or Rust code in the folders it indexes; the only such files are in folders it skips. - The live index is fresh: 2,691 of 2,726 files current (98.7%). 5 were edited after this morning's ingest. - One real defect, in every language: deleting a file never removes its nodes. 30 deleted files still contribute 263 nodes. Each language passes 6 of 7 checks and fails this one. - Not preregistered, observed: JavaScript/TypeScript arrow functions are not captured as functions.

Expectations against results. Registry version accuracy above 50% was expected to fail; overall it passed (67%), but critical components failed badly (30%). Router and bridge stale: confirmed. The resume was expected to be better than the registry; it is worse. Drift without decision exposure: confirmed. The code graph was expected to show stale nodes from deletions (confirmed) and over 5% stale files (refuted: 1.1%).

Two corrections in my own collector, both recorded. It counted archive and backup copies as live; the scorer (score05 1.1) now applies the preregistered exclusion, with the change logged. It also marked the work-ledger schema entry unverifiable because it only scanned 400 lines; a direct read shows the entry is correct.

Score. 47.5 is registry exact-field accuracy only (subsuite D). It is not a total out of 100 for representation.

Next. 1. The plan's second experiment: does making her check the concept registry before writing new code actually help? (A/B on consultation.) 2. For the operator: regenerate the registry from the live tree instead of hand-editing it; make code-graph ingest delete nodes of removed files; restart foundationd.

Bench: ~/cognition-bench/05-representation (PREREG-A, PREREG-C, PROGRESS.md, collect05/score05/battery); snapshot sealed root-only on the bench machine.