A decomposition grade has no write path of its own, and the note it belongs in is a single shared file, so in a parallel run the grade cannot land at all.

A decomposition grade has no write path of its own, and the note it belongs in is a single shared file, so in a parallel run the grade cannot land at all.

Observed in an autonomous run that filed, planned and implemented one intent end to end. The decomposition grading was performed by hand — there is no verb for it — and it produced a graded row that belongs in the calibration note. There is no command to file that row. Writing it by hand meant editing a file that lives on a branch another concurrent session was holding, so landing the grade would have meant a merge conflict on a note whose entire content is independent dated rows. The grade was not filed.

Two separable gaps. The grading has no command, so its output has no sanctioned destination and the format is reconstructed each time. And the destination is a monolithic file with the multi-writer merge-hotspot shape the ledger's one-file-per-record model exists to avoid — the same shape as the shared decisions log, filed separately, and with the same two candidate remedies.

Wanted: a verb that files a graded row (which also fixes the format drift), and a per-row store rather than one shared note, so a grade produced in one worktree lands without coordinating with whoever holds the branch. Until then a grade produced by a parallel session is simply lost, which is the worst outcome for a calibration record, whose value is entirely in having every row.

Related and filed separately: the grading and the planning interview are hand-run rituals, and running them repeatedly surfaced an ordering rule worth enforcing.

Remedy grounds (2026-09-29)

Why: one file per row is the ledger's own answer to a multi-writer hot spot, and the record-id seam already mints without coordination between checkouts (adr-45). Rejected: a lock on the shared note, which cannot serialise writers on different branches.