Choose when to answer and how an answer can improve

The original Dataflow model separates what is computed, where event-time grouping occurs, when results are emitted, and how successive results relate. These are useful design questions rather than a promise that one implementation solves every source's uncertainty. An early processing-time trigger can improve time to first answer while a later event-time result reflects a more mature input set. Label provisional and revised results so consumers know whether to act immediately, wait, or reconcile. A watermark-based on-time result still inherits the source strategy and allowed-late-data policy.

Choose a stable identity such as key plus window bounds and a result version. A replacement consumer updates one result; a delta consumer applies a declared change; an append-only consumer may need explicit retractions. Without that contract, a sequence of increasingly complete sums can look like several independent business totals. Event-time lag, processing latency, and wall-clock freshness describe different things. Record what the user sees at each stage, including whether delayed sources are absent, rather than reporting only the speed of the fastest initial emission.

An observed arrival-delay distribution can inform a lateness tolerance, but it reflects the sampled workload, clock quality, outages, and observation period. A 99th-percentile delay does not imply that a window containing many events has a 99-percent chance of being complete, especially when outages correlate delays. Define whether completeness means event count, value contribution, source coverage, or absence of a particular important event. The same count of missing events can have very different business impact. Treat rare slow-source behavior as part of the failure envelope, not noise to remove from a convenient percentile.

Waiting or retaining longer can recover more late data at the cost of state, revisions, and possibly delayed decisions. Incremental aggregates can reduce payload but still need timers, keys, and correction metadata. Source retention and sink update capability limit what later reconciliation can accomplish. A consumer that cannot retract an earlier action may require a conservative gate before acting rather than a fast provisional number. Measure the actual objective—useful decision time at a stated completeness level—alongside processing cost and correction frequency, so a faster incomplete output is not silently counted as the same product.

Use a trace with ordinary out-of-order arrivals, an idle source, a burst of delayed events, a recovery, and data arriving after retention expires. Compare initial output latency, eventual accepted result, correction count, rejected late value, state footprint, and external effect invariants. Preserve reference data for reconciliation where the contract needs a later authoritative answer. A change that reduces state by discarding more late events should be reported as a changed completeness policy, not solely an optimization. Document the chosen horizon and the evidence that supports it for this workload.

The probability lab tests the independence illustration. Reset, set BOTH p=0.95 and n=20, predict the all-success bar at about 0.3585, then Play or Step. Reset and re-set BOTH p=0.99 and n=20; predict about 0.8179. Edits retain t, and playback tours exact probabilities rather than generating arrival delays. There are no windows, watermarks, correlated outages, or business values. The comparison shows why a high per-event on-time fraction can still leave many multi-event groups incomplete; a real policy needs measured delay and source behavior beyond this toy assumption.