Distributed Job Scheduler  ·  View 17 of 20  ·  Operations

Trigger Lifecycle

Seven states, and why the loop only closes if the tenant can see lateness.

Editable source SVG draw.io All views
Declared validated, versioned Indexed next instant computed Decided instant claimed Dispatched at-least-once Accounted outcome or unknown Observed lateness published Amended or paused new version Trigger one version at a time recompute clock gate commit then send callback window per-trigger view tenant acts revalidate Trigger Lifecycle — The Loop That Has to Close Application we own Data store Decision point Security / platform The loop closes because the tenant can see lateness. Without the observed step, a trigger that drifted would only be found by a customer. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • The observed step is on the ring, not beside it. Without a tenant-visible lateness view, a trigger that has drifted is only found by a customer (ADR-13).
  • An amendment revalidates rather than mutates: a new version re-enters the loop at declared, so the next instant is recomputed under the new rules (ADR-05).
  • Accounted includes unknown as a terminal state, so the loop closes even when the executor never answers (ADR-12).

Assumptions

  • A callback window short enough that overlap control can treat unknown as finished without routinely allowing concurrent execution — the choice Question 6 in the ask leaves open.

Risks

  • The loop assumes the tenant looks. A per-trigger lateness view nobody opens is the same as no view, which is why the tenant-facing alert in view 05 matters more than the dashboard.