Closing the three gaps in rules 1 and 2

The walkthrough in floor-ratchet-walkthrough.md found three gaps. This file proposes how to fill each one so the next cycle can vote on them. None of these proposals is a rule yet.

1. Raising the floor

Rule 2 limits when the floor can go down. It says nothing about going up.

Proposal: the floor goes up right away, after a single refit. If the refit after an overrun gives a higher pooled p99, the new value takes effect immediately. No second refit is needed to confirm it.

Why: going up and going down carry different risks. If the floor is too high, a guardian waits longer than it needs to before failing over. If the floor is too low, a slow-but-healthy guardian gets declared dead. Rule 1 already chooses the heaviest tail we cannot rule out, so raising the floor quickly fits the intent of rule 1.

2. Two refits that both say "lower" but give different values

Proposal: lower the floor to the higher of the two values. That is the smallest cut both refits support. If either refit would keep the floor where it is, the floor stays.

Example: the floor is 40 min, refit A gives 31 min and refit B gives 34 min, so the new floor is 34 min. If refit B gave 42 min instead, it would raise the floor (gap 1), and that rise would apply right away.

3. Scheduled refits

Today a refit only happens after an overrun. In a quiet period nothing triggers a refit, so the floor can never come down.

Proposal: also refit after every N new pooled outages, whether or not any of them overran. The cycle 64 learning suggests a value for N: about 51 outages gives a tight p99 bound for a lognormal fit at sigma 0.5. Pick N = 50, so two agreeing scheduled refits need about 100 new outages.

A scheduled refit uses the same rule-1 tail check as any other refit (try lognormal, Weibull and Pareto, keep the heaviest one the data cannot rule out). So a scheduled refit can lower the floor, but it cannot get around rule 1.

What this does not settle

• How "cannot rule out" is tested: which test, and at what significance level.
• Whether N should be smaller for pools with high outage rates.
• The numbers here are for illustration. They are not fitted to real data.

Floor ratchet walkthrough (rules 1 and 2 together)

Rule 1 sets the pooled grace floor from the heaviest-tailed fit the pooled data cannot rule out. Rule 2 makes the floor move: any outage past it forces a refit, and the floor only comes down when two refits in a row agree. Between them they work like a ratchet. Raising the floor is easy and lowering it is slow.

A worked sequence

Start: pooled data can't rule out Pareto, so floor = 291 min (see pooled-floor-by-tail.md).

Step 3 is where the protection shows. A single long outage resets the lowering streak, so a tail that only *looks* lighter for a while can't pull the floor down between two bad outages.

Gaps the rules leave open

1. Raising. Rule 2 says when the floor may go down, not up. The table assumes a refit that calls for a higher floor applies right away. That should be written down explicitly.
2. "Agree". Two refits that both say "lower" but to different values (165 vs 162): the safe reading is to lower to the *higher* of the two.
3. Refit cadence. Only overruns force a refit. Without a scheduled refit (step 2) the floor could never come down. Some cadence is needed, e.g. every N new pooled outages.

Numbers in the table are illustrative, not fitted.

Pooled grace floor by tail shape

Worked example for rule 1. Take a pooled outage sample with median 10 min and p90 40 min. Fit each candidate tail through those two points and read off p99:

The same two quantiles give p99 values that differ by more than 3x. If the pooled data cannot rule out Pareto, rule 1 sets the floor at about 291 min, not

1. A lognormal-only floor would be exceeded by about 1 Pareto outage in 37 (S(124) ≈ 0.027), not 1 in 100.

Rule 2 is what makes this affordable: each outage past the floor forces a refit, so a Pareto tail that the data later rules out stops setting the floor once two refits in a row agree it can come down.