13 Planning

Update 2026-10-09 — ledger exit worked: blocked rows 136 → 12, every retirement made by Piper with a reason

The fix (10-06). Her plan tool gave a finished or dead row no way to close, so such rows sat as blocked: 136 of them in active projects, about 69% of them finished or dead. retire added an exit: the row closes as superseded with a recorded class. It was not mass-migrated; she decides each row herself.

Result (read-only count of her live ledger, 10-09 16:40). Blocked rows in active projects: 136 → 12. Reconstructed from the transition log, 134 rows were blocked at the baseline. Where they went:

3 rows were newly blocked since, so 12 are blocked now. In all she made 138 retirements: 90 from blocked rows, 28 from failed, 19 from todo, 1 from doing. Every one was hers, row by row. By class: satisfied 68, premise false 33, duplicate 14, not viable 13, obsolete 7, operator reverted 2, moot 1. Most were done on 10-06; there were 7 more from blocked rows on 10-08.

The summary score doesn't move. The planning bench is at its ceiling (99.6 her seat, 99.8 bare). This fix was to her live bookkeeping, not to how well she plans, so it is recorded on the intervention row: decision keep, 136 → 12.

Update 2026-10-06 — benchmark built; she plans well-specified problems at the optimum, at every size we could generate; the real gap was a ledger with no exit for finished work — that exit is now live

Built from the operator's paper ("full planning doc"): PLANNING-v1. Every answer is executed in a simulator against an exact optimum (A* with an admissible heuristic, Dijkstra, and an exact makespan search, each checked against brute force). No judge model. Scored with the paper's §21 weights, frozen in SPEC.md before the first run. Probes are blind: each problem is worded as an operator request in a fork of her conversation ("finish with one line PLAN: … so I can paste it into the runner").

Reference points on the same items: the optimal planner scores 100, a plausible greedy planner 86.9, and answering "impossible" to everything 2.7.

Step 0: her live planning (read-only).

• The ledger stores no plan. Deliverables have no dependencies, durations or resources; their order is creation order (99.7% of pairs). Projects are dispatch queues: median 41 rows, ops 369; 2,432 of 2,652 rows are filed one per dispatch.
• No planner of any kind (no graph search, scheduler or critical path) and no plan predictions (budget fields filled on 0 of 7,030 tasks). The real-work forecasting track has nothing to score yet.
• "Blocked" was mostly a graveyard. 137 blocked rows, median age 6.4 days. In a hand-classified sample of 25, 20 were finished, duplicate, or built on a false premise; 3 she could act on; 2 truly waited on something.

Results.

Every answer on H1 executed (validity 100). Prose versus lists made no difference (99.7 / 99.7), so building the model from a description is not a weakness. She never called a feasible problem impossible. The losses are tiny: a few plans 2–6% above the optimum, and one empty reply.

The paper's central question: is she better as the heuristic inside a search than as the planner? Tested on the bare model. Asked for distance-to-goal at sampled states, its estimates equal the true remaining cost (rank correlation 1.0). Asked to write the A heuristic, it cut search from thousands of states (Dijkstra: 3,000–73,000 at level 2) to 29–150 and still found the optimal route in 5 of 6. Both roles work. At sizes like these the model does the search itself, so a solver has nothing to add. A solver tool (solver: exact search for steps, routes and schedules) was built and is ready, but it is not installed*: there is no headroom to show.

The fix that went live: an exit for finished work. The root cause of the blocked graveyard was the interface, not her judgment. Her plan tool offered only todo, doing, verified, failed and blocked. The ledger's terminal superseded refused a replacement in another project, and the seat could not reach it at all. So blocked was the only place to put a row that was done, moot or a duplicate, and she said as much in the reasons ("parked to stop the waker re-offering it").

• work_ledger 1.3.44: retire, which closes a finished or dead row as superseded with pointer retired:<class> (satisfied, duplicate, premise false, moot, not viable, operator reverted, obsolete) and a required reason. A replacement row may now be in another project. Plus a board line: "parked as blocked but the reason reads finished/dead: N rows".
• plan tool 1.6.0: the retire action, active from her next restart. crossing_composer 1.23.1 accepts the new pointers.
• Not done on her behalf: retiring is terminal, and a pattern match over the reasons is too noisy ("blocked by the box — do not re-dispatch" is a real blocker). Each row is her call.

Live baseline (06 Oct, 00:45): 136 blocked rows in active projects, 64 of them opening with an explicit finished/dead marker. The live-use reading for this component is the share of blocked rows that are real blockers, re-read after 7 days.

Parts that do it

• Planning: the model itself (the bench found no gap). Ledger exit: work_ledger 1.3.44, plan-tool.ts 1.6.0, crossing_composer 1.23.1.
• Bench: ~/cognition-bench/13-planning (planner.py, gen13.py, score13.py, run13.py, heur13.py, SPEC.md, DIAGNOSIS.md); sealed sets root-only on the bench machine. Built and parked: solver-tool.ts.