Make real-time uncertainty part of the commit protocol

Suppose a time API returns earliest and latest bounds with a contract that real time at that call lies between them. Their midpoint is an estimate; their width is uncertainty. The protocol must rely on containment, not merely on the historical frequency with which the midpoint was close. If a clock source is lost, the interval may need to grow or the service may need to stop making a time-sensitive claim. Keeping a narrow interval while the actual guarantee has failed makes the caller's otherwise correct interval comparison unsafe.

Two event intervals that overlap do not determine their real-time order. If one interval lies wholly before another, their actual times are ordered under the containment contract. This differs from happened-before: physical precedence alone does not establish a communication path. In a transaction system, the desired property concerns observable starts and completions as well as timestamps. Define those boundaries explicitly. A timestamp assigned during processing is not the same event as a client learning that its transaction completed, and uncertainty between these events is exactly what the waiting rule addresses.

In the Spanner design, a coordinator chooses a transaction timestamp subject to protocol constraints, including a lower bound related to the current latest possible time. It prevents the relevant commit from becoming observable until the time API can establish that the timestamp is in the past. The essential after test uses the earliest current bound: only when that bound exceeds the chosen timestamp is every possible current real time later. Checking only the midpoint or latest bound would leave some allowed real times on the wrong side of the timestamp.

The protocol also needs ordering of assigned timestamps, transaction locking and validation, replication, and the other commit rules described by the design. Waiting on a clock cannot make a partially replicated write durable, resolve a transaction conflict, or replace atomic commit. It supplies one real-time ordering fact inside that larger argument. Some waiting can overlap work already required for replication, so a synthetic uncertainty width is not automatically extra end-to-end latency added after all other work. Distinguish the condition that must eventually hold from a prediction of how a particular implementation schedules its stages.

If uncertainty is symmetrically bounded by epsilon around a steadily advancing estimate and the chosen timestamp equals the initial upper bound, the lower bound must advance by more than twice epsilon to pass that timestamp in the simplified model. Real systems can change uncertainty, choose a later timestamp for another reason, or overlap the wait with communication. Do not publish one universal fixed commit-wait duration. Monitor the health of the uncertainty contract and the chosen timestamp constraints, then measure how much waiting remains on the actual critical path under the deployed workload.

The root-finding lab illustrates what a valid bound means, not how clocks are synchronized. Reset, set both target c=2 and upper bound U=3, predict the bracket half-width after three bisections, then Step three times. The positive root remains inside a bracket whose midpoint error bound falls from 1.5 to 0.1875. This guarantee comes from the monotone quadratic and preserved bracket. A clock interval instead requires evidence about time sources and drift; numerical bisection cannot shrink it. The useful shared idea is that a decision justified by a bound depends on why the bound contains the unknown value.