Read fresh version tokens before update

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Rename a shared space while another user may change description. Teaching read gives identity/nameA/descriptionD/version 12 and conditional writes compare its token. Fresh reads are not locks.

Mechanism

Read current object/token immediately before writing, changing intended fields only. On conflict reread/reconcile preserving others rather than force an old snapshot. Do not reconstruct tokens; unconditional services provide no claimed concurrency protection. Satisfy authorization separately.

Bad example

Overwrite with cached version 11, bypass conflict and restore another person's D2 to D.

Good example

Read teaching version 12 and submit the scoped rename under its contract. If D2 intervenes/conflicts, reread object/token and merge rename without overwriting D2 or inventing versions. Read access is not write permission; uncertain conflict semantics remain a gap.

Why the change matters

Tokens bind writes to reads and expose intervening edits. Intent reconciliation preserves both changes rather than treating conflict as an obstacle to bypass.

Observable expectation

Version 12 succeeds normally; an intervening edit rejects old token, and reread retains D2 with actual new token. Inspect matched identity/token/scoped fields.

Fresh read without server comparison establishes no safety; no real space changes.

Limits

Tokens may be opaque and vary by service; frozen sys.version/SyncToken are instances. Bound retries/reconcile, and tokens prove neither correctness nor extra authority.