No-Code SaaS Automation Platform  ·  View 14 of 21  ·  Runtime

Step Lifecycle by Replay-Safety Class

The same five stages, three times, because the guarantee the platform can offer depends entirely on what the provider supports.

Editable source SVG draw.io All views
Bind inputs Mint effect key Call provider Ambiguous outcome Terminal state Idempotent By reference Provider honours key Key on the request Retry, same key Done exactly once Checkable By reference Natural key Plain request Read back first Done, verified Unsafe By reference No key available Plain request Park, ask the author Gap or duplicate Step Lifecycle by Replay-Safety Class The third lane is the honest one: the platform cannot make it safe, so it surfaces the choice instead of guessing. v 1.0 · owner Integration Platform Architecture · date 2026-10

What this view proves

  • The three lanes diverge at exactly one stage — the ambiguous outcome — and converge nowhere. That is why replay safety is a stored property of an action rather than a platform-wide retry policy.
  • The third lane is the honest one. For an action with no idempotency key and no read-back, the platform cannot deliver at-most-once visible effect, so it parks and surfaces the choice rather than guessing on the author's behalf.
  • Automatic retry of an ambiguous outcome is forbidden in the unsafe lane. That is a refusable requirement, and it is the reason the class exists at all.

Assumptions

  • ≤ 1 duplicate visible effect per 1,000,000 step attempts in the idempotent and checkable lanes.
  • The unsafe lane has no duplicate SLO, by construction: it trades a possible gap for the duplicate, and says so in the product.

Open

  • Core Architecture Question 3: whether 'park and ask' is the right default, or whether some unsafe actions should refuse publication outright without an explicit author acknowledgement.