Execution lifecycle
INTENDED → PERSISTED → DISPATCHED → SETTLED_COMMITTED | SETTLED_FAILED | AMBIGUOUS (→ settled on adjudication); CANCELLED pre-dispatch.
How it works
The retry that isn’t identical
Classic distributed systems assume a deterministic caller: if a request is retried, the same bytes are resent, so argument hashes and caller-supplied idempotency keys hold. An LLM agent breaks that assumption — it regenerates the request itself.
Under temperature 0, floating-point nondeterminism yields different token sequences on retry; the re-synthesized tool call carries a different reference ID and the destination treats it as new. That defeats idempotency keys, recorded-nondeterminism, and deterministic orchestrators — all of which assume the caller resends an identical request. A survey of 12 agent frameworks found none enforce exactly-once at the tool boundary, and duplicate-execution issues are documented in LangGraph and CrewAI in production.
Evidence: Verified evidenceTechnical provenance
The insight
Identity must come from upstream business facts
intent_id = hash(stable business ids
+ effect_type + scope)
operation_id = (intent_id, step)
idempotency evidence derives ONLY
from operation_id — no key-derivation
path reads model output.Effect identity derives from an explicit intent contract keyed on stable upstream identifiers —order_id, invoice_id, approved_task_id,authorization_id. When the model re-synthesizes different arguments for the same intent, the identity is unchanged, so the retry collapses onto the same record and the divergent parameters are kept as evidence for the denial.
Semantic or embedding similarity may flag suspected duplicates for review, but never merges or blocks on its own. The “no model output in key derivation” rule is a conformance test, not a convention.
Evidence: Design specificationTechnical provenance
The state model
Three orthogonal dimensions, because one machine can’t say “orphan”
Conceptual
Reconciliation classification
UNRECONCILED · CONFIRMED_UNIQUE · DUPLICATE · LOST · CONTRADICTED · ORPHANED — an orphan is representable only as a finding, because a ledger-keyed state machine cannot express a destination effect with no ledger record.
Resolution status
OPEN → COMPENSATED | REDISPATCHED (fresh authority + new idempotency evidence only) | ACCEPTED_AS_IS | ESCALATED_HUMAN → CLOSED.
The three dimensions are deliberately never collapsed into one status color or one flat machine: an effect can be lifecycle-settled and classification-contested at once, and the record keeps both facts. This rendering is conceptual; the canonical, exhaustively tested state tables live in RFC-002 §3.
Evidence: Design specificationTechnical provenance
The ambiguous case, end to end
Crash, recover, adjudicate — then deny the duplicate with evidence
This is the sequence from master doc §7.4, retold by the recorded artifact: response lost, process killed, ledger replayed, destination queried before any redispatch, and the re-synthesized retry collapsed onto the same identity.
Recorded sequence (seed 777)
Recorded artifactseed 777engine 0a22114refdest-c2
- — Irrevon leg —
- 1registeredeffect 0bb7e8d64711… · lifecycle PERSISTED
- 2dispatch_response_lostfault response_lost · lifecycle AMBIGUOUS
- 3crashexit_status -9 (SIGKILL, mid-run)
- 4recoveredrestart · scanned 1 · adjudicated 1 — before any redispatch
- 5settled_confirmed_uniqueSETTLED_COMMITTED · CONFIRMED_UNIQUE (destination queried)
- 6resynthesis_collapsedreplayed true · parameter_variant sha256:074abd63…98c2cd
- 7duplicate_rejectedoutcome denied · deny_check dedup · decision_id 2
- — B5 contrast leg —developmental file-journal B5 stand-in: durable retry + stable op-IDs + idempotency keys
- 8b5_response_losttransport_outcome LOST (identical fault schedule)
- 9b5_restartdurable runtime restarts the workflow
- 10b5_retriedretried wf-order-9410-activity-0 — key sent, destination ignores it
- 11b5_duplicatedestination_effects 2
Irrevon leg1 destination effectduplicate rejected · SETTLED_COMMITTED
B5 leg2 destination effectsduplicate created · same fault schedule
contrast_holdstruerecorded in the artifact summary
0a22114) against the reference C2 destination — queryable status, no honored idempotency. Not live, not production; reproducible from the repository with uv run irrevon demo.Evidence: Verified evidenceTechnical provenance
Prefer it beat by beat? Step through the recorded sequence on the demo page →
The recovery rule
On restart, replay the ledger; every DISPATCHED or AMBIGUOUS record is adjudicated via reconciliation before any new dispatch of the same operation. Re-dispatch requires confirmed absence (C2) or in-window replay (C1), plus fresh authority.Never re-dispatch on belief.
Evidence: Design specificationTechnical provenance
Guarantee boundaries
What each destination class makes possible — and impossible
Guarantees are destination-tiered, and the table is rendered whole: the expected C1 null and the C3 impossibility boundary are as load-bearing as the C2 claim.
Scroll table horizontally
| Tier | Destination property | Duplicates | Lost / orphans | Example APIs |
|---|---|---|---|---|
| C1 idempotency-keyed | Accepts caller key with defined replay window | PREVENTED within window (native — Irrevon adds no advantage: the expected null) | Detected via receipts + query | Stripe; QuickBooks Online (RequestId) |
| C2 queryable | Stable external refs; list/status query, no dependable native idempotency | DETECTED via query; safe re-dispatch after confirmed absence | Detected via sweep; LOST provable | Amadeus Flight Create Orders; Twilio Messages; EasyPost/Shippo shipments; Shopify orderCreate |
| C3 opaque | No key, no query, no stable ID | Client-side dedup of identical ops only | UNDETECTABLE — impossibility boundary, demonstrated openly | Fire-and-forget notifications |
Evidence: Design specificationTechnical provenance
Non-guarantee
No universal exactly-once (Two Generals / FLP). At-least-once delivery plus idempotent or reconciled processing is the achievable target.
Evidence: Verified evidenceTechnical provenance
Non-guarantee
True rollback of an externalized irreversible effect is impossible; compensation is a new effect with its own failure modes, measured never assumed.
Evidence: Design specificationTechnical provenance
Non-guarantee
Reconciliation cannot recover information the destination never exposes. The benchmark must show every method failing at C3.
Evidence: Design specificationTechnical provenance
Prior art, credited
None of the primitives are new. The combination and its measurement are.
Irrevon did not invent the outbox pattern, idempotency keys, sagas, or durable execution. What is defensibly new — narrowed on the record as adjacent work appeared — is the planned measurement combination: a fault-injection benchmark drafted for preregistration against real production API contracts with a destination read-back oracle, and reconciliation keyed on the destination’s authoritative-status query for C2.
Scroll table horizontally
| Primitive | Prior art |
|---|---|
| Effect ledger / persist-before-dispatch | Transactional outbox pattern (established) |
| Idempotency keys | Stripe, Kafka EOS, Hookdeck |
| Compensation | Saga pattern; SagaLLM |
| Durable execution | Temporal, DBOS, Restate, Inngest (exactly-once on own state only) |
| Staged commit / effect containment for agents | Cordon (2606.17573), Atomix (2602.14849) — academic |
| Record-and-replay-or-fork | ACRFence (2603.20625) — security framing |
| Bi-temporal ledger + reconciliation | Formance; Modern Treasury |
| Local agent dedup + receipts | rune0-dev/agent-ledger; azender1/SafeAgent |
Evidence: Verified evidence · Evidence-backed analysisTechnical provenance
The honest counter-evidence, on this page
Irreversible actions are rare as a share of agent traffic: about 0.8% of nearly a million sampled tool calls, per Anthropic’s February 2026 measurement (model-classified estimates, with the caveat on the record). This is a high-severity, low-frequency problem — which is why Irrevon is a reliability contribution and a benchmark, not a metered platform. If you need one of those, this isn’t it.
Evidence: Verified evidenceTechnical provenance