Owner ruling 2026-09-14c, recorded in the #695 plan and the campaign runbook.
One gate for every stream was wrong. It applied a VR budget to a flat experience and failed venues that are fit for mercator-talks. Remote VR is NOT ruled out either: cloud-seven reaches GCP europe-west1 in 4.092 ms with 1.500 ms of jitter, which is inside the VR tier from a public cloud. The working reach rule is roughly 30 km, but routing decides, not distance.
| Metric | VR | Flat |
|---|---|---|
| RTT p50 | <= 5 ms | <= 30 ms |
| RTT p99 | <= 10 ms | <= 50 ms |
| IPDV p99 | <= 5 ms | <= 15 ms |
| Downstream loss | <= 0.1%, no burst > 3 | <= 0.1%, no burst > 3 |
| Reordering | <= 0.01% | <= 0.1% |
Loss does not relax between tiers: a lost packet is lost frame data in either mode. The VR jitter line is the #402 5 ms line unchanged.
tier field to the result YAML carrying the HIGHEST tier the numbers support: vr, flat or unfit. A cell that is vr is flat by construction. This is the useful answer because it says what a venue can be SOLD, not whether it cleared one arbitrary bar.--gate vr|flat, defaulting to flat because this program is flat. verdict stays, scored against the nominated gate, so pass, conditional and fail keep their meaning for an operator who nominated a target.Do NOT start until the #724 kernel-timestamping change has landed; both touch internal/result and cmd/hydraprobe.
The flat thresholds are derived, not observed. The pilot tap-to-photon run (#708 gate G3) is the ground truth. If a venue at the edge of the flat tier feels right on a real mercator-talks session the numbers hold; if it feels laggy they tighten. The docs must say so wherever the flat row appears.