@@ -12,7 +12,7 @@ Clause-②: no
 `resolveAuthzContext` now runs inside a request-scoped grants memo. A resolution that already completed inside the same call, with the same user, organization and seeds, is served to the next caller that asks for exactly that resolution, so the hook's resolution serves the resolver's own. The decision a request is authorised with is unchanged:
 
 - The memo lives for one `resolveAuthzContext` call (an `AsyncLocalStorage` scope, closed when the call settles). Nothing is cached across requests; the cross-request grants cache keeps its own default-off switch, `OS_AUTHZ_GRANTS_CACHE_TTL_MS`.
-- An entry is served only when a fresh read would agree with it. No write may have started, landed or still be in flight on the engine since the first resolution opened: the engine's write epoch (bumped when a write starts) and a write observer the memo registers as an engine middleware (counting writes into the chain and, after the driver step, out of it) must both read what they read at the open, with nothing inside the chain. No grant validity boundary may lie between the two clocks. The organization must be the same (the session arm's dropped-claim re-resolution is its own entry). A `bypassGrantsCache` caller is never served, a failed resolution is never stored, and an engine without the write-epoch seam or `registerMiddleware` declines entirely.
+- An entry is served only when a fresh read would agree with it. No write may have started, been executed at the driver, or still be in flight on the engine since the first resolution opened: the engine's write epoch (bumped when a write starts) and a write observer the memo registers as an engine middleware (counting writes into the chain and, after the driver step, out of it) must both read what they read at the open, with nothing inside the chain. The observer sees statement execution, not commit visibility. A write inside an `engine.transaction()` becomes visible only at its COMMIT, outside every chain. On driver-sql (not on the Turso remote face, which opens no transaction), a request whose step 2 falls inside that one commit round trip is authorised as of its first resolution, and the next request reads fresh — the same answer as a write from another process. No grant validity boundary may lie between the two clocks. The organization must be the same (the session arm's dropped-claim re-resolution is its own entry). A `bypassGrantsCache` caller is never served, a failed resolution is never stored, and an engine without the write-epoch seam or `registerMiddleware` declines entirely.
 - `plugin-auth`'s hook now passes the session's email as its seed email, exactly as `resolveAuthzContext` does for the same session, so the two calls ask for the same resolution. The seed reaches only the envelope's `email`, which the hook does not read: the payload's `positions[]` and `isPlatformAdmin` are unchanged, and platform-admin standing still compares the stored `sys_user.email`, never a seed.
 
 Where the saving does not apply, the request reads the grants twice, as before — always the safe direction:
 
@@ -60,8 +60,11 @@
  *         first sight of an engine, counting every write that enters it and,
  *         in a `finally` around `next()`, every write whose driver step has
  *         settled. The driver step runs INSIDE that `next()`, so a write cannot
- *         land without first moving `started` and cannot finish without moving
- *         `completed`.
+ *         be EXECUTED at the driver without first moving `started`, and cannot
+ *         finish executing without moving `completed`. The observer sees
+ *         statement execution, not commit visibility: on an
+ *         `engine.transaction()` the rows become visible to other connections
+ *         only at the driver COMMIT, outside every chain (residuals below).
  *    An entry is served only when the epoch, `started` and `completed` all read
  *    what they read at the open AND no write is inside the observer
  *    (`started === completed`). So a write that started before the open and
@@ -98,6 +101,18 @@
  * them — the same answer a write committing just after the second read always
  * got.
  *
+ * The same holds for a write executed on an `engine.transaction()` whose
+ * COMMIT lands between the first resolution and step 2. Its statements pass
+ * the observer, which settles per statement, but the rows become visible only
+ * at the driver commit, which runs outside every middleware chain. The window
+ * is that one commit round trip after the transaction's last statement. It is
+ * reachable on driver-sql deployments (SCIM through the better-auth adapter,
+ * REST `/batch`), and not on the Turso remote face, which declares
+ * `transactionsUnsupported` and so opens no transaction. The answer is the
+ * out-of-process one: that request is authorised as of the first resolution,
+ * and the next request reads fresh. Closing it engine-side (an objectql epoch
+ * bump after an owned transaction's commit) is out of scope here.
+ *
  * The cost: on an engine with a concurrent write, step 2 reads afresh. That
  * includes a session read that writes inside the request (the first request on
  * a fresh auth instance generates its signing key; `enforceSessionControls`