Changes Use the Version Read

Context

Optimistic concurrency preserves the basis on which a person edited a record. Dedicated update and archive operations validate that basis under record locks; deletion has no version argument.

Decision

Field-changing updates require the client’s read version and reject missing or stale versions with modifier attribution; current-version contact and organization no-op saves preserve capture and stamps; classification no-op behavior differs, and deletion remains unversioned.

Alternatives Considered

Accept whichever write arrives last. The recorded version decision rejects silent overwrite of another person’s or the system’s work.

Accept a stale request whose resulting content is unchanged. Platform requires that retry behavior, but the approved Entities rule and current code reject stale versions. The existing open question must resolve the conflict.

Consequences

Contact and organization no-op detection runs after the version check. The approved planning and Platform standard differ on stale unchanged requests. Classification writes also lack uniform no-op preservation, so this decision must not be read as proof of universal enforcement.

System maintenance can make an open editor stale and identifies the system in conflict attribution. A repeated committed edit can report a stale-version conflict despite unchanged content. Catalogue records have versions; settings begin at zero, and catalogue no-op behavior needs alignment.