docs(ci-serialisation): mark the 99.3% baseline figure historical and correct why the ratio band is insensitive - #15
Open
sakanni wants to merge 1 commit into
Conversation
… correct why the band is insensitive The figure the implausible-baseline ratio was chosen against was the pre-fix serialiser. That defect was fixed on 2026-08-03, so a reader arriving at either copy of the text today is told the current baseline failure rate is 99.3% when it is at or near zero. The insensitivity claim is true and its stated reason was wrong. Any value from 0.25 to 0.90 does behave identically on everything observed, but because the two observed states sit at opposite ends of the band, not because a baseline cannot land between them. Failures and population are summed across three converter legs, so a defect confined to one produces an aggregate in the low tens of percent, which is exactly the region a value inside the band decides. No behaviour change: the default stays 0.5 and the guard is untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Comment-only. The default stays
0.5and the guard is untouched.Two things were wrong in the text that documents
implausible_baseline_ratio, in both places it is written: the code comment onDefaultImplausibleBaselineRatioand theci-serialisationaction input description.The 99.3% figure is historical and read as current. That baseline failure rate (5981 of 6024) was the pre-fix serialiser. The defect behind it was fixed on 2026-08-03 by the
System.Drawing.Commonreference inSerialiserRunner.csproj, and healthy baselines since then report at or near zero failures over a population of roughly six thousand. Anyone arriving at either copy of the text today is told the current rate is 99.3%. Both are now marked historical and dated to the fix.The insensitivity claim is true and the reason given for it was wrong. Any value from roughly 0.25 to 0.90 does behave identically on everything observed so far, but not because a baseline cannot land between those numbers. It is because the only two states seen to date sit at opposite ends of that band: near 0% with a healthy serialiser, near 100% with a globally broken one.
Intermediate states are reachable. Failures and population are summed across the three
Verifylegs, so a defect confined to one converter produces an aggregate in the low tens of percent rather than at either end. That is the region a value inside the band actually decides, which makes choosing inside it a choice about which partial states to refuse rather than a free one. The old wording obscured exactly that.