Stores are constructed into one of these. A store never owns an order and never borrows one; it is a member of the order it was built with, and it says so once, at construction, which is why nothing here can be attached, replaced or set wrong afterwards. A shard set builds all of its partitions into one order, its own or the one it was itself built into, and a group over several stores is one commit exactly when they were built into the same order.
Nothing here is wall time. Both counters are logical in the sense a commit stamp is logical: monotone integers that order events, and nothing else.
Publication
Commits are a ring indexed by stamp. Drawing a stamp is one unconditional add, so a committer never waits for room; landing is what waits, and only for the stamp whose slot it is about to reuse. The watermark then walks forward through consecutive landed slots, so it stops one below the oldest commit still in flight and never covers a stamp whose versions are still being written. A later commit that finishes first stays invisible until the earlier one lands, when both appear together.
The ring is correct at every size down to one, where it degenerates to publishing in stamp order; commits_in_flight_ chooses only how often a committer waits, never what the watermark means. What bounds it is not the core count: a committer holds its locks across the whole span between begin_commit and end_commit, so two commits in flight hold disjoint lock sets, and the ceiling is the number of independently lockable regions the order serves. A shard set therefore names its own partition count, and a single locked store needs one.
Open Snapshots
Readers are counted by bucket rather than listed one by one. A bucket carries the watermark it was opened at, which is a floor for every reader that joins it, and the low-water mark is the least floor over occupied buckets. Running out of buckets refuses nothing and blocks nobody: readers share a bucket, the mark becomes a lower bound rather than exact, and reclamation is correspondingly conservative, which is already the only thing a caller may assume of it. That is what lets take_snapshot stay infallible, since three of its callers sit inside noexcept helpers with no channel to report a refusal.
A claim is therefore a bucket index and a stamp, never a pointer into caller memory, so a claim moves with its transaction between threads by copying two fields and touching this order not at all. Two buckets are the fewest that work: the head rotates into the other one as the watermark leaves its floor behind, so a reader handing over to the next never pins the first one's floor.
Ordering
Three orderings carry the guarantees under shared_k, and the models in verification/commit_order/ drop each in turn. A reader joins its bucket and then reads the watermark through a read-modify-write, so a mark computed after the join counts it, and one computed before it stands at or below the stamp the reader is handed. A mark reads the watermark through a read-modify-write before scanning the buckets, never after, or a reader joining in between is missed. A landed commit reads the watermark through a read-modify-write before it walks the ring, or two commits landing at once store-buffer past each other and a mark is left for the next commit to find. A bucket is also retagged shut to arrivals before its floor is stored, which keeps the floor from moving under a member; a joiner the retag misses read the watermark before the opener did, so the floor stays at or below its snapshot either way.
Under solitary_k none of that applies, because there is no second thread to order against.
end_commit waits for older commits to land once commits_in_flight_ of them are ahead of the watermark, and await_published waits for another thread's publication. Every store and group here commits under the rule above.