Resolution Event Commit¶
Atomic commit protocol — instantiates Deferred Fulfillment Placeholder
Atomically stamps a pending placeholder into a single authorized terminal state, guarded so exactly one resolution ever takes effect.
If creation is the birth of a placeholder, Resolution Event Commit is the one irreversible moment that ends its pending life. It is the transactional step that flips a placeholder from pending to a terminal state — fulfilled, failed, cancelled, or expired — and does so as a single, all-or-nothing, authorized, once-only write. Its defining idea is the commit: the transition is atomic and guarded, so that out of every party that might try to resolve the same placeholder, and every retry and race, exactly one resolution takes hold and every subsequent attempt is rejected or absorbed. It doesn't wait, notify dependents, or decide what to do next; it is purely the machinery that makes "this placeholder is now, provably and finally, this outcome" true and unrepeatable.
Example¶
A payments platform holds a pending settlement placeholder for a card transaction — the money is promised but not yet cleared. When the clearing network responds, the resolution commit runs. First it checks authority: only the clearing service, presenting a valid network response, may resolve this placeholder; the merchant's own system cannot self-declare "settled." Then it selects the terminal state from the modeled set — settled versus declined versus reversed are genuinely different endings, not one blurry "done." It performs a guarded conditional write: set state to settled only if the current state is still pending. And it records the evidence — the network trace ID, the timestamp, the amount cleared — as the immutable provenance of this outcome.
The guard is what earns its keep the day the network sends a duplicate callback. The second commit finds the state is no longer pending, so its conditional write is a no-op; the settlement is not applied twice, no double credit is posted, and the duplicate is logged rather than acted on. One transaction, one resolution, one auditable record.
How it works¶
- Gate on authority. Verify the caller is permitted to resolve this placeholder to this kind of outcome. Forging or self-resolving is refused here, before any state changes.
- Choose a terminal state. Map the outcome onto the modeled set — fulfilled, failed, cancelled, expired — keeping them distinguishable rather than collapsing every non-success into a single "error."
- Commit atomically under a guard. Perform the pending→terminal transition as a conditional, compare-and-set write[n1] that succeeds only if the placeholder is still pending. This is the idempotency guard — a second, duplicate, or racing resolution cannot overwrite the first.
- Record evidence. Persist the outcome's provenance — who resolved it, when, with what proof, to what value — as an immutable part of the resolution event.
Only after the commit lands do other mechanisms (propagation, memoization) have something final to act on; the commit itself neither calls them nor knows about them.
Tuning parameters¶
- Authority granularity — a single privileged resolver, a role, or per-terminal-state permissions (who may fulfill vs. who may cancel). Finer control prevents abuse but adds policy surface.
- Atomicity boundary — whether the commit is a single-row conditional update, a database transaction, or a distributed consensus write. Stronger boundaries survive concurrency and partitions at higher cost and latency.
- Duplicate handling — whether a repeat resolution is a hard error, a silent no-op, or a return of the already-committed result. No-op-and-return is friendliest to at-least-once callers.
- Evidence depth — minimal outcome flag versus full provenance (actor, proof, inputs). Deeper evidence is auditable and dispute-resistant but heavier to store.
- Terminal-state vocabulary — how many distinct endings the model admits. More states carry more meaning downstream but complicate every consumer that must handle them.
When it helps, and when it misleads¶
Its strength is that it makes resolution trustworthy: exactly-once, authorized, evidenced, and final. It is the mechanism that prevents the archetype's ugliest failures — double-resolution races and false fulfillment — because the guard structurally forbids a second winner and the authority check forbids an illegitimate one.
Its failure mode is subtler than "it breaks": it is committing to the wrong terminal state, or committing without real evidence, so the ledger is internally consistent but wrong. A classic misuse is treating a timeout or a producer error as a success just because the code path was easier, collapsing distinct endings and hiding failures from everyone downstream. Another is a guard that is atomic in one node but not across a replicated store, so a partition lets two "winners" commit. The guarding discipline is to keep the terminal states genuinely distinct, refuse to commit a state the evidence does not support, and ensure the atomicity boundary actually spans everywhere the placeholder can be resolved from — an internal consistency check that the recorded outcome matches its proof.
How it implements the components¶
Resolution Event Commit fills the resolution authority and finality components:
resolution_authority_rule— enforces who may resolve the placeholder, and to which outcomes, at commit time.terminal_state_model— selects one of the distinct modeled endings (fulfilled / failed / cancelled / expired) rather than a single undifferentiated "done."idempotent_resolution_guard— the compare-and-set commit ensures exactly one resolution takes effect; duplicates and races are absorbed.resolution_evidence_record— persists the immutable provenance of the outcome as part of the commit.
It does not implement placeholder_identity, expected_value_specification, fulfillment_commitment, or pending_state_record — those originate the placeholder and belong to the creation-side twin, Promise Creation Protocol, which mints the object this commit later ends.
Related¶
- Instantiates: Deferred Fulfillment Placeholder — the commit is the finality step that ends the pending lifecycle authoritatively.
- Consumes: Promise Creation Protocol — a placeholder must already exist, pending, for the commit to resolve.
- Sibling mechanisms: Promise Creation Protocol · Await or Subscription · Callback or Continuation Registration · Pending State Polling · Cancellation Propagation · Failure Propagation · Dependency Graph Scheduling · Resolved Value Memoization · Timeout Expiration Handler
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Resolution Event Commit operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it atomically stamps a pending placeholder into a single authorized terminal state, guarded so exactly one resolution ever takes effect.
Independent corroboration: The frozen evidence defines Resolution Event Commit as 'Atomically stamps a pending placeholder into a single authorized terminal state, guarded so exactly one resolution ever takes effect', so its operative form is Control, Automation & Runtime.
Nearest alternative: Decision, Gate & Allocation — Resolution Event Commit includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Atomic compare-and-set transition to one terminal state is a concurrency and distributed-systems mechanism.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement adopts reviewer_a's evidence: Atomic compare-and-set transition to one terminal state is a concurrency and distributed-systems mechanism. The selected record uses alternates=none, origin_mode=single_lineage, and domain_reach=specialized; the other review proposed alternates=engineering_design, origin_mode=single_lineage, and domain_reach=specialized. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Compare-and-swap (CAS) — a primitive that writes a location only if it still holds an expected value — is the canonical building block for lock-free, exactly-once state transitions; the "resolve only if still pending" guard is a CAS in spirit. ↩