diff --git a/docs/drivers/MTConnect.md b/docs/drivers/MTConnect.md
index bd4edcdae..1b84a9bee 100644
--- a/docs/drivers/MTConnect.md
+++ b/docs/drivers/MTConnect.md
@@ -763,7 +763,7 @@ Tests: `MTConnectCommsLossTests` (incl. an ambiguous-failure falsification contr
 
 ### Live gate: refused-connection fast path (#846/#852) — recipe
 
-**Not yet run.** Uses a dedicated, throwaway Agent on the local docker-dev rig — never the shared fixture on
+**Ran 2026-11-11 on `03e51457` — PASS** (see the gate table below). Uses a dedicated, throwaway Agent on the local docker-dev rig — never the shared fixture on
 `10.100.0.35`. `docker-dev/docker-compose.mtconnect-gate.yml` adds two services to the rig's network: `mtconnect-gate`
 (the fixture's SHDR adapter, which also owns the network namespace and publishes host `:5155`) and
 `mtconnect-gate-agent` (`mtconnect/agent:2.7.0.12` with the fixture's `agent.cfg`/`Devices.xml`, running **inside**
@@ -817,7 +817,7 @@ NodeIds moved together in every leg. Fixture containers were restored healthy af
 |---|---|
 | Adapter stop | Both NodeIds `BadNoCommunication` within 1 s of the adapter dying (Agent marks items UNAVAILABLE); driver stayed Healthy. Adapter start ⇒ Good 1–2 s later. |
 | Agent restart (`docker restart`, ~12 s) | Stream lost and reconnected ~1 s; the stale cursor was refused `OUT_OF_RANGE`, the re-baseline saw the new `instanceId`, **rediscovery raised** — `/hosts` shows the **RE-BROWSE** chip. Values stayed Good (outage shorter than the comms-loss window). |
-| Agent stopped ~2 min | Values held Good-but-stale; **Bad at 118 s** (comms-loss watchdog, connection refused). Agent start ⇒ re-init on the 10 s retry, Good ~8 s after the Agent was back. **Since #846** a refused connection marks the values `BadNoCommunication` after `CommsLossConfirmMs` (2 s) instead — unit-tested, not yet re-gated live (recipe: [Live gate: refused-connection fast path](#live-gate-refused-connection-fast-path-846852--recipe)). |
+| Agent stopped ~2 min | Values held Good-but-stale; **Bad at 118 s** (comms-loss watchdog, connection refused). Agent start ⇒ re-init on the 10 s retry, Good ~8 s after the Agent was back. **Since #846** a refused connection marks the values `BadNoCommunication` after `CommsLossConfirmMs` (2 s) instead — **live-gated 2026-11-11 (#852):** Agent killed 13:27:15.19 ⇒ both values `BadNoCommunication` and the `x_travel` condition's quality-only event at 13:27:17 (2.0 s; condition kept Inactive/Acknowledged). On restart the condition got one more event (Inactive/Acknowledged, no re-raise) and values were Good again ~23 s later — the delay is the `/sample` reconnect backoff (attempt 9 ≈ 26 s), not the fast path. Note `mtconnect/agent` ignores SIGTERM, so `compose stop` kills it at the 10 s grace — time the leg from the container's `FinishedAt`. |
 | Agent paused (`docker pause`) | Stream idle watchdog at 24 s (2 × 10000 + 5000); **Bad at 94 s** (watchdog); unpause ⇒ Good within ~3 s. |
 | Genuine buffer overrun | A stalling TCP proxy froze the driver's transport while 32 000 observations were injected (`AllowPut`) — the Agent's `firstSequence` passed the driver's cursor (75 856 → 77 083). On release the resume was refused `OUT_OF_RANGE`, the driver re-baselined from `/current` within 1 s and resumed; values Good, no restart misdiagnosed. A raised-count stream (count 16, interval 5 s) was **not** lapped by a 266 obs/s burst: chunks are sent back-to-back while data is pending, so `interval` does not cap throughput. |
 | `SampleCount` vs `bufferSize` (#825) | Test Connect rendered the amber "OK with warning" chip and a deploy logged the Warning (`/hosts` shows `agentBufferSize`). The same gate measured the Agent's real edge — `count = 16384` streams, `16385` is `OUT_OF_RANGE` — so the first build's "at or above" threshold was corrected to "above" (pinned live by `Test_Connect_warns_when_SampleCount_exceeds_the_live_agents_buffer_size`). |