# Workload demand forecast — coulomb-social (2026-08)

| Field | Value |
|-------|--------|
| Resource | `resource:tenant:coulomb:coulomb-social` |
| Workplan | CSOC-WP-0005-T01 |
| Forecast version | `csoc-demand-2026-08-v1` |
| Created | 2026-08-12T09:03:47Z |
| Machine record | `demand-forecast-2026-08.json` |

## Scope

Demand for **this production instance** (Coulomb reference tenant on
Railiance). Deployment shape is **instance-per-client** (DR-1 C): future
external customers are **separate instances** and separate resource ids —
they are **not** folded into the high scenario.

| Case | What it models |
|------|----------------|
| **low** | Current parallel-host posture: few operators, Bubble still full product on apex |
| **base** | Coulomb community day-to-day on the rebuild (still one tenant) |
| **high** | Full Bubble-parity load on this Coulomb instance (HA-ish replicas/resources) |

## Proxies (stable units)

| Proxy | Unit | Notes |
|-------|------|--------|
| active_tenants | count | Expected 1 for this instance |
| active_members | MAU-ish Member count | App-owned |
| http_requests_per_month | count | App Service ingress |
| oidc_logins_per_month | count | Successful app logins |
| background_jobs_per_month | count | 0 until workers exist |
| app_database_gb | GB logical | `coulomb_social_db` on apps-pg |
| stored_media_gb | GB | App-owned binaries only |
| forgejo_content_gb_bound | GB | Attribution for space markdown on shared Forgejo |
| ingress_gb / egress_gb | GB/month | App path only |
| cpu/memory request·limit | mCPU / Mi | Declared K8s requirements |
| operator_hours_per_month | hours | Workload labor (T03) |

## Scenario table (monthly)

| Proxy | low | base | high |
|-------|----:|-----:|-----:|
| active_tenants | 1 | 1 | 1 |
| active_members | 5 | 50 | 500 |
| http_requests | 5 000 | 150 000 | 2 000 000 |
| oidc_logins | 80 | 1 500 | 20 000 |
| background_jobs | 0 | 0 | 5 000 |
| app_database_gb | 0.1 | 1 | 10 |
| DB growth %/mo | 5 | 10 | 15 |
| stored_media_gb | 0 | 2 | 50 |
| forgejo_content_gb_bound | 0.01 | 0.5 | 20 |
| ingress_gb | 0.5 | 5 | 40 |
| egress_gb | 1 | 15 | 120 |
| cpu request (m) | 100 | 200 | 500 |
| mem request (Mi) | 256 | 512 | 1024 |
| replicas | 1 | 1 | 2 |
| operator h/mo | 2 | 4 | 8 |
| labor €/mo @ €60/h | 120 | 240 | 480 |

Infrastructure EUR is **not invented** here. Cost joins should treat
infrastructure as an allocated share of cluster, apps-pg, ingress, and
identity platform once those owners and fin-hub supply figures.

## Capacity floor (current deploy declaration)

From `railiance-apps` chart defaults (production values do not override
resources as of 2026-08):

| Dimension | Value |
|-----------|--------|
| replicas | 1 |
| cpu request / limit | 100m / 1000m |
| memory request / limit | 256Mi / 1Gi |
| media PV | disabled |
| Image tag (values) | `7fcd0cf` (railiance-apps helm values; may lag git HEAD) |

## How resource-control should use this

1. Pick scenario band from observed MAU / requests (or default **low** until
   Bubble migration starts).
2. Feed proxies into monthly forecast/actual control (null infrastructure
   until platform prices exist).
3. Attribute Forgejo-bound content via `forgejo_content_gb_bound` without
   double-counting storage in the app resource.
4. Recalibrate after three comparable months (MAPE on members, requests, DB
   GB, labor hours).

## Assumptions and falsifiability

See JSON `assumptions` array. Primary falsifiers after each calendar month:

- measured `active_members` outside the active scenario band by >2×
- `app_database_gb` growth vs declared growth %
- operator hours vs T03 labor log