consistency-modelslisted

# Consistency Models ## Purpose Specify the weakest set of guarantees that satisfies observable requirements and price it. The models are not one total ladder: recency, ordering, session, convergence and multi-object atomicity are different dimensions. Stronger coordination often costs latency or partition availability, but the cost depends on topology, implementation and workload. The failure this prevents is the requirement expressed as a model name. "We need strong consistency" cannot be verified, priced, or tested. "A user must never see their own comment disappear after posting it because a replica has not applied the write" names an observation. Eventual convergence alone is insufficient; it can coexist with read-your-writes for that session. No global linearizability requirement follows from this observation alone. ## Workflow 1. **State the requirement as something a client observes.** "Two users must never both be assigned seat 14C." "A user must never see their own write disappear." "A balance may lag by up to five seconds but must never go backwards." No model names yet. 2. **Ask who observes it.** Requirements that hold only for the session that performed the write may need session guarantees. Compare their routing and metadata costs with the coordination required by the actual cross-client contract. 3. **Map each requirement to guarantees and scope**, using `references/requirement-to-model.md`: object/key range, session versus all clients, nor