# Durability Guarantee

Weft's promise is **checkpoint-position durability**, not blanket exactly-once execution. With a durable storage adapter, the engine persists each durable boundary before the workflow advances, and recovery resumes from the last committed checkpoint instead of replaying the whole function from the beginning.

## Guaranteed Today

| Guarantee                                                                   | What it means                                                                                                                                                                                                                                             | Evidence                                                                                                                                                                                                                       |
| --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Every `yield*` boundary commits a checkpoint before the next step advances. | The latest workflow position, local state, pending replay entries, timeline entry, and checkpoint-event replay metadata are written through the checkpoint commit path.                                                                                   | [`persistCheckpoint()` and `commitCheckpoint()`](../../src/core/engine/checkpoint-io.ts)                                                                                                                                       |
| Fresh-process recovery is automatic when you use `Engine.create()`.         | Definitions are registered first, then `recoverAll()` runs unless you pass `recover: false`.                                                                                                                                                              | [`Engine.create()`](../../src/core/engine/index.ts) and [Recovery and deploys](../guides/recovery-and-deploys.md)                                                                                                              |
| Recovery is exactly positional.                                             | The generator resumes from the persisted checkpoint step and stored locals; completed durable operations do not re-run just to rebuild state.                                                                                                             | [Checkpoint versus Replay](checkpoint-versus-replay.md) and [Workflow guide](../guides/workflows.md#bounded-checkpoint-growth)                                                                                                 |
| Pending signals and review requests survive process restarts.               | Signal payloads and review requests are stored separately from checkpoints. A submitted review decision is part of workflow state after the waiting workflow checkpoints the returned decision; completed review records are also stored for review APIs. | [Signals and Queries](../guides/signals-and-queries.md#signal-durability), [`ReviewCoordinator`](../../src/core/review/index.ts), and [`submitReviewDecisionOperation`](../../src/server/operations/submit-review-decision.ts) |
| Lease-owned engine writes are fenced on the current owner epoch.            | When `ownership: 'lease'` is enabled, engine-owned checkpoint, timer, schedule, purge, retry, activity-reconciliation, async-activity, and completed-review writes lose their compare-and-swap instead of landing after a successor has taken the lease.  | [Singleton deployment guide](../guides/singleton-service-deployment.md#optional-lease-based-ownership-for-a-clean-deploy-handoff), [`commitFencedEngineWrite()`](../../src/core/engine/fenced-write.ts)                        |

## Current Limit

Activities are side effects in external systems. If an activity completes externally and the process crashes before Weft commits the activity result, recovery may dispatch that activity again. Today, activities without an `idempotencyKey`, provider transaction lookup, or equivalent verifier are therefore **at least once** across that hard crash window. The [Activities guide](../guides/activities.md#per-call-options) describes the user-supplied idempotency boundary.

The Tier-0 activity reconciliation track closes this gap for keyed and verifiable activities by adding durable activity result reconciliation. It is specified in the [Tier-0 Behavioral Contract](tier-0-behavioral-contract.md#activity-result-reconciliation), but it is not the current blanket guarantee.

Out-of-band async activity completion uses the same commit boundary: a successful completion consumes the single-use token in the workflow checkpoint batch that records the result. If the payload is malformed or oversized, Weft rejects it before token consumption so the parked workflow can still be completed later.

## Operational Boundary

Durability also depends on topology. `MemoryStorage` is not durable, and production recovery currently supports one engine process per durable store. Do not point two engines at the same store until the future `MultiEngine` fenced-ownership work lands. The supported deployment shape is documented in [Running Weft as a Singleton Service](../guides/singleton-service-deployment.md).