The delivery seam a fired timer job goes through - the run-liveness check st-ADR-0054 decision 4 requires, plus the feed-back itself.

Spec 6.2 says a delayed send whose session terminated before the delay elapsed MUST be discarded without delivery. Inside statifier-ex, Statifier.Session.terminate/2 satisfies that by cancelling every live timer ref before the process exits; a durable scheduler survives process death by design, so nothing plays that role for a stored job. What replaces it (st-ADR-0054 decision 4): before feeding the fired event back, the host MUST establish the run is still live and discard otherwise. The guarantee is enforced here, at delivery time - a cancel-on-run-end hook may keep the store tidy but is never load-bearing, because the node death durability exists to survive takes the hook down with it.

Whether a run is live is the host's question, not this package's: a host running Statifier.Session processes answers it from the session registry and Statifier.Session.status/1 (StatifierOban.Timer.Delivery.Session, the default), while a process-less host driving Statifier.Interpreter against persisted positions answers it from whatever it stores as the run's terminated/halted state and feeds the event into its next drive. That is why this is a behaviour: StatifierOban.Config carries the implementation (:delivery), and the scheduled job carries it to the worker.

Implementations must be idempotent under redelivery: jobs in this package are at-least-once, so deliver/2 can run more than once for the same fired timer.