The load-bearing part of the design is the direction of travel. Each act in the pipeline is allowed to claim less than the act before it, and none of them can argue the deterministic reducer into a stronger verdict [7]. The model gathers candidate observations; it does not decide what those observations prove [13]. Every accepted observation has to match the evidence schema, pure reducers map records to a claim, and missing or conflicting evidence returns an honest partial result instead of a guess [14]. Issue text and repository content enter as untrusted input [14]. The same records always produce the same verdict [15].
This is a scoring rule: it rewards evidence crossing a threshold, not a convincing writeup. It also explains why the failed, partial and unresolved runs stay in the ledger alongside the successful ones [4]: a reducer that only sees the runs supporting the story is a reducer you can lie to by selection.
Now the number. Ten stalled runs and ten responsive controls is twenty executions in total [11][21]. For a request that never resolves, that split is about as clean as a differential gets, and the author's point about the control half holds: one condition that fails every time next to one that never fails carries more weight than twenty failures with nothing to compare them to [20]. For an intermittent bug the same threshold says much less. If a condition truly fails one run in ten, ten runs miss it entirely about 35 percent of the time, since 0.9^10 is 0.349 [22]. Ten is a budget tuned to deterministic conditions, and the budget is exactly the thing the maintainer approves before Hunter starts [4].
Transferring this record to your bug depends on three conditions holding. The trigger has to be expressible as a knob in an approved condition matrix [4]. The failure has to surface inside the runtime of an approved command [14]. A contrasting control has to exist that holds everything else fixed. TrueForge issue #417, where snapshot registration can wait indefinitely when an upstream request never resolves, satisfies all three under a pinned provider [8][9]. A race that only appears across several services under production traffic satisfies none of them, and the harness would be expected to return partial rather than wrong [14].
The field I would keep is `runtimeReproducedByThisWorkflow: false` [19]. The provider run reproduced the bug; the CI workflow verified the harness and published a proof anyone can check; collapsing those two into one vague "verified" flag would erase the boundary between them [19]. It is the rarest key in any pipeline output. The same restraint shows in the interactive workspace, which is labelled a conceptual fixture with every generated value marked, rather than dressed up as live runtime evidence [17].
The honest limit is sample size: one issue, one pinned provider, one author's own writeup [8][9]. What the artifact does establish is a cheaper comparison than benchmark tables usually allow. A plausible explanation of a stack trace costs one model call [23]. A ledger with its unresolved runs intact, a maintainer-approved command budget and a recomputable hash costs twenty runs and an approval [11][16]. The ledger is the one worth reading, because it is the one that scales.
