From a4a25ca7e39b822c12c99f08b2a213485805b6d4 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 26 Aug 2026 23:27:42 +0200 Subject: [PATCH] 011: one surface over several contexts is normal MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The board visualises the mesh, the work engine, the knowledge base and more, and the alternative — a web application per context — is worse for everyone using it. Composing several sources into one view is what a surface IS, so this is not a compromise with the ownership rule. What changes is only where it reads from: each context's interface rather than each context's store. Most of that already exists — 56 of 126 modules carry a tool surface, more than carry a service. And the unified board is what keeps those interfaces honest. A view that cannot be built from a context's interface proves the interface inadequate, discovered where it is 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 proves too slow, the answer is a projection the board owns and keeps current from events, not access to somebody else's tables. --- .../011-the-module-graph/worked-provider.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/01-RESEARCH/011-the-module-graph/worked-provider.md b/01-RESEARCH/011-the-module-graph/worked-provider.md index 9c38023..7abac32 100644 --- a/01-RESEARCH/011-the-module-graph/worked-provider.md +++ b/01-RESEARCH/011-the-module-graph/worked-provider.md @@ -226,6 +226,23 @@ context reading it. Which is exactly what the count below shows: the problem was never surfaces. It was three other contexts keeping their tables in the mesh's database. +**And one surface over several contexts is normal.** The board visualises the mesh, the work +engine, the knowledge base and more, and the alternative — a separate web application per +context — is worse for everyone who uses it. That is not a compromise with the rule; composing +several sources into one view is what a surface *is*. + +What it changes is only where it reads from: each context's **interface**, not each context's +**store**. Most of that already exists — 56 of 126 modules carry a tool surface, more than carry +a service. + +**And the unified board is what keeps those interfaces honest.** If a view cannot be built from +a context's interface, that interface is inadequate — discovered in the one place where it is +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. + ### Checked against the real consumers The rule's survival turned on whether every reader of the mesh's own registry could be served