The main forces are consistency, recoverability and continuity versus complexity,
latency and user review effort. First verify the endpoint's version, authorization,
business-rule and receipt contracts; the names below cannot supply missing guarantees.
## Decisions and resulting contexts
| Decision | Candidate and resulting context | Alternative / boundary |
| --- | --- | --- |
| Keep typing separate from the last received record | [CAND-0005 Local Draft State](../research/candidates/LocalDraftState.md): base, proposal and current observation can be compared | Directly bind a cache only where there is no unfinished work; retention/export still follow access policy |
| Reject proposals based on stale assumptions | [CAND-0006 Version-Checked Mutation](../research/candidates/VersionCheckedMutation.md): authority checks expected version with the write; rejection creates a review decision | Commutative or unconditional operations need their own domain contract; do not blindly resend against a newer version |
| Distinguish transport failure from the result of the operation | [CAND-0007 Mutation Outcome Tracking](../research/candidates/MutationOutcomeTracking.md): keep pending, accepted, rejected or unknown evidence for that attempt | Without result lookup or valid deduplication scope/window, stop automatic replay and reconcile; a fresh ID is not a recovery guarantee |
| Refresh affected views after acceptance | [CAND-0008 Invalidate and Reproject](../research/candidates/InvalidateAndReproject.md): acceptance and view freshness remain separate | A complete authoritative result or suitable subscription may avoid refetch; obsolete responses must not replace newer observations or drafts |
These decisions are conditional, not a mandatory dependency chain. Keep shared
acceptance separate from local display. Server and client projection are alternatives
only after their input availability, performance and recovery needs are understood.
## Follow the failure
A reads a record and edits it; B changes that record. A's stale write is rejected:
keep A's draft and compare it with the current record. After the user reconsiders,
a new proposal may be sent. If its response disappears, retain its identity and show
unknown outcome. Resolve that attempt through its verified receipt/replay contract.
Once acceptance is established, refresh affected observations without erasing newer
input. If refreshing fails, show accepted with a stale view, not failed mutation.
Opaque versions are not sortable numbers without an ordering contract. Stopping a
local wait does not reverse a remote effect; compensation is a separate authorized
operation. Invalid access may prohibit retaining the draft. Keyboard/error recovery
must be implemented and checked; this sequence is not accessibility certification.
## Change a constraint
With one authorized writer, cross-user contention disappears, but that writer's
in-flight operations can still race. Outcome uncertainty and refresh remain; version
checks do not automatically become unnecessary. With required offline final approval,
this fixed server-acceptance brief is incompatible: change the domain acceptance
contract or require connectivity. Do not substitute the offline-note sequence silently.
## Implementation and evidence
Use [transactional mechanism mappings](../technologies/TransactionalRecovery.md) to
find API and frontend examples, then verify your actual contracts. The full
[VC-01 trace](../research/walkthroughs/VC01-TransactionalAdministration.md) includes the
plain-language baseline, assumptions and counterfactual. It is development reasoning,
not empirical validation. [M1 review](../research/reviews/M1-SeedReview.md) remains
revise/defer. Independent human usefulness and complete application recurrence are open.
