---
title: Version-Checked Mutation
status: draft
maturity: hypothesis
families: [mutation, authority]
scales: [L2, L6]
admission: research-candidate-only
---

# Version-Checked Mutation

Context: a proposal depends on a previously observed record. Problem: concurrent
updates can invalidate that base. Consistency competes with throughput and user effort.

Proposed solution: send an expected version with the proposal; the authority checks
it atomically with validation and commit. A mismatch rejects the attempt. Preserve
the draft, fetch current state and reconsider intent before a new attempt. An
operation identity for safe retries is separate from the version precondition.

Consequences: lost updates can be detected, but high contention creates repeated
review. Unconditional or commutative operations may need different preconditions;
blindly retrying with a new version can overwrite another user's intent.

Evidence: T01 documents Kubernetes conditional PUT; T02 documents a different GitLab
failure surface and optional last_commit_id, insufficient to prove identical atomic
semantics. One precise mechanism use, not two verified frontend uses. Recurrence of
this frontend configuration: unknown. Hypothesis only.

Proposed connection: rejection creates work for [Local Draft State](LocalDraftState.md)
and [Mutation Outcome Tracking](MutationOutcomeTracking.md).

T01–T05 refer to [TransactionalEvidenceExpansion](../reviews/TransactionalEvidenceExpansion.md).
Connections are research proposals, not admitted graph edges.
Reasoning exercise: [VC-01](../walkthroughs/VC01-TransactionalAdministration.md).