A branch-transfer telemetry stream logs each time a crated artifact passes a loading-dock scanner during an inter-branch loan move. The reporting requirement is a strict, non-overlapping count of scans per fifteen-minute block for the whole day, where each scan counts toward one and only one block. Which windowing function is the correct fit?

A tumbling window partitions the timeline into fixed-length, back-to-back, non-overlapping segments, so every event is assigned to exactly one window and the windows collectively cover the entire period with no gaps and no overlap. A fifteen-minute tumbling window applied to loading-dock scan events produces exactly the strict, mutually-exclusive per-block counts the reporting requirement describes.

A sliding window re-evaluates continuously as events arrive rather than emitting one value per fixed fifteen-minute block, so it does not produce the discrete, once-per-block counts the requirement calls for. A hopping window with a fifteen-minute duration and a five-minute hop deliberately overlaps consecutive windows, meaning a single scan could be counted in as many as three separate fifteen-minute windows, which directly breaks the 'one and only one block' rule. A session window's boundaries are defined by gaps in activity rather than a fixed clock, so it would produce a variable number of variable-length groups depending on scan frequency, not fixed fifteen-minute reporting blocks.

A caveat: a scanner outage that produces zero scans in a given fifteen-minute block still needs to be represented as a zero-count row for the report to be complete, which some tumbling-window implementations require an explicit fill-in step to achieve. Operationally, verify correctness by summing every fifteen-minute block's count for a day and confirming it equals the total raw scan count for that day with no over- or under-counting.