011: one interface, many contexts — and the constraint that hides in it

The objection is right: if every context runs its own service with its own
interface, the board is coupled to N interfaces 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 it, and the previous entry talked past it. `work`
and `knowledge` are not separate services; they are contexts INSIDE the control
plane, alongside the record, inventory and delivery — 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,
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. 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 and now recorded as an open question: 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 before splitting rather than after.

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