Triggers and accumulation mode

When should a window's result be emitted, and how must the trigger mode match the sink?

Once results are provisional, when to emit a result becomes a separate question from what to compute. A trigger is the rule that decides when a window's result is emitted. Relative to the watermark there are three classes:

Class	When	Character
Early	Before the watermark reaches the window end (for example every minute)	Speculative, incomplete, low latency
On-time	When the watermark passes the window end	The declared-complete answer
Late	For each late record, or in batches, after on-time	Corrections

Accumulation mode: the knob people miss

The second knob matters more and is often missed: accumulation mode. When a window fires again, does it emit the new total or only the change since the last fire?

Accumulating: emit the new total (3,100, then 3,260). The sink must overwrite by key, so the sink must be keyed and mutable.
Discarding: emit only the delta (3,100, then +160). The sink must be additive and must have received every earlier fire exactly once.

So the trigger mode is really a statement about the algebra of the sink. Getting it wrong gives double counting that stays invisible until someone compares totals with the source.

Early firings carry an unstated contract

A dashboard whose count rises and then falls is not a pipeline bug. It is a consumer who was never told the number was provisional. That failure is informational, not technical, and no amount of engineering can fix it. Early results must be labelled as early.

Case, resolvedConstructed case · Kavya at Kitebox Deliveries

3,100 sent to finance, 3,260 the next morning

Rohan sent finance an hourly count of 3,100 that was really 3,260, because late uploads from courier phones without signal were dropped silently; once late data could update the number, the hour's total doubled the next day and the live count rose and fell. Where it started: Late data and triggers →

Dropped late data. She counts drops, and diverts records later than 1 hour to a side table. For records within the allowed lateness she keeps state for 1 + 60/60 = 2 hourly windows per key, which is cheap for hour-sized windows.
Doubled total. She makes the sink a keyed table, written by (depot, hour) with overwrite, and keeps accumulating mode. Now re-fires are safe, because writing the same key twice leaves one value.
The rising and falling count. She labels the panel "provisional until the hour is closed" and shows a small flag when the window has passed its on-time fire.