The discriminator claimed "exact across all seven" while r07 is recorded lower down as "inconclusive rather than ruled out, because no evidence came back from it." A row this page calls inconclusive can't also be counted as evidence for the conclusion.
Checking it found a second instance R29 didn't name
The abort-cadence section said "Measured across the seven runs above" — but the table records r07's aborts as not readable, because adb wedged before a crash buffer could be taken. Six runs contributed gaps, not seven.
Both now say six, and both say why.
What excluding r07 costs: nothing, and the doc now says so
r07 is a host row, so the discriminator predicts it wouldn't boot. Confirming a prediction with the one run whose evidence didn't come back adds no information either way. That's the point R29 made — claiming six doesn't weaken the conclusion — and it belongs in the document rather than only in the ticket, because the next reader would otherwise wonder whether a run was quietly dropped.
Deliberately left
four of the seven runs show the directory creation itself is broken during the loop
That's a count of how many runs showed something, not a claim that all seven were readable for it. It survives. Checked rather than assumed, and named here so the next pass doesn't re-audit it.
Not taken
R29's other option — "state how r07's boot outcome was read" — because I don't know, and inventing a source would be worse than narrowing the claim. Narrowing is the option R29 offered and the one that can be honest.
Closes #38 (R29).
The discriminator claimed **"exact across all seven"** while r07 is recorded lower down as *"inconclusive rather than ruled out, because no evidence came back from it."* A row this page calls inconclusive can't also be counted as evidence for the conclusion.
## Checking it found a second instance R29 didn't name
The abort-cadence section said *"Measured across the seven runs above"* — but the table records r07's aborts as **not readable**, because adb wedged before a crash buffer could be taken. **Six runs contributed gaps, not seven.**
Both now say six, and both say why.
## What excluding r07 costs: nothing, and the doc now says so
r07 is a `host` row, so the discriminator *predicts* it wouldn't boot. Confirming a prediction with the one run whose evidence didn't come back adds no information either way. That's the point R29 made — claiming six doesn't weaken the conclusion — and it belongs in the document rather than only in the ticket, because the next reader would otherwise wonder whether a run was quietly dropped.
## Deliberately left
> four of the seven runs show the directory creation itself is broken during the loop
That's a count of how many runs *showed* something, not a claim that all seven were readable for it. It survives. Checked rather than assumed, and named here so the next pass doesn't re-audit it.
## Not taken
R29's other option — *"state how r07's boot outcome was read"* — because **I don't know, and inventing a source would be worse than narrowing the claim.** Narrowing is the option R29 offered and the one that can be honest.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #38 (R29).
The discriminator claimed "exact across all seven" while r07 is recorded lower down as "inconclusive rather than ruled out, because no evidence came back from it." A row this page calls inconclusive can't also be counted as evidence for the conclusion.
Checking it found a second instance R29 didn't name
The abort-cadence section said "Measured across the seven runs above" — but the table records r07's aborts as not readable, because adb wedged before a crash buffer could be taken. Six runs contributed gaps, not seven.
Both now say six, and both say why.
What excluding r07 costs: nothing, and the doc now says so
r07 is a
hostrow, so the discriminator predicts it wouldn't boot. Confirming a prediction with the one run whose evidence didn't come back adds no information either way. That's the point R29 made — claiming six doesn't weaken the conclusion — and it belongs in the document rather than only in the ticket, because the next reader would otherwise wonder whether a run was quietly dropped.Deliberately left
That's a count of how many runs showed something, not a claim that all seven were readable for it. It survives. Checked rather than assumed, and named here so the next pass doesn't re-audit it.
Not taken
R29's other option — "state how r07's boot outcome was read" — because I don't know, and inventing a source would be worse than narrowing the claim. Narrowing is the option R29 offered and the one that can be honest.