---
name: filed-rate-may-predate-your-base
description: "A filed rate table names the SHAs it was measured at — check whether a fix landed since, because an issue's own earlier fix can be the thing that moved its rate."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 65448c94-60f8-4bce-88b7-3548e33546a0
  modified: 2026-08-21T10:20:49.901Z
---

releases#199's rate table said the second face was **1/20**, measured at
`bd942f6` and `4ba27d3`. I planned a hunt against that number. Both SHAs
**predate `8437b26`** — the in-flight bring-up ledger, which is *#199's own FIRST
face fix* and is an ancestor of the base I was working on. The rate at my base
had never been measured by anyone, so every "expected N reds in M runs" I would
have computed was arithmetic over a tree nobody was standing on.

**Why it is easy to miss:** the table is *in the issue*, formatted, with named
SHAs and run counts — it wears all the clothes of a current measurement. And the
confounder is not some sibling milestone: it is the SAME ISSUE's earlier lane.
A two-face issue fixes face one, stays open for face two, and its own header
table silently becomes historical.

**How to apply:**
1. Before hunting a filed rate, `git merge-base --is-ancestor <fix-sha> <base>`
   for every fix mentioned anywhere on the issue — including fixes for the
   issue's OTHER faces.
2. If any landed since, say so **first** in the report and on the board: the
   old numbers are provenance, not a prediction.
3. Then compute the arithmetic on your own measurement. 0 reds in 120 at a filed
   1/20 is `(19/20)^120` = 0.21% — that is evidence the rate MOVED, not evidence
   you were unlucky, and it is still not evidence the mechanism is gone. Report
   those three as three separate claims.

Sibling of "an issue can be outrun by a sibling milestone" (that is the CODE
being already fixed; this is the NUMBERS being measured on the pre-fix tree) and
of [[read-the-measured-sha-not-the-default-tree]]. Pairs with
[[load-knob-must-be-proven-to-bite]] and
[[base-rate-is-over-cell-executions-not-suite-runs]].

**SECOND FACE — IT IS NOT ONLY RATES, IT IS ANY QUOTED ARTIFACT (2026-08-21,
releases#196).** The filing quoted a docstring as its evidence: the verb "creates
the restriction if absent", therefore the precise arm violates it. That sentence
had ALREADY been replaced — by `f2d215a5`, the fix for the SIBLING issue the
filing itself cites as its boundary, an ancestor of the base I was told to read
at. Half the fork was discharged before I opened the file, and a build that
"restored" the quoted semantic would have re-broken a corrected docstring.

An issue quotes code AT FILING TIME. The quote is a snapshot wearing a citation's
clothes, and it is quoted precisely because it is load-bearing — so a stale one
mis-shapes the whole task, not a detail of it. Same discipline as the rate:
merge-base every fix named ANYWHERE on the issue (its own other faces, and the
siblings it names as boundaries), then **re-read the quoted text at your base**
and report "already discharged" as its own finding, first, before the work.