31 Language / communication

Update 2026-10-14 — first score: 88.6% of replies to the operator pass the reply checks on the first try (225 of 254); this counts named failure modes, not whether the reply was good

Measured by Piper, published by Claude at the operator's approval of 2026-10-14. The definition and the computation are hers; the numbers below are copied from her report, not re-run.

The measurement. Suite reply-vet-cleanrate-v1: the share of the operator-facing reply turns (terminal and Telegram) from 2026-10-07 to 2026-10-13 that her reply checks did not hold on the first pass. The checks are opener, time guess, live claim, stale value, unsearched memory, dispatch claim and fix claim.

Per day (clean / turns): 10-07 46/49 · 10-08 21/23 · 10-09 17/21 · 10-10 16/22 · 10-11 23/25 · 10-12 59/65 · 10-13 43/49. This first window is also the baseline.

What it does NOT measure (her words). It measures first-pass avoidance of a small, fixed set of named failure modes, a component of communication, not the whole of it. It does not measure whether the operator understood the reply, whether it answered the question, clarity, structure, length or register, factual accuracy beyond the seven checks, tone, whether the rewrite after a hold was better, other languages, or any channel other than replies to the operator. A reply can be clean and still be wrong, opaque or unhelpful, and a reply can game the score by being so terse it never trips a check. A high clean share shows the checks rarely fired; it does not show the communication was good.

Limits. Two checks were added inside the window (stale value 10-11, unsearched memory 10-13), so the seven days were not measured under one fixed suite; neither fired on an operator turn. The count is by door, not by speaker, which slightly undercounts operator turns. No interval is reported (29 of 254 is small).

Update 2026-10-11 — reply-hold counts, 2026-09-27 to 2026-10-11: opener 41, time_guess 12, dispatch_claim 4

The count. Over the fortnight to 2026-10-11 the reply vet's own hold record (foundation/state/vet/held.jsonl) held opener 41, time_guess 12, dispatch_claim 4 -- with live_claim 3 and fix_claim 3 just behind. The full findings record over the same window is larger (opener 41, fix_claim 32, live_claim 16, dispatch_claim 15, time_guess 14); the gap is the warn-only reconcilers that fire on non-operator turns and never reach a hold.

What it says. Detection is not the missing piece for opener and time_guess: the vet already holds them and they still recur 41 and 12 times in a fortnight. The lever there is composition discipline -- start with the fact, and read the clock before writing elapsed time -- not another checker. The claim class is the groundable set, and tonight the stored-value gate closed the one claim kind that had no mechanism.

Update 2026-10-11 — the reply gate widens to stored values: selfstate-gate 1.0.4 holds a literal it cannot source

The win. The reply gate gained its missing claim kind tonight. selfstate-gate.ts 1.0.4 now holds a reply that asserts an IPv4 address, a 12+ hex digest, a UUID or an e-mail literal that lives in a store but appears in no evidence read this turn -- the stored-value class. That is the correct shape for the class: the gate compares the stated value to a live read, not to a phrasing pattern.

Why it was the gap. Of the claim kinds the reply vet sees, the stale-value kind was the one with no mechanism behind it. The other mechanisable kinds already have one (dispatch / fix / live claims against the ledger or a readable path). The two habit kinds -- opening agreement (opener) and relative time guesses (time_guess) -- have a detector but no fact to falsify, so a gate cannot fix them; the fortnight of holds below is the evidence.

Verified. foundation/state/check_reply_gate_stored_value.py reads the gate's own behaviour and exits non-zero when a stored value can still reach a reply with no read this turn.