22100f94cf
Decision records DR-1 (tenancy), DR-2 (coulomb.social shape), DR-3 (external identity) framing the Binky Hedgehog commercial lane on the coulomb/HelixForge platform; coordination workplan for service contract, client-hub scoping, fin-hub billing gap, and delivery-lane pilot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
140 lines
6.5 KiB
Markdown
140 lines
6.5 KiB
Markdown
# Business Platform Decision Records
|
||
|
||
**Created:** 2026-07-10
|
||
**Workplan:** `CUST-WP-0058`
|
||
**Status:** All three decisions **pending** — Bernd's to resolve; this document
|
||
frames options and recommendations only.
|
||
|
||
## Context
|
||
|
||
Binky Hedgehog GmbH intends to build commercial business applications on the
|
||
coulomb/HelixForge platform (Forgejo → railiance-forge → railiance-apps →
|
||
Core Hub ecosystem):
|
||
|
||
1. **vergabe-teilnahme** — tender-participation web app as the first
|
||
commercial offering for business clients.
|
||
2. **coulomb.social rebuild** — replace the current bubble.io implementation
|
||
as the second business project.
|
||
|
||
The hub-ecosystem review (2026-07-09, see `hub-ecosystem-architecture.md`)
|
||
concluded the architecture is sound but three decisions gate the business
|
||
lane. Each is recorded here with options and a recommendation; resolution
|
||
happens via State Hub decision records (`resolve_decision`).
|
||
|
||
---
|
||
|
||
## DR-1 — Tenancy model for vergabe-teilnahme
|
||
|
||
**Status:** pending
|
||
|
||
### Question
|
||
|
||
How are business clients isolated: one deployed instance per client, or one
|
||
multi-tenant instance?
|
||
|
||
### Options
|
||
|
||
| Option | Description | Consequences |
|
||
| --- | --- | --- |
|
||
| **A. Instance-per-client** | Each client gets a dedicated deployment (own DB, own release values in `railiance-apps`) | Strong isolation; simpler compliance story; per-client backup/restore; matches vergabe-teilnahme SCOPE ("no multi-tenancy"); ops-hub must model *client instances*; fin-hub needs per-instance cost attribution; N instances = N upgrade operations |
|
||
| **B. Multi-tenant single instance** | One deployment, tenant column / row-level isolation | Cheaper to operate at scale; contradicts current SCOPE; requires tenancy rework in the app; single blast radius for incidents and data-protection failures |
|
||
| **C. Hybrid (A now, B later)** | Start instance-per-client; revisit at a client-count threshold | Defers rework until demand proves it; risk of never consolidating |
|
||
|
||
### Recommendation
|
||
|
||
**Option A (instance-per-client) for v1**, with an explicit revisit trigger
|
||
(e.g. >5 paying clients or upgrade toil exceeding one operator-day/month).
|
||
It matches the app's current SCOPE, the railiance-apps per-app values
|
||
pattern, and gives the cleanest early compliance/data-protection story for
|
||
German business clients.
|
||
|
||
### Downstream effects once resolved
|
||
|
||
- ops-hub: add client-instance entity (environment × client mapping)
|
||
- fin-hub: per-instance cost attribution keys
|
||
- Business-app service contract (CUST-WP-0058-T04): codify instance
|
||
provisioning/backup/upgrade obligations
|
||
|
||
---
|
||
|
||
## DR-2 — coulomb.social rebuild architecture
|
||
|
||
**Status:** pending
|
||
|
||
### Question
|
||
|
||
Is the coulomb.social rebuild a **Core Hub extension** (hubs/widgets/
|
||
manifests, ops-hub pattern) or a **standalone application** (vergabe-
|
||
teilnahme pattern)?
|
||
|
||
### Options
|
||
|
||
| Option | Description | Consequences |
|
||
| --- | --- | --- |
|
||
| **A. Core Hub extension** | Built on `/api/v2` framework: hubs, widgets, manifests, interaction events | Reuses production framework already at `hub.coulomb.social`; interaction-platform semantics fit; couples product evolution to core-hub framework maturity; framework gaps become product blockers |
|
||
| **B. Standalone app** | Own service repo, own DB, deployed via forge→apps lane like vergabe-teilnahme | Full product freedom; no framework coupling; duplicates interaction/identity plumbing core-hub already has; two social-ish surfaces to keep coherent |
|
||
| **C. Defer until after the vergabe-teilnahme pilot** | Run the delivery-lane pilot first; decide with evidence | Costs calendar time; decision made with real platform evidence instead of speculation |
|
||
|
||
### Recommendation
|
||
|
||
**Option C, with a leaning toward A.** The delivery-lane pilot
|
||
(CUST-WP-0058-T07) will expose whether the forge→apps path and Core Hub
|
||
framework are mature enough to host a client-facing interaction product.
|
||
Deciding now would be speculation; the bubble.io exit additionally needs a
|
||
separately-scoped **data migration** assessment regardless of which shape
|
||
wins.
|
||
|
||
### Downstream effects once resolved
|
||
|
||
- A → core-hub gains its first external-product extension; widget/manifest
|
||
contract hardening becomes product-critical
|
||
- B → second entry in the business-app service contract; shared identity
|
||
becomes the only coupling point
|
||
- Either → bubble.io data-export/migration workplan in the owning repo
|
||
|
||
---
|
||
|
||
## DR-3 — External identity path for business clients
|
||
|
||
**Status:** pending
|
||
|
||
### Question
|
||
|
||
What identity stack serves *external* users (client employees, later
|
||
coulomb.social members): the current lightweight internal stack
|
||
(KeyCape/Authelia/LLDAP) or the proposed expanded-mode Keycloak lane
|
||
(`NK-WP-0011`)?
|
||
|
||
### Options
|
||
|
||
| Option | Description | Consequences |
|
||
| --- | --- | --- |
|
||
| **A. Lightweight stack, app-local accounts for v1** | vergabe-teilnahme manages its own user accounts per instance; platform identity stays internal | Fastest to ship; consistent with instance-per-client isolation; no SSO story; identity debt accrues per app |
|
||
| **B. Activate NK-WP-0011 (Keycloak expanded mode) now** | Platform-level OIDC for external users before first client onboarding | One identity story from day one; enterprise federation ready; heavyweight — delays first client; NK-WP-0011 is only *proposed* |
|
||
| **C. Trigger-based: A for vergabe-teilnahme v1, B gated on defined triggers** | Define explicit conditions that activate the Keycloak lane (e.g. coulomb.social greenlight, first client requesting SSO/AD federation, >2 apps with local accounts) | Ships v1 fast without pretending identity debt doesn't exist; triggers make the debt visible and bounded |
|
||
|
||
### Recommendation
|
||
|
||
**Option C.** Vergabe-teilnahme v1 explicitly excludes external partner
|
||
accounts and is instance-per-client, so app-local auth is defensible *for
|
||
that app*. coulomb.social is the forcing function: any resolution of DR-2
|
||
that greenlights the rebuild should automatically activate the NK-WP-0011
|
||
lane, because a social platform on app-local accounts is not viable.
|
||
|
||
### Downstream effects once resolved
|
||
|
||
- NetKingdom: NK-WP-0011 gets concrete activation triggers instead of
|
||
indefinite "proposed" status
|
||
- Business-app service contract: identity section states which mode each
|
||
app class must use
|
||
|
||
---
|
||
|
||
## Resolution protocol
|
||
|
||
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.
|