Consistency, in the words we use

Declare what you need; the platform satisfies or refuses

Most systems document their consistency in prose and degrade it in silence. CX inverts both halves: a program declares the guarantee a read or a session needs, in a closed vocabulary, and the platform either satisfies the declaration or refuses loudly — never approximates, never silently downgrades. An unknown token is a typed error, not an ignored option.

The enemy this design names is the silent-wrong-answer class: a read that used to be fresh quietly served from a stale cache, a resumed subscription that skipped entries nobody noticed, a replica answering as if it were the primary. Every one of those becomes either a declared-and-satisfied guarantee or a visible refusal naming the token and the surface that could not honor it.

The vocabulary

The tokens are a closed set. Each names one checkable property; the table says what satisfies it and what refuses it.

Deliberately absent: snapshot-isolation, causal, and eventual are not in the set at all — admitting them as refusals would imply roadmap, and admitting them as accepted would be a lie. And valid-at is not a consistency token: it is the valid-time query parameter (bitemporal), and the two axes must not fuse.

Two refusals that teach

Two tokens exist so their refusals can point somewhere better:

• :exactly-once — permanently refused: no distributed substrate delivers it, and pretending is how double-charges happen. The refusal names the real answer: at-least-once delivery composed with declared idempotency at the effect boundary (commands-effects).
• :serializable — refused with a pointer: the substrate offers no cross-stream commit coordination, and this vocabulary will not imply one. The refusal names the coordination design as the place where that either arrives or is rejected on principle.

This is the vocabulary's quiet thesis: a guarantee you refuse loudly is worth more than a guarantee you fake. The refusal is documentation, delivered at the moment of need, naming the supported alternative.

A lattice, not a ladder

Incumbent intuition wants \"consistency levels\" on a dial from weak to strong. This vocabulary is independent conjuncts: prefix-consistent and read-your-writes are incomparable — neither implies the other — and a declaration is a set, not a level. A refusal names the failing token and the failing stage, so widening a declaration tells you exactly what you just asked for that the surface cannot give.

The composition rules that follow from per-stream reality: prefix-consistent holds per source — a multi-stream read gets per-source prefixes and NO cross-source cut unless it declares :at-head-set, which supplies a signed cut of named positions. And a head-set is a read coordinate: committing across streams is coordination, a different problem owned by a different design — this vocabulary refuses to blur that line.

Where declarations attach

Exactly two attachment points:

• The handle floor — store open options, journal open/attach, fabric subscribe, session establishment. The declaration is checked ONCE at declaration time against the surface's advertised guarantee set and refused at open; the advertisement is bound to the configuration generation, so a config reload cannot leave a cached advertisement lying about the new reality.
• Per-read pins — at-seq, a head-set, or a cursor on the read options.

Deliberately NOT an attachment point: definitions. A consistency need is a property of the handle a value arrives through at runtime, not of a function — a def-level clause would be either advisory (the house contradiction) or a disguised runtime check. Replicas get an honest profile from the same vocabulary: a replica can declare :prefix-consistent (the hash chain makes prefixes checkable), :at-seq-pinned up to its synced head, and :monotonic-reads — and must refuse :read-your-writes and :linearizable-ref, advertising its signed head-set and lag through status instead of pretending to be the primary.