Chainsaw: the time window bounds the hits

The window is part of the result

If the hunt was given a start and an end, every hit you see was inside that range, and hits outside it were not printed. The output does not repeat the bounds on each row. They live in the command or the job note. A result file without those bounds is an incomplete record of what was asked.

A row’s timestamp is the event’s time. It is not a substitute for writing the window. The timestamp tells you where that hit sits. The window tells you what was excluded.

Zero hits is inside the window

No rows means no rule hits in that window for the rules you ran. The log can still hold events before and after. A full-file search with no window is a different question. Do not describe a windowed zero as “the log is clean.”

Widening the window is a new run. Keep the old zero attached to the old bounds. Do not replace it with the wider count and drop the fact that the first run was narrow.

What to file

File the start, the end, the rule set you pointed at, and the hit count. If the bounds were not saved, write “window not recorded” and do not compare the count with a run whose window you do know. File timestamps on hits as event times, not as the window.

Worked case: a clean hour that was only an hour

A lab hunt used a start of 2026-11-03T15:00:00Z and an end of 2026-11-03T16:00:00Z and printed no hits. A draft says the Security log has no detections. A second run with no time limit prints six hits, all timestamped the day before.

The note keeps the first result as zero hits inside that one hour. It does not say the log is clean. The six hits are a different run with no window, and their event times are the day before, which the first window excluded. Both counts stay, each with its bounds.

run A: 2026-11-03T15:00:00Z to 16:00:00Z  hits: 0
run B: no time limit  hits: 6
event times on B: the previous day
write: the hour had no hits; the log was not fully searched in run A
not: the Security log has no detections