A watermark is a progress claim with an input policy

Event time is a timestamp attached to the event under the application's definition, such as when a sensor sampled a value. Processing time is when an operator executes work according to its local clock. Network delay, batching, retries, and replay can put those times far apart. Event-time aggregation can preserve an intended temporal grouping despite changed arrival order, but only if timestamps, progress policy, and retained state support it. A watermark is not a measurement that all producers share synchronized clocks, and it does not repair incorrect timestamps.

A bounded-out-of-orderness strategy can derive a watermark from the largest timestamp observed minus a configured tolerance, with implementation-specific discrete-time details. This is a strategy, not a proof that no older event exists. A producer outage or delayed partition can violate the expectation. Name the timestamp units and boundary convention when computing examples; a one-millisecond adjustment can matter at a window edge. Watermarks also differ from checkpoint barriers: one advances event-time decisions, while the other coordinates a recoverable computation cut. Receiving either is not itself an external output commit.

An operator combining inputs generally advances using the minimum relevant input watermark, so a fast input cannot unilaterally certify progress for a slow one. Flink 2.1's source idleness support can mark an input idle after a configured lack of activity, excluding it from that minimum while it remains idle. Without such a policy, a silent partition can stall event-time windows indefinitely. With it, other inputs can progress, but the silent partition has not been proven complete; a later resumption can bring events behind the advanced watermark.

An idle timeout is therefore a liveness-versus-completeness policy with a defined clock and observation point. Check whether silence means no business activity, a failed reader, backpressure, or a broken source. Late resumed events need a chosen disposition: update retained state, route to an audit path, or reject according to the contract. Watermarks are monotonic progress at an operator; resuming an old input cannot simply rewind already emitted results. Watermark alignment is another mechanism that can constrain fast sources to limit buffering skew, and should not be confused with checkpoint-barrier alignment.

Monitor per-input event-time progress, processing-time inactivity, source lag, idle transitions, and late-event outcomes. A high output watermark after excluding one input can make a latency dashboard look good while that input's customers wait for corrections. Report completeness policy alongside freshness. Tests should pause one partition, advance another, resume the paused partition with an old event, and inspect both initial output and late handling. This trace tests the actual contract more directly than verifying that a watermark counter eventually increases.

The Markov lab models availability labels only as an exact two-state thought experiment. Reset, set BOTH p=0.2 from active state 0 to idle state 1 and q=0.3 back, predict idle probabilities 0.2 after one transition and 0.3 after two, then Step twice. One Step advances one transition because n=floor(2t). Edits retain t and recompute from initial active state. The displayed stationary idle probability is 0.4, not a measured idle rate. There are no timestamps, timeout detector, minimum watermark, or sampled source failures; this model cannot justify excluding a real input.