01-RESEARCH/011-the-module-graph/00-overview.md

@@ -185,5 +185,6 @@ Struck-through rows are answered, with where. The rest are live.
 | What does an exclusion mean for something already installed? | Refuse the install, or surface the conflict and let it be decided. |
 | Are tiers a view of the graph, or a constraint on it? | If a tier is a computed level the word is a convenience. If *a tier may depend only on tiers below it* is to be enforced, it is a constraint and must be stated as one. |
 | Where does resolution happen — the mesh, or the platform's package manager? | The mesh must model mesh-level edges. Whether it also resolves operating-system packages decides whether a solver gets written. |
+| How far may the control plane be split? | A single board over several contexts works because they are contexts *inside* one control plane with one interface. If a context becomes its own deployable with its own interface, the board is coupled to N of them and the composition has nowhere to live that tier 3 permits. A constraint on splitting, worth knowing before splitting. |
 | What does the pipeline schedule, once features are gone? | It schedules features today. The four categories they split into have different lifecycles, so the unit of work differs for each and needs naming. |
 | Should placement leave the catalogue? | A provision pins itself to a named node in the manifest. Placement is an inventory decision, and having it in the catalogue means a second node cannot provide the mesh's store without editing its consumer. |

01-RESEARCH/011-the-module-graph/worked-provider.md

@@ -240,8 +240,31 @@ a context's interface, that interface is inadequate — discovered in the one pl
 cheap to notice, rather than the first time something else needs the same data and quietly
 reaches for the store instead.
 
-If composing many calls turns out too slow, the answer is a projection the board owns and keeps
-current from events — not access to somebody else's tables.
+**But "the board calls each context's interface" is not quite it either**, and the objection is
+right: if every context runs its own service with its own interface, the board is coupled to N
+of them instead of N schemas, something has to compose them, and composition is logic — which
+tier 3 says a surface does not hold. That moves the problem up a layer rather than solving it.
+
+**The skeleton already answers this and the argument above talked past it.** `work` and
+`knowledge` are not separate services; they are **contexts inside the control plane**, alongside
+the record, inventory, delivery and the rest — and `api` is listed there as *the one interface
+every surface speaks to*.
+
+So the board speaks to **one** interface. Behind it the contexts stay separate: separate stores,
+integrating through the record. But they are one tier, one repository, one deployable, and
+coupling *within* a tier is not what the tier rule forbids.
+
+Which resolves the objection rather than deflecting it: the problem does move up a layer, and
+the layer it moves to already exists and has this as its job.
+
+**The caveat is load-bearing.** This holds only while the contexts are not separate deployables.
+The moment one becomes its own service with its own interface, the board is back to N clients,
+something must compose them, and the composition has nowhere to live that tier 3 permits. That
+is a real constraint on how far the control plane may be split, and it is worth knowing now
+rather than discovering it by splitting.
+
+If composing even one interface turns out too slow, the answer is a projection the board owns
+and keeps current from events — not access to somebody else's tables.
 
 ### Checked against the real consumers