sigma-cli: timeframe is not the search window

Timeframe belongs to the rule text

Some detections include a timeframe, a span such as 15m that the author attached to a count or a sequence. That span is part of the rule as written. It tells you how the author grouped events inside the detection. It is not a receipt for the search you submitted.

A rule with no timeframe has no author span. Do not invent 15m because other rules in the folder use it.

The bounds are what the search used

The earliest and latest times on the search, or the equivalent range in the query you ran, are the window that produced the count. A day-long range can return rows even when the rule text says 15m, and a 15-minute range can be what you ran even when the YAML says something longer.

If the printed query dropped the timeframe, say that the author span was not in the text that ran. The count then belongs to the bounds you set, not to the span in the YAML.

What to file

File the rule id, the timeframe from the YAML if there is one, and the earliest and latest bounds of the search that returned the count. If you describe a rate, say which of those spans the rate uses. Do not call a full-day count a 15-minute count.

Worked case: a day of heartbeats called a 15-minute burst

The lab heartbeat rule sets timeframe to 15m. The search that was run used earliest 2026-11-03T00:00:00Z and latest 2026-11-04T00:00:00Z and returned 9 rows, spread through the day. A draft says the sensor saw a 15-minute burst of 9 heartbeats.

The note quotes 15m as the span in the rule text and the two bounds as the span that was searched. The 9 rows are a count for that day-long search. They are not a burst inside 15 minutes. A 15-minute claim would need bounds that actually cover 15 minutes, or a query that still applies the author span, which this run did not.

rule timeframe: 15m
search earliest: 2026-11-03T00:00:00Z
search latest: 2026-11-04T00:00:00Z
rows: 9, spread through the day
write: 9 rows for the day-long search
not: a 15-minute burst