diff --git a/01-RESEARCH/011-the-module-graph/00-overview.md b/01-RESEARCH/011-the-module-graph/00-overview.md
index dd87b35..0454edf 100644
--- a/01-RESEARCH/011-the-module-graph/00-overview.md
+++ b/01-RESEARCH/011-the-module-graph/00-overview.md
@@ -177,7 +177,8 @@ Struck-through rows are answered, with where. The rest are live.
 | What does a provider hand back? | Credentials and an address for a store; a command for a terminal. Same relation, different shape crossing it. |
 | Is provisioning one mechanism or two? | The mesh's own registry is provisioned **before there is a mesh**, so provisioning is part of the bootstrap and part of what the carried bundle expresses. At bootstrap the store is local; afterwards it is on another node. Same operation, both sides of a tier boundary. |
 | Is a tool surface one relation with two audiences, or two? | 56 of 126 modules carry tools — more than carry a service — and what consumes them is an **agent**, not a module. |
-| Do the remaining cross-context reads want an interface or events? | Asking *which nodes exist* is a request; reacting *when a node appears* is a subscription. Some want both. |
+| ~~Do the remaining cross-context reads want an interface or events?~~ | **Derived, not chosen.** Neither is SQL — that only ever runs against your own store. ADR 0036 makes disconnection ordinary, so anything that must work while disconnected cannot use a request and needs a local copy: a subscription. Anything where a stale answer is worse than none cannot use a subscription. |
+| What does a consumer do about events it missed while disconnected? | Replay from a point, ask once for a full picture and resume, or rebuild. The question every projection has, and unanswered here. |
 | What happens to a grant when its consumer is removed? | Dropping is data loss; keeping is a leak. ADR 0043's removal rule does not obviously carry, because the thing lives inside another module's state. |
 | Is a declaration composed per node, from what that node reported? | Some configuration follows the hardware. Either the host fills a blank — deciding, against ADR 0037 — or the control plane composes from the node's inventory first. |
 | Would `excludes` and capability requirements actually be used? | Zero manifests declare either, which is equally consistent with *nobody needs them* and *nobody can express them*. |
diff --git a/01-RESEARCH/011-the-module-graph/worked-provider.md b/01-RESEARCH/011-the-module-graph/worked-provider.md
index 885357c..71f0954 100644
--- a/01-RESEARCH/011-the-module-graph/worked-provider.md
+++ b/01-RESEARCH/011-the-module-graph/worked-provider.md
@@ -256,11 +256,38 @@ its dependency on the registry shrinks to a single table.
 What remains is a handful of genuine cross-context reads, small enough to enumerate rather than
 estimate. **The rule holds.**
 
-### What it still does not answer
+### Request or subscription, and what decides
 
-Whether those remaining reads want an **interface** or **events**. A consumer asking *which
-nodes exist* at the moment it needs to know is a request; one that must react *when a node
-appears* is a subscription. Some will want both, and nothing here says which.
+The remaining cross-context reads need one or the other. **Neither is SQL** — under exclusive
+ownership a module runs SQL against its own database and nothing else, whatever transport a
+query might travel over. Both options are the mesh's own channel, and both ride the broker
+([ADR 0001](../../02-DECISIONS/0001-nodes-communicate-over-a-broker.md)), so the transport is
+not the distinction.
+
+**The distinction is where the answer lives when you need it.**
+
+| | request | subscription |
+|---|---|---|
+| you ask | at the moment you need to know | never — you are told |
+| the answer lives | on the other side | in your own store |
+| freshness | always current | as current as the last event you received |
+| when the other side is down | you cannot answer | you answer from your copy |
+| what you must handle | a round trip that can fail | events you missed while you were down |
+
+**What decides is not taste.** [ADR 0036](../../02-DECISIONS/0036-a-node-is-a-managed-machine.md)
+makes disconnection an ordinary situation rather than an exception. So:
+
+> **Anything that must keep working while disconnected cannot use a request** — there is nobody
+> to ask. It needs a local copy, which means a subscription.
+
+And the converse: anything that must be *correct at the instant of asking*, where a stale answer
+is worse than no answer, cannot use a subscription. A display can lag. A decision about whether
+a grant is still valid cannot.
+
+That turns an apparently open question into a derived one. What remains genuinely open is
+narrower: **what a consumer does about the events it missed** while it was disconnected — replay
+from a point, ask once for a full picture and resume, or rebuild from scratch. That is the same
+question every projection has, and nothing in the record answers it yet.
 
 ## A migration belongs to the consumer and runs on the provider