ADR 0188: a provider declares what it derives for each consumer, and the mesh tells both ends

Issue 124: a value the mesh's own rule produced reached neither end as a
statement. The object store's provisioner derived each consumer's bucket in
its own code; all three consumers transcribed the rule into their own
definitions, one of them wrong, and each of the three also named the machine
it happens to run on.

A served value may now name the consumer the mesh is serving. Design 27
amended; issue 124 resolved.

03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md

@@ -2,7 +2,7 @@
 layer: to-be
 status: in-progress
 code: [mesh-controller internal/catalogue]
-updated: 2026-09-30
+updated: 2026-10-02
 decisions:
   - 02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md
   - 02-DECISIONS/0155-a-definition-names-no-installation-and-how-that-is-checked.md
@@ -14,6 +14,7 @@ decisions:
   - 02-DECISIONS/0084-which-provider-serves-a-consumer.md
   - 02-DECISIONS/0046-a-module-configuration-is-its-assignments-not-its-manifest.md
   - 02-DECISIONS/0038-the-mesh-assigns-the-port.md
+  - 02-DECISIONS/0188-a-provider-declares-what-it-derives-for-each-consumer.md
 ---
 
 # 27 — A module requires, the mesh resolves
@@ -206,6 +207,22 @@ name when nothing sets it. That is the contract half of this design's operator p
 the placeholder allows: the definition says which values reach which requirement, and nothing else
 does. *How it is checked:* the unit tests named in issue 173, and the plan comparison that closed it.
 
+*A provider says once what it derives for each consumer (2026-10-02,
+[ADR 0188](../../02-DECISIONS/0188-a-provider-declares-what-it-derives-for-each-consumer.md),
+[issue 124](../../04-ISSUES/124-a-consumer-cannot-be-told-what-its-provider-derived/00-report.md)):*
+where a provider **names the resource** it gives each consumer — a bucket, a database, a vhost — the
+name is derived per consumer, and a literal `serves` block could not carry it. A served value may
+now name the consumer the mesh is serving: `${consumer:as}`, the identity the mesh minted, and
+`${consumer:as:dns}`, that same identity written as a DNS label. Nothing else — **the mesh learns no
+protocol here; it spells its own name in an alphabet it already knows.** Settings are laid on first,
+so an operator may still set a prefix and the mesh derives the rest. The mesh fills it at the one
+moment it knows who the consumer is, and the one filled value reaches both ends: the consumer, as
+its binding's served facts and as `${bound:<provision>:<key>}` in any file it writes; the provider,
+as `derived` on that consumer's entry in its contributions file, so its provisioner is told the name
+rather than recomputing it. A consumer that writes the derived value into its own definition instead
+of asking for it is refused, naming the placeholder to use. *How it is checked:* the unit tests in
+ADR 0188's "how this is checked", each run against the unchanged controller first.
+
 ## How a definition reads what was resolved
 
 **One form, naming a requirement and a field of its contract.** A definition that needs the database's
@@ -214,7 +231,9 @@ name in a configuration file writes the same thing: the requirement's name and t
 controller fills it at resolution.
 
 This one form replaces the placeholders that exist today, one per mechanism: bound values, secrets,
-ports and machine facts.
+ports and machine facts. It subsumes the consumer placeholder too — a value a provider derives is
+read by the consumer exactly as any other field of the contract is, and `${consumer:…}` is only
+how the *provider* states the rule.
 
 **The seat placeholder stays, for the controller alone.** The controller composes its own
 declaration and reaches the store and broker it made before any module existed, so it cannot be