Environment Noise and Circuit Breaker Classification

When the network is bad, does the system wrongly blame “C-channel execution noise”? Two scripts: an original and a revised rule.

PurposeMeasure how often network trouble is classified as C-channel execution noise, and test a rule meant to reduce that.

StatusCannot show improvement — the count is real, but the sample has no true execution noise, so a rule that never fires would score best.

Meaning of “false positive”A session whose cause was the network but which was classified as C-channel noise. The script uses the term this way throughout.

SampleOriginal: 40 sessions. Revised: 60 sessions. Both draw latency and packet loss at random.

Touches NCFCA codeNo. The “current system logic” is a simplified rule written inside each script, not the real circuit breaker.

CorrectionAn earlier version of this page misread the script’s counter as true detections. It counts network trouble wrongly blamed on the C channel, as stated above.

AttributionCode AI-generated (tool not recorded). Run in the lab; results unchanged.

ReviewedBy no outside party. The reading below was done when this page was built, directly from the code and CSV.

Original script (40 sessions)

16 sessions have a network issue. 6 are classified as C-channel execution noise, all of them with an issue, so 6 of 16 network issues (37.5%) are misattributed. The script prints “VULNERABILITY: System frequently mistakes network problems for execution noise”, which fires on a cutoff of “more than 5”. No session without a network issue is classified as C.

Revised script (60 sessions)

26 sessions have a network issue (latency above 900 ms or packet loss above 0.18).

	Network issues blamed on C	Share of the 26
Old rule (latency above 1200 or loss above 0.25)	18	69%
New rule	9	35%

The script reports this as a 50% reduction in false positives. The arithmetic is right.

What the data show

The new rule’s only effect is a higher packet-loss cutoff. It adds a “network quality” clause, but that clause reduces to “latency above 1000”, and no session in the sample exceeds 892 ms. In practice the rule changes the loss cutoff from 0.25 to 0.30.
The sample has no genuine execution noise. Every rule fires only above thresholds higher than those that define a network issue, so every firing is by construction a misattribution. A rule that never fires would show a 100% reduction.
The cost of the new rule, missing real execution noise, cannot appear in this data.
The simulation draws latency from an unclipped normal distribution, and session 10 of the revised run has a latency of −86 ms.

What it shows

That moving a threshold up reduces how often network trouble is blamed on the C channel. It is a sensible direction to test properly.

What it does not show

That the new rule is an improvement. That needs a labelled mix of network trouble and real execution noise, and a measure of both kinds of error.
Anything about real traffic, or about the real circuit breaker.

Download (unchanged from the lab’s run): environment_noise_test.py · environment_noise_results.csv · environment_noise_detailed_test.py · environment_noise_detailed_results.csv
The scripts write to a path from the lab’s own machine (/home/workdir/artifacts/); change it to run them elsewhere. Each uses seed 42, so a rerun reproduces the CSV.