CUST-WP-0058: DR-1/2/3 resolved — consistency refinement, plan activated

DR-1: C (instance-per-client, early cost-optimization move)
DR-2: B (coulomb.social standalone app; Binky Hedgehog as client #1)
DR-3: A (app-local accounts; demand-gated NK-WP-0011 triggers)

Refinements: consolidation-ready data model required by the service
contract; coulomb.social auto-trigger for Keycloak retired in favor of
three demand triggers. T01-T03 done (NetKingdom notified), T04/T05
unblocked, workplan active.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/business-platform-decision-records.md

@@ -2,8 +2,10 @@
 
 **Created:** 2026-07-10
 **Workplan:** `CUST-WP-0058`
-**Status:** All three decisions **pending** — Bernd's to resolve; this document
-frames options and recommendations only.
+**Status:** All three decisions **resolved** by Bernd on 2026-07-10 (hub
+decision records `d85cd185…`, `1f8b109e…`, `ebcf0573…`). See *Resolutions and
+consistency refinement* at the end; the option tables below are kept as
+decision history.
 
 ## Context
 
@@ -25,7 +27,7 @@ happens via State Hub decision records (`resolve_decision`).
 
 ## DR-1 — Tenancy model for vergabe-teilnahme
 
-**Status:** pending
+**Status:** resolved 2026-07-10 — **Option C** (hybrid)
 
 ### Question
 
@@ -59,7 +61,7 @@ German business clients.
 
 ## DR-2 — coulomb.social rebuild architecture
 
-**Status:** pending
+**Status:** resolved 2026-07-10 — **Option B** (standalone application)
 
 ### Question
 
@@ -96,7 +98,7 @@ wins.
 
 ## DR-3 — External identity path for business clients
 
-**Status:** pending
+**Status:** resolved 2026-07-10 — **Option A** (app-local accounts), demand-gated follow-up
 
 ### Question
 
@@ -130,11 +132,60 @@ lane, because a social platform on app-local accounts is not viable.
 
 ---
 
-## Resolution protocol
+## Resolutions and consistency refinement (2026-07-10)
 
-1. Each DR is registered as a pending State Hub decision (custodian topic).
-2. Bernd resolves via `resolve_decision()` or by stating the choice in a
-   session; the resolving agent updates this document's status lines and the
-   hub record together.
-3. `CUST-WP-0058` tasks T01–T03 track the facilitation; downstream tasks
-   stay `wait` until their gating DR is resolved.
+All three decisions were resolved by Bernd in the State Hub on 2026-07-10.
+The resolved set was then reviewed for internal consistency; two refinements
+follow from reading the three choices together.
+
+### Resolved set
+
+| DR | Choice | Bernd's rationale (hub record) |
+| --- | --- | --- |
+| DR-1 | **C — hybrid** | Instance-per-client to serve early customers easily, but "move on to resource cost optimization early" |
+| DR-2 | **B — standalone app** | coulomb.social is its own application, distinct in purpose and operations model; an application *of* Binky Hedgehog GmbH just as other apps are provided to clients; the fact that Binky Hedgehog provides the ecosystem (coulomb domain, Forgejo repos) is not relevant to the app itself |
+| DR-3 | **A — app-local accounts** | Lightweight version now; follow up with Keycloak (NK-WP-0011) only on actual demand |
+
+### Unifying model
+
+**Binky Hedgehog GmbH is client #1 of its own platform.** coulomb.social is
+delivered through the same standalone-app lane, service contract, and tenancy
+rules as apps sold to external clients. There is exactly one app shape
+(standalone service, forge→apps delivery) and one tenancy default
+(instance-per-client) — no special cases.
+
+### Refinement 1 — consolidation-readiness (DR-1 C ↔ DR-3 A)
+
+DR-1's early cost-optimization move implies consolidating instances later,
+which app-local accounts per instance would turn into an account-migration
+problem. Therefore:
+
+- The business-app service contract (CUST-WP-0058-T04) **must require
+  consolidation-ready design**: tenant-clean data model (all client data
+  keyed by a tenant identifier) even when deployed single-tenant.
+- **Instance consolidation is itself a DR-3 demand trigger**: when the
+  cost-optimization move consolidates instances, the platform-identity
+  follow-up (NK-WP-0011) activates as part of that move.
+
+### Refinement 2 — identity triggers corrected (DR-2 B ↔ DR-3 A)
+
+The original DR-3 framing made a coulomb.social greenlight an automatic
+Keycloak trigger. DR-2 B + DR-3 A overrule this: a standalone social app
+owning its own user accounts is a normal, viable shape. The corrected,
+purely demand-based triggers for activating NK-WP-0011 are:
+
+1. A client requests SSO / AD federation.
+2. Instance consolidation under DR-1's cost-optimization move (Refinement 1).
+3. Operational toil from local account administration across >2 apps.
+
+### Downstream actions
+
+- T04 service contract: encode instance-per-client provisioning,
+  consolidation-ready data model, app-local identity baseline.
+- T05 client-hub scoping: client↔instance mapping assumes 1..n instances per
+  client, consolidation-aware.
+- NetKingdom lane notified: NK-WP-0011 stays proposed with the three triggers
+  above (no auto-activation).
+- coulomb.social rebuild + bubble.io migration assessment: seeded as
+  standalone-app workplan skeletons (T08), consuming the same delivery lane
+  as vergabe-teilnahme.