When buffer_duration_sec is set above 0, this Measurement stops publishing live: each collected sample is instead pushed into an in-memory ring buffer covering the last buffer_duration_sec seconds. A FlushEvent on flush_topic (published by a dc_triggers broadcast node when its Trigger fires) then drives one incident-capture cycle:

1. Buffering — the default, armed state: samples accumulate in the ring buffer and nothing is published. Only in this state does a FlushEvent start a cycle.
2. Flushing — the buffered window is published oldest first, each Record tagged with the event's incident_id and stamped with when it was collected, not when it was released. With max_flush_rate_hz left at 0 the whole window goes out in one burst; set above 0, it is emitted at no more than that many Records per second, so a robot recovering from an incident does not also have to absorb the entire window at once. The window is consumed, so the next incident releases its own history rather than replaying this one. Samples collected while a rate-limited release is still draining are buffered, not published, and so become part of the next incident's pre-roll.
3. PostRoll — for post_roll_duration_sec after the release finishes, samples are published live as they are collected, still tagged with the same incident_id, so the aftermath of the incident is captured too. It runs from the end of the release, not from the FlushEvent, so a rate-limited release does not eat into it. Left at its default 0, this phase is skipped entirely: pre-roll only.
4. Cooldown — for cooldown_sec after post-roll ends, further FlushEvents are ignored, so a flapping Trigger cannot produce a flood of overlapping incidents. Samples are buffered again during this phase, so the next incident still gets a full pre-roll window.

Files follow their Records. A Measurement that produces Files (camera, map, …) normally leaves them under save_local_base_path for the Bridge to upload as soon as the Record naming them is published — but an armed Measurement publishes nothing, so every File it produces while buffering (also during cooldown, and while a rate-limited release is still draining) is instead moved into a scratch directory beside the save path, <save_local_base_path>/.dc_incident_scratch/<measurement_name>/, and the buffered Record is rewritten to reference the staged copy. That scratch directory rolls on the same buffer_duration_sec window as the Records themselves: a staged File is deleted from disk at the same moment its Record ages out of the ring buffer, so an armed Measurement's Files stay bounded instead of accumulating images no Record will ever carry to the Bridge. On release the staged copies are handed on with the Records referencing them — remote_paths is untouched, so each File uploads to exactly the Destination key it was collected under — and the scratch ring stops tracking them, leaving the Bridge's usual retention sweep and delete_when_sent to clean them up. The Bridge needs no configuration for any of this: a released Record is an ordinary Files Record that happens to be older than usual. Files collected during PostRoll are published live and never staged at all.

The Measurement then re-arms itself back to Buffering with no manual intervention — a second incident is captured exactly like the first. With both post_roll_duration_sec and cooldown_sec left at 0, a flush releases the pre-roll window and the Measurement is armed again immediately.

incident_id is a top-level field of the Record envelope, beside tags, run_id and name — not a key nested inside the measurement's own data — so a postgres Destination stores it in its own incident_id column and "everything from this one event" is a plain WHERE incident_id = '…'. See Destinations for the column the table needs. A Record collected outside an incident carries no incident_id at all, leaving the column NULL. A Group lifts a member's incident_id onto the merged Record the same way it does tags, so grouping does not bury it.

gate_condition is a one-shot arming latch: it names a single Condition plugin (any type under dc_measurements/plugins/conditions/) that suppresses every collection — including the init_collect Record normally published on activation — until that Condition becomes true for the first time. Once armed, the Condition is never consulted again for the lifetime of the node, even if it later becomes false again; re-arming does not happen. This is unlike if_all_conditions/ if_any_conditions/if_none_conditions, which are re-evaluated on every collection and can suppress publishing again once their Conditions change. If the named Condition doesn't exist among condition_plugins, collection is held back permanently and an error is logged.

The three lists are evaluated on every collection and ANDed together: if_all_conditions objects unless every Condition it names is active, if_any_conditions unless at least one of its Conditions is active, and if_none_conditions unless every Condition it names is inactive. A list left empty never objects, so a Measurement naming no Condition at all always collects. A name that is not among condition_plugins reads as inactive and an error is logged: it blocks collection when listed in if_all_conditions or if_any_conditions, and is accepted by if_none_conditions.