adding-product-alerting

Compose the shared platform instead of building a product-local framework: define the product contract, add persistence, build a lifecycle adapter over the shared state machine, configure HogFunction destinations, and reuse shared scheduling helpers. The adopting-platform-alerting reference walks through each step.

Extend shared infrastructure only when a real second adopter needs the same capability. Keep changes product-owned when there is no second use case, when a helper would need product-name branches, or when the option leaks product model fields into the shared state machine.

No. The lifecycle module in products/alerts/backend/state_machine.py is pure Python with no Django imports. Every persisted state or consecutive_failures write must go through the product adapter's single apply_outcome function, enforced by a semgrep rule.

Produce internal events, flush once per batch, then check producer acknowledgement before persisting notification-dependent transitions. Restore pre-check outcomes for unacknowledged events, since acknowledgement confirms production to the transport, not downstream destination delivery.

There is no generic alert base model, product registry, push-mode submit_check, generic scheduler runner, or generic Temporal harness. Non-insight products keep evaluation, persistence, due queries, history, and orchestration product-owned until a shared contract lands.