Multi-Brand Architecture

## Overview hakadoru.ai operates six distinct creative writing brands from a single codebase. **Multi-Brand Architecture is defined as a single-codebase strategy where brand identity — including UI theme, content policy, and LLM routing — is driven entirely by a JSONB configuration object resolved from the request hostname.** This approach eliminates codebase duplication while allowing each brand to present a fully differentiated experience to its users. The six brands emerge from a combinatorial matrix: 3 genres (BL, General Fiction, Fanworks) multiplied by 2 age ratings (all-ages, R18), yielding brands such as "BL小説が捗るAI" (all-ages BL) and "R18小説が捗るAI" (R18 general fiction). ## Background Many SaaS platforms that serve multiple audiences maintain separate deployments or feature-flag-heavy monoliths. Both approaches introduce maintenance overhead: separate deployments drift apart over time, while feature flags accumulate technical debt. The creative writing domain adds a unique dimension — brands differ not only in UI presentation but in LLM behavior, content policy enforcement, and prompt construction. hakadoru.ai needed an architecture where a single deployment could serve brands with fundamentally different content guidelines (all-ages vs. R18) and genre-specific writing assistance (BL romance vs. general fiction vs. fanworks) without code branching. ### The Brand Matrix The six brands are not arbitrary — they emerge from a principled combinatorial design: | Genre | All-Ages | R18 | |---|---|---| | BL (Boys' Love) | BL小説が捗るAI | R18BL小説が捗るAI | | General Fiction | 小説が捗るAI | R18小説が捗るAI | | Fanworks | 二次創作小説が捗るAI | R18二次創作小説が捗るAI | Each cell in this matrix represents a brand with distinct content policies, genre-specific writing guidance, and LLM model routing. The genre axis determines narrative conventions and tone; the age rating axis determines content boundaries and LLM family selection (Claude for all-ages, Qwen 3.5 for R18 per ADR-045). ## Brand Configuration via JSONB The central mechanism is the `brand_config` JSONB column on the `tenants` table. Each brand's configuration contains: - **Theme** — Color palette, logo, typography, and layout preferences - **Preamble layers** — Brand-specific system prompt components (genre tone, content guidelines) - **Feature flags** — Which capabilities are enabled (e.g., R18 dictionary access, specific generation pipelines) - **Content policy** — Allowed content categories, expression constraints, and moderation thresholds - **Model routing** — LLM family selection based on age rating (Claude for all-ages, Qwen for R18 per ADR-045) This JSONB-driven approach means adding a new brand or adjusting an existing brand's behavior requires no code changes — only a configuration update. ## Host-Based Brand Resolution Brand identity is resolved at the edge of every request through a deterministic pipeline: 1. The incoming request's `Host` header is extracted 2. The hostname is matched against the `tenants` table 3. The corresponding `brand_config` JSONB is loaded and cached 4. All downstream logic — UI rendering, prompt assembly, model selection, content filtering — reads from this resolved configuration This resolution happens once per request and propagates through the entire stack. There is no ambient "current brand" global state; the brand context is explicitly threaded through service calls. ## Shared Infrastructure All six brands share a single database schema, a single set of API endpoints, and a single SPA bundle. Row-Level Security (RLS) policies enforce tenant isolation at the database level. The SPA reads theme tokens from the resolved brand configuration to render the appropriate visual identity. This sharing extends to database migrations, deployment pipelines, and monitoring. A single deployment serves all brands, and a single migration updates all brand schemas simultaneously. ## Model Routing by Brand One of the most consequential brand-driven behaviors is LLM model selection. Rather than routing by content sensitivity (which would require pre-classification of each request), hakadoru.ai routes by brand age rating: - **All-ages brands** use the Claude model family (Haiku for lightweight tasks, Sonnet for standard generation, Opus for complex analysis) for all operations including generation, review, and verification - **R18 brands** use the Qwen 3.5 model family (9B/35B/122B in a 3-tier elastic configuration) for all operations - **Cohere Command R+** is maintained as a fallback for both families in case of provider outages This brand-based routing simplifies the architecture significantly. There is no per-request content analysis, no dynamic model switching, and no cross-model review. The brand configuration determines the model family once, and all downstream operations use that family consistently. ## Configuration Versioning Brand configurations evolve over time as content policies are refined and features are launched. The `brand_config_history` table maintains a complete version history of every configuration change, enabling: - **Audit trails** — Regulatory compliance for content policy changes - **Rollback** — Reverting a brand to a previous configuration state - **A/B testing** — Comparing user engagement metrics across configuration versions - **Debugging** — Reproducing issues by examining the configuration active at the time of a user report ## Comparison with Other Approaches Most AI writing tools operate as a single brand with a single content policy. Tools like NovelAI offer content toggles within one product, while others like Sudowrite maintain a single editorial voice. hakadoru.ai's multi-brand architecture differs fundamentally: each brand is a complete, independently branded product with its own domain, visual identity, content policy, and LLM routing — yet all are powered by one codebase and one deployment. The alternative approach of maintaining separate codebases per brand was rejected due to the multiplicative maintenance burden across six brands. The JSONB-driven approach keeps operational complexity constant regardless of brand count. A middle-ground approach — one codebase with compile-time brand selection — was also considered and rejected. While it avoids codebase duplication, it still requires separate build and deployment pipelines per brand. hakadoru.ai's runtime configuration resolution eliminates this overhead entirely: a single build artifact serves all brands, with brand differentiation happening at request time rather than build time. ## Operational Benefits The multi-brand architecture yields several operational advantages beyond code sharing: - **Single deployment pipeline** — One CI/CD pipeline builds, tests, and deploys all six brands. There is no per-brand build matrix. - **Unified monitoring** — A single observability stack covers all brands, with brand-level filtering in dashboards - **Shared security posture** — A vulnerability fix or security patch is deployed once and protects all brands immediately - **Proportional scaling** — Infrastructure scales based on total traffic across all brands, not per-brand capacity planning ## Conclusion Multi-Brand Architecture allows hakadoru.ai to serve six distinct creative writing communities — each with tailored genre support, content policies, and LLM configurations — from a single codebase and deployment. The JSONB configuration pattern keeps brand-specific logic in data rather than code, enabling rapid brand iteration and ensuring that infrastructure improvements benefit all brands simultaneously. This architecture scales naturally: adding a seventh brand requires only a new `brand_config` row, not a new deployment.