# Linearization (consistency model actually implemented)

- **Proposal**: the primary assigns a sequence number. This is not a client-visible linearization point.
- **Commit**: the first time 2f+1 COMMITs for (v, n, d) exist. Every honest replica executes committed operations
  in sequence order (BFT-TV, RT-BFT, judge R5/R6), so operations ordered through consensus are linearizable with
  respect to each other (standard SMR result), given f < n/3.
- **Authorization**: the gateway's successful `verify_commit` of a 2f+1 certificate over the exact commitment.
  It happens after the commit point, so a permit is linearized after its commit.
- **Revocation**: a durable sqlite write of a per-tenant revocation epoch in ONE gateway database. It is not
  ordered by consensus. The fast path reads it on every call, so within one gateway deployment revocation is
  linearizable with respect to later fast-path authorizations (RT-BFT-01/10: 0 violations in 200 threaded
  trials). Across gateways with separate databases there is NO common order.
- **Execution**: after `decide()` returns and outside consensus. It is not linearized against revocation
  beyond "the decision was taken before the revocation's write".

Consistency model: linearizable SMR for consensus-ordered decisions; read-your-writes revocation per gateway
database; a bounded-staleness permit window equal to the snapshot TTL when the fast path is on and the cluster
is unreachable. No global linearizability claim is made.