# Transactional recovery: mechanism mappings

0.1 research preview. These map previously reviewed mechanisms to candidate decisions,
not complete, interchangeable product implementations. No new source verification was
performed for this mapping; dates and revisions are those in the linked reviews.
[Transactional sequence](../sequences/TransactionalApplication.md).

| Decision | Located mechanism and provenance | What still needs verification |
| --- | --- | --- |
| CAND-0005 — retain unfinished intent | Zulip and Element composer draft paths, pinned source R01/R03 in [FrontendRecoveryImplementations](../research/reviews/FrontendRecoveryImplementations.md) | Complete base/draft/current merge, retention policy, restart and composer-to-operation handoff |
| CAND-0006 — reject a stale proposal | Kubernetes conditional PUT, T01 in [TransactionalEvidenceExpansion](../research/reviews/TransactionalEvidenceExpansion.md); GitLab optional file precondition T02 has different failure semantics | Actual endpoint atomicity and domain checks; do not treat every GitLab 400 as version rejection |
| CAND-0007 — resolve uncertain outcome | Stripe bounded replay identity T03; Element/Matrix echo/retry source R04–R06; [Matrix SDK observation](../research/reviews/MatrixRecoveryExperiment.md) uses synthetic transport | Receiver retention/identity scope, lookup, true server deduplication, cancellation/compensation; these mechanisms are not one assembled stack |
| CAND-0008 — refresh after acceptance | React Router revalidation and concurrency guidance T04/T05 in the transactional review | Read-after-write, obsolescence and preserved drafts in the actual application; client cancellation does not stop server effects |

Select a mechanism only after the application's acceptance and failure contracts are
known. These examples do not require Kubernetes, Stripe or a particular UI framework;
they illustrate different obligations. Combining them is a proposed design, not a
known deployed use. Full-contract recurrence remains unassessed.