How many different screens can one component settle into, when the responses it asked for arrive in a different order?
The measurement. For a blotter whose rows and whose header exposure figure come from two endpoints, the answer is 4, and every figure on every one of them was computed and sent by the server. With the flag react.dev documents applied to both requests it is 1. One ordering settles with 41 position rows under a header reading "128 positions, 4.82m net", with no spinner, no error and nothing stale in the sense anybody checks for.
What this adds to fast-check, which is not much and is the point. fc.scheduler already permutes delivery orders and already shrinks a counterexample, and none of it is reimplemented. What it does not ship is cardinality: fc.assert answers is there an ordering that breaks this and stops at the first. The question here is how many distinct screens can a user be shown.
The unit of comparison is the accessible tree, never innerHTML and never a screenshot, so a refactor cannot satisfy the property. A screen whose elements have no accessible names cannot be described by that fingerprint, so that is a precondition, checked with four axe-core rules and watched refusing a subject written to fail it.
Two properties, four subjects, one per quadrant. The control passes both and finds nothing, which is what makes every other number falsifiable. The risk panel is the sharpest: perfectly deterministic and perfectly wrong.
And two wirings this harness cannot fully see. A library that schedules its own work is partly outside the explorer, so no count for those is committed, because an evidence file carrying a number that moves is one people delete.
Verification. 2 required status checks, one of which reproduces the counterexample in real Chromium and checks the control holds there too.