The light ceiling's population floor reads a prose count, but its own published 95th percentile forces a population of 60 #3200

RefreshCeilingProvenancePinTests.PopulationFloor (#3195) is applied at two sites that are not equally guarded, and #3195's description states that asymmetry as an inherent bound rather than a deferred one:

• HeaviestHourlyRefreshObservedCeilingSeconds — the floor reads a parsed population.Length over readings the summary actually lists. It cannot be satisfied by a claim.
• OtherHourlyRefreshObservedCeilingSeconds — the floor reads the census sentence's count, over a population the summary deliberately does not republish ("a list that long stops being re-derivable by reading and starts being a wall of digits"). A re-derivation stating over 900 runs while having read four satisfies it. The only corroboration is the exclusion-control sentence, which states the same figure a second time — two prose claims agreeing with each other.

That gap can be closed at the light site with figures the file already parses, and without republishing anything. The count stops being an unconstrained claim and becomes one leg of an arithmetic relationship between three independently pinned figures.

The derivation

The light summary publishes, in three different sentences, all three already pinned and all three already read into Verify:

The summary also publishes the three largest readings — 226.8, 160.4, 140.1 — and Verify already pins their ordering (midnightMax == lightMax, previousNight < lightMax, thirdLargest < previousNight).

The stated 95th percentile is 42.2 s, below all three. Under nearest rank that is not free — it forces a minimum population size:

• the p95 value sits at 1-based index r = ceil(0.95n), which is what NearestRank computes;
• three published readings are strictly above that value, so at least three members sit above index r, i.e. n − r ≥ 3;
• ceil(0.95n) ≤ n − 3 ⟹ 0.95n ≤ n − 3 ⟹ n ≥ 60.

Checked against NearestRank's own integer form: at n = 59 the rank is 57 and 59 − 57 = 2; at n = 60 the rank is 57 and 60 − 57 = 3. So 60 is the first admissible size, and at the real 874 the rank is 831 with 43 readings above it — comfortably consistent.

So the light site's floor is 60, not 20, and the third of that is bought with no new extraction.

Why this closes the gap rather than restating it

The count is no longer corroborated by a second sentence stating the same number. It is constrained by a relationship among three figures pinned from three different sentences, and to pass, a thin census has to fabricate all three consistently rather than one. A re-derivation that honestly read four runs cannot state a 42.2 s 95th percentile at all: at n = 4 the nearest rank is 4, so the p95 is the maximum.

Concretely, #3195's own successful mutation is caught by this. That mutation cut the census from 874 to 4, rewriting the count sentence and the filter-control sentence consistently, and was green across the whole file before #3195 and green on the quantile clauses after it — the quantile and third-largest sentences were never touched. Under this check, 42.2 < 140.1 demands runs ≥ 60, and 4 is not. That claim is verifiable by re-running exactly that mutation, and it should be verified rather than taken.

It generalises PopulationFloor rather than competing with it

Both are the same search with a different threshold on n − NearestRank(1..n, 95):

• ≥ 1 — the p95 is a different reading from the maximum → 20, which is PopulationFloor exactly;
• ≥ 3 — three published readings sit above the p95 → 60.

So derive it the same way PopulationFloor is derived — searched with NearestRank itself, bounded, never written as a literal — and drive the threshold from how many published tail readings actually exceed the stated 95th percentile, counted rather than assumed to be three. If a future re-derivation raised the p95 above the third-largest, the count drops and the bound weakens correctly, because fewer readings above the percentile really is less information about n. PopulationFloor stays as the floor under it: at a count of zero the derived bound degenerates to 1 and the 20-draw floor is the only thing holding the line. Neither weaken nor remove PopulationFloor.

The store-backed route does not work, for two independent reasons

OtherHourlyRefreshRuntimesSql (#3182) is the read that can attribute a live run to one of the twelve non-heaviest hourly views, and that is exactly what it does — a run, singular. It joins timescaledb_information.job_stats USING (job_id) and projects js.last_run_duration, and job_stats carries one row per job. So it returns at most twelve rows, each that view's most recent successful run. It cannot count runs and it cannot measure a span. The premise fails at the instrument, one level above the GUC question.

The read that can count is timescaledb_information.job_history, which is what the census itself used — one row per run. Two things stop it corroborating this count:

1. The honest-empty problem, which the constant's own summary already states: the view only records executions while timescaledb.enable_job_execution_logging is ON; that GUC defaulted off and could not be healed onto a pre-existing cluster until job_history is silently empty on clusters predating ~2026-08-17, because its GUC lives in the one postgresql.conf block EnsureConfAppended cannot heal #3175/Give timescaledb.enable_job_execution_logging its own conf marker, so existing stores can heal (#3175) #3177 gave it a marker; and a count or a maximum over it on an unhealed store returns zero rows, which reads as "nothing exceeded the line". Any check would have to report the GUC's effective value and source distinctly from the row count — DarlingStoreMetricsReader.GetJobExecutionLoggingAsync and DarlingMcpStoreMetricsTools.JobHistoryNote already do exactly that, so the machinery exists.
2. The population mismatch, which is fatal on its own. This census is scoped by a positional exclusion rule to runs starting after the 13:44:23 narrowing boundary, and job_history records only from whenever logging was switched on. A live count is therefore a count over a different population, and the summary says so in its own words: "neither is comparable with a sweep over a store's whole job history, because the boundary is there because runs before it worked an unnarrowed HourlyRefreshStartOffset." Comparing them is the cross-regime comparison the constant's own doc warns about, and its stated direction is that a boundary-scoped constant reads as understated by a factor.

So a store read cannot make this count a measurement. What can is arithmetic over what the summary already publishes — which needs no store, no GUC, and no honest-empty handling.

Scope

• Raise the light site's effective floor to the derived value, from figures already in hand at that point in Verify.
• Keep PopulationFloor and its minimality assertion untouched.
• Do not republish the 874 readings — that contradicts the summary's own stated reasoning and trades this weakness for a worse one.
• Update Require a population large enough for a maximum to bound anything (#3193) #3195's stated-bound paragraph, which currently says the gap "cannot be closed here". Once the count is arithmetically constrained, that sentence is the thing most likely to be read later as still true.