011: the dashboard case, and why exclusive ownership is the tier rule

Raised as the hardest test of the rule: a board showing nodes, modules, pipelines, agents and tasks wants to read a dozen stores, and under exclusive ownership it can read none of them. It survives, and not by luck. The board is a SURFACE, and surfaces already may not do this — the skeleton puts `api/` in the control plane as the one interface every surface speaks to, and tier 3 as thin, no logic. A board reading stores directly is a surface reaching past the context that owns the data, which the tier rule forbids for reasons that have nothing to do with databases. So it is not a counter-example; it is an instance the rule catches. And the two rules turn out to be one rule seen from two sides: exclusive ownership is the tier rule expressed in terms of storage. The general shape for anything needing to see across many things: consume the record and own your own view. A reporting context builds a projection from events and reads its own store, never anybody else's. The cost said plainly rather than buried: a projection is more work than a join, and it lags. A board queries the mesh's own database directly today — ordinary, working — and this rule makes that a migration rather than a preference. The reason to pay it is §4's already-measured cost, not elegance.
2026-08-26 23:10:36 +02:00
parent aa767d17a8
commit 6b1aab6a1e
1 changed files with 24 additions and 0 deletions
@@ -208,6 +208,30 @@ first clear instance:
  against itself.
 - **A whole class of permission modelling** that a shared store would otherwise need.
 ### The hardest case for it: a dashboard reading everything
 Raised immediately, and it is the right test — a board showing nodes, modules, pipelines, agents
 and tasks wants to read a dozen stores. Under this rule it cannot read any of them.
 **It survives, and not by luck: the board is a surface, and surfaces already may not do this.**
 The skeleton puts `api/` in the control plane as *the one interface every surface speaks to*, and
 tier 3 as *thin; no logic lives here*. A board reading stores directly is a surface reaching past
 the context that owns the data — which the tier rule forbids for reasons that have nothing to do
 with databases.
 So the dashboard is not a counter-example. It is an instance the rule catches, and the two rules
 turn out to be one rule seen from two sides: **exclusive ownership is the tier rule, expressed in
 terms of storage.**
 **The general shape, for anything that needs to see across many things:** consume the record and
 own your own view. A reporting context builds a projection from events and reads its own store.
 It does not read anybody else's.
 **And the cost is not small, so it should be said plainly.** A projection is more work than a
 join, and it lags. Today a board queries the mesh's own database directly — that is ordinary,
 it works, and this rule makes it a migration rather than a preference. The reason to pay it is
 [`how-we-build`](../../00-META/how-we-build.md) §4's already-measured cost, not elegance.
 ### What it does not answer
 **The mesh's own registry is read by many things.** Under this rule they cannot read its tables,