Documentation source

Venture Factory

A reusable 3-layer operating model for running ventures idea→exit — an unopinionated portfolio foundation, optional Studio-Method and Capital add-ons, and a re-runnable installer that clones the whole stack into a new venture tenant.

# Venture Factory

The **Venture Factory** is an operating model for running ventures from idea to exit on the Sprinter Platform. It is not a new engine — it is a *reusable stack of installable surfaces* (workspaces, entity types, SOPs, criteria sets, agents, actions) plus a **re-runnable installer** that stands a new venture tenant up from nothing. A tenant that installs the stack gets a portfolio command center, a customer-discovery canvas, a fundraising surface, and the 0→1 SOPs to drive a venture through every stage.

**Praxium** is the reference tenant — the spin-out of DOC'S / DOC360 into a protocol-intelligence layer for multi-modality wellness studios. It is venture #1 inside its own factory: the OS operating the company that builds the OS's first customer. Praxium dogfoods the operating model end-to-end.

> The Venture Factory builds on the reusable 3-layer OS from `documents/work/2026-06-06-venture-factory-reusable-os/` and is specified in [ADR-0062](https://github.com/sprinterhq/amble/blob/main/documents/adr/0062-venture-factory-template-tenant.md). The architecture decisions below are the authoritative summary.

## Overview

The factory is organized as three layers, with a hard reusability boundary between them:

```
L0 Platform kernel — entity engine, workspace templates, bundle installer, SOPs, criteria sets
L1 Installable bundles — venture-factory + studio-method + capital + operating workspaces (reusable, any tenant)
L3 Tenant seed — Praxium as venture #1 + the venture-creation SOP set (one tenant, never bundled)
```

The whole point is **install, don't fork**. A new venture is not a repo fork — it is a tenant the installer points at. Every venture tenant runs the same code; only the seed (the venture's own records) differs. This is the same boundary the platform draws everywhere (`features/` ex-`custom/` is shared; `features/custom/tenants/<slug>/` is the only thing that changes per venture).

A venture factory adds **zero new platform surface**. Per the [surface-area-stewardship rule](https://github.com/sprinterhq/amble/blob/main/.claude/rules/surface-area-stewardship.md), it adds capability by *installing* primitives the platform already ships — entity types as DB-driven rows, workspace templates, SOP entities, criteria sets — so the kernel stays thin.

## Key Concepts

**The 3-layer model.** L0 is the untouched platform kernel. L1 is a set of *installable bundles* that are tenant-agnostic and slug-clean — any venture tenant can install them. L3 is the per-tenant seed (the individual venture's data), seeded only into the reference tenant, never bundled into the templates. This mirrors the [original Venture-Factory OS epic](https://github.com/sprinterhq/amble/blob/main/documents/work/2026-06-06-venture-factory-reusable-os/spec.md), which established the L1 foundation and the optional Studio-Method add-on; this work extends it with the Capital add-on, the reference tenant, and the re-runnable installer.

**The installed workspaces.** A fully-loaded venture tenant runs across these workspace templates (each installed from `features/custom/workspaces/`):

- **`venture-factory`** — the unopinionated L1 foundation: a `venture` portfolio table, generic venture detail, a pipeline-by-stage board, and a portfolio command center. Ships *empty* — stage and archetype are configurable free fields, no enforced taxonomy.
- **`venture-factory-studio-method`** — the optional opinionated L1 add-on. Installing it turns the blank portfolio into the full Sprinter Studio methodology: the customer-discovery canvas (`vf_*` ICP / JTBD / pain-point / GTM-experiment / gate entity types), the venture-priority and Gate 0–6 criteria sets, the stage taxonomy, the Forge meta-agent, and per-stage action templates (dormant by default).
- **`venture-factory-capital`** — the optional Capital add-on (new in this work). The fundraising / money side of a 0→1 venture (see below).
- **`command-center`** — the operating cockpit: workstreams, processes, tasks, and the portfolio dashboard a venture is run from day-to-day.
- **`social-suite`** — social presence and analytics for member / audience growth.
- **`marketing`** — campaign series, content briefs, content pieces, distribution runs, brand + voice profiles.
- **`opportunity-studio`** — opportunity / lead discovery and qualification.

A tenant can start blank (L1 foundation only) or batteries-included (foundation + studio-method + capital + operating workspaces). The factory composes coherently at either end.

**The Capital add-on.** `venture-factory-capital` is config over existing primitives — a bundle of DB-driven entity types plus a go/no-go gate, *not* a new module. It declares the fundraising surface a venture needs:

- `vf_fundraise_round` — a financing round (stage, target, raised, terms).
- `vf_investor` — investors and their relationship to rounds.
- `vf_financial_model` — the venture's financial model.
- `vf_assumption` — the load-bearing assumptions a model and a raise depend on.
- `vf_deck_artifact` — the pitch / go-no-go deck the venture produces.
- a **go/no-go criteria set** — reusing the same scoring + gate machinery the Studio Method's Gate 0–6 sets use.

Each entity type ships a Zod-backed `json_schema` (Critical Rule 2 — entity types are DB-driven, with a Zod schema per the tenant-modules static-literal invariant). The `vf_` method-namespaced prefix keeps every slug tenant-agnostic — never `praxium_*` — so the bundle installs into *any* venture tenant. It installs *on top of* L1, exactly like the Studio Method, and is discoverable in the install gallery as an optional add-on.

**The venture-creation SOP set.** The 0→1 process is captured as a set of SOP *entities* (per [ADR-0055](https://github.com/sprinterhq/amble/blob/main/documents/adr/0055-sop-living-entity-over-action-spine.md) — SOP as living entity, not a new automation spine), importable and shared across venture tenants. They walk a venture through the lifecycle: ideate → validate → score → gate-check → scope → launch → grow → (sunset). Each SOP is a living, runnable document — a human can walk it, or an agent can drive it.

## How It Works

### The installer is the clone mechanism

A new venture tenant is stood up in two moves: **install the workspace stack** (an operator action, in-app), then **run the installer** against the new slug to seed the data. `scripts/seed-venture-factory-tenant.ts` takes a `slug=<tenant>` parameter and seeds the venture-creation SOPs (and, with `--demo`, venture #1) into that tenant:

```
pnpm seed:venture-factory slug=<tenant> [--demo] [--apply]
├─ report which of the 7 venture-factory workspaces are installed
├─ hard-error if their entity types are missing (install the workspaces first)
├─ seed the venture-creation SOP set (idempotent)
└─ (with --demo) seed Praxium as venture #1 + its canvas/capital records
```

The installer seeds **data, not workspaces.** It dry-runs by default (writes only with `--apply`), every write carries `tenant_id`, ids are deterministic (UUID-v5 keyed on the tenant slug) so re-runs converge, and it refuses to run until the workspaces' entity types are installed. Installing the workspace surfaces themselves is the operator's job — the in-app install gallery, or `install_bundle()` SQL ([ADR-0058](https://github.com/sprinterhq/amble/blob/main/documents/adr/0058-plugins-unified-install-surface.md)) — because `installWorkspaceFromTemplate` needs an authenticated request context and cannot run headless from a script. Standing up venture #2 is: install the stack from the gallery, then re-run the installer against the new slug — not forking a repo.

### Praxium — the reference tenant (dogfood)

`features/custom/tenants/praxium/` is a *thin* `TenantModule` (per [ADR-0029](https://github.com/sprinterhq/amble/blob/main/documents/adr/0029-tenant-module-client-safe-index.md) — a client-safe `index.ts` plus a data-heavy `declarations.server.ts`). It declares *what to install*, not new mechanics. Praxium's own product — protocol intelligence for wellness studios — is modeled **as a venture inside the factory**: a `venture` record (venture #1), its ICP / JTBD / GTM-experiment canvas records in the Studio-Method surface, its fundraise round and financial model in the Capital surface, and its growth loops in the operating workspaces. The OS running the venture that is the OS's first reference customer is the dogfood.

### Human-led vs agent-driven modes

The same SOPs and surfaces support two operating modes, and the factory is designed to slide between them:

- **Human-led** — a founder/operator walks the SOPs and works the workspaces directly. SOP steps are checklists; gates are human go/no-go decisions; the canvas and capital records are filled by hand. The factory is a structured workspace.
- **Agent-driven** — the Forge meta-agent and per-stage agents drive the same SOPs, with humans gating only the irreversible decisions (spend, kill, exit) as `waiting_human` tasks. Per-stage autopilot/cron *action templates* are installed by the Studio Method but ship **dormant by default** (gated by `isCronAllowed()` + an explicit enable) — the template proves the structure; live autonomous firing is a downstream epic.

Most ventures run a blend: a human owns strategy and the irreversible gates while agents do research, scoring, drafting, and the repetitive growth-loop work. Because both modes share one set of SOPs, entity types, and criteria sets, switching a step from human to agent (or back) is a matter of *who runs it*, not a reimplementation.

## Spinning up a new venture tenant

The end-to-end flow for cloning the factory into a new venture:

1. **Create the tenant** (Admin, or platform tenant provisioning).
2. **Install the workspace stack** — from the in-app install gallery (or `install_bundle()` SQL): the `venture-factory` foundation, optionally the `studio-method` and `capital` add-ons on top of L1, and the operating workspaces (command-center, social-suite, marketing, opportunity-studio). A freshly-authored bundle is installable into a live tenant only after it has merged and deployed.
3. **Run the installer** — `pnpm seed:venture-factory slug=<new-slug> --apply` seeds the venture-creation SOP set into the new tenant. This is the clone of the operating playbook.
4. **Seed venture #1** (optional) — add `--demo` to also create the first `venture` record and its canvas / capital / growth records, or the founder creates them by hand.
5. **Operate** — run the venture-creation SOPs human-led, agent-driven, or blended. Gates, scores, and the portfolio command center light up as records accumulate.

Because every venture tenant runs the same installed code, the operating model, the SOPs, and the scoring rubrics are identical across the portfolio — only each venture's *data* differs.

## For Agents

The Venture Factory reaches agents through the surfaces it installs — there is no Venture-Factory-specific tool to learn:

- **SOPs as the operating playbook.** The venture-creation SOPs are SOP entities ([ADR-0055](https://github.com/sprinterhq/amble/blob/main/documents/adr/0055-sop-living-entity-over-action-spine.md)) an agent can run step by step. The `.claude/skills/venture-*` skills (`venture-ideate`, `venture-validate`, `venture-score`, `venture-gate-check`, `venture-scope`, `venture-launch`, `venture-growth-loop`, `venture-sunset`, and `venture-forge` for orchestration) encode each subprocess and are individually invocable.
- **Records via the entity tools.** The `venture`, `vf_*` canvas, and capital entity types are DB-driven — an agent reads and writes them with `createEntity` / `createRelation` / `updateEntity`, the same as any other entity type. Stage advances, scoring, and gate checks are entity updates against criteria sets, not bespoke calls.
- **Gates as criteria sets.** Go/no-go and Gate 0–6 decisions are criteria sets — an agent scores a venture against the rubric and the gate machinery produces the verdict.
- **Dormant actions.** Per-stage autopilot/cron action templates exist on `actions` rows but do not fire until explicitly enabled (and only when `isCronAllowed()` permits) — an agent enabling a loop is enabling existing config, not building a new one.

## Design Decisions

**The factory is installable surfaces, not a new engine.** The strongest temptation was a `features/venture-factory/` platform engine. That would be a parallel system competing with the workspace-template, bundle-installer, SOP, and criteria-set primitives the platform already owns. Instead the factory is *config over those primitives* — every layer is an install of existing code. This is the no-parallel-systems rule applied literally.

**Three separate add-ons, not one mega-template.** The foundation, Studio Method, and Capital are *separate installable bundles* so a tenant can start blank or batteries-included and opt in per layer. Collapsing them into one install would destroy the optionality the operating model is built to deliver — a venture that wants the portfolio but not the fundraising surface (or vice versa) must be able to choose.

**The installer is the clone mechanism.** Rather than a bespoke "create venture" code path, cloning the factory is *installing the stack from the gallery, then re-running one idempotent, tenant-parameterized seed script* for the data. The script seeds SOPs + the optional demo (not workspaces — those install via the gallery / `install_bundle()`), so venture #2..N cost a couple of commands, not a fork.

**Slugs are method-namespaced, never tenant-named.** The Capital entity types use the `vf_` prefix (continuing the prior epic's move away from the tenant-specific `vs_*`). A slug named for a single tenant makes the bundle non-reusable — `vf_` keeps the types tenant-agnostic and the installer maps them into whatever tenant it targets.

**Praxium dogfoods the product it sells.** The reference tenant is not a synthetic demo — it is a real venture (protocol intelligence for wellness studios) run as venture #1 inside the factory. Dogfooding the operating model end-to-end surfaces gaps a spec never would, and proves the "batteries-included" path and install ordering against a real workload.

## Related Modules

- **Workspaces** (`features/workspaces/`, `features/custom/workspaces/`) — the workspace templates the factory installs. See [Workspaces](/docs/features/workspaces), [Workspace Templates](/docs/features/workspace-templates), [Custom Workspaces](/docs/features/custom-workspaces).
- **Plugins** (`features/plugins/`) — the unified install surface (ADR-0058) the workspace stack and the add-on gallery install through (the data installer seeds on top of it). See [Plugins](/docs/features/plugins) and [Bundles](/docs/features/bundles).
- **SOPs** (`features/custom/`, SOP entities) — the venture-creation playbook as living, runnable documents (ADR-0055). See [SOPs](/docs/features/sops).
- **Command Center** — the operating cockpit a venture is run from. See [Command Center](/docs/features/command-center).
- **Entity System** (`features/entities/`) — the `venture`, `vf_*` canvas, and Capital entity types whose `json_schema` drives forms / cards / details automatically. See [Entity System](/docs/features/entity-system).
- **Multi-tenant** (`features/tenant/`) — the tenant boundary that makes each venture a tenant the installer points at. See [Multi-tenant](/docs/features/multi-tenant).

# Venture Factory The **Venture Factory** is an operating model for running ventures from idea to exit on the Sprinter Platform. It is not a new engine — it is a *reusable stack of installable surfaces* (workspaces, entity types, SOPs, criteria sets, agents, actions) plus a **re-runnable installer** that stands a new venture tenant up from nothing. A tenant that installs the stack gets a portfolio command center, a customer-discovery canvas, a fundraising surface, and the 0→1 SOPs to drive a venture through every stage. **Praxium** is the reference tenant — the spin-out of DOC'S / DOC360 into a protocol-intelligence layer for multi-modality wellness studios. It is venture #1 inside its own factory: the OS operating the company that builds the OS's first customer. Praxium dogfoods the operating model end-to-end. > The Venture Factory builds on the reusable 3-layer OS from `documents/work/2026-06-06-venture-factory-reusable-os/` and is specified in [ADR-0062](https://github.com/sprinterhq/amble/blob/main/documents/adr/0062-venture-factory-template-tenant.md). The architecture decisions below are the authoritative summary. ## Overview The factory is organized as three layers, with a hard reusability boundary between them: ``` L0 Platform kernel — entity engine, workspace templates, bundle installer, SOPs, criteria sets L1 Installable bundles — venture-factory + studio-method + capital + operating workspaces (reusable, any tenant) L3 Tenant seed — Praxium as venture #1 + the venture-creation SOP set (one tenant, never bundled) ``` The whole point is **install, don't fork**. A new venture is not a repo fork — it is a tenant the installer points at. Every venture tenant runs the same code; only the seed (the venture's own records) differs. This is the same boundary the platform draws everywhere (`features/` ex-`custom/` is shared; `features/custom/tenants/<slug>/` is the only thing that changes per venture). A venture factory adds **zero new platform surface**. Per the [surface-area-stewardship rule](https://github.com/sprinterhq/amble/blob/main/.claude/rules/surface-area-stewardship.md), it adds capability by *installing* primitives the platform already ships — entity types as DB-driven rows, workspace templates, SOP entities, criteria sets — so the kernel stays thin. ## Key Concepts **The 3-layer model.** L0 is the untouched platform kernel. L1 is a set of *installable bundles* that are tenant-agnostic and slug-clean — any venture tenant can install them. L3 is the per-tenant seed (the individual venture's data), seeded only into the reference tenant, never bundled into the templates. This mirrors the [original Venture-Factory OS epic](https://github.com/sprinterhq/amble/blob/main/documents/work/2026-06-06-venture-factory-reusable-os/spec.md), which established the L1 foundation and the optional Studio-Method add-on; this work extends it with the Capital add-on, the reference tenant, and the re-runnable installer. **The installed workspaces.** A fully-loaded venture tenant runs across these workspace templates (each installed from `features/custom/workspaces/`): - **`venture-factory`** — the unopinionated L1 foundation: a `venture` portfolio table, generic venture detail, a pipeline-by-stage board, and a portfolio command center. Ships *empty* — stage and archetype are configurable free fields, no enforced taxonomy. - **`venture-factory-studio-method`** — the optional opinionated L1 add-on. Installing it turns the blank portfolio into the full Sprinter Studio methodology: the customer-discovery canvas (`vf_*` ICP / JTBD / pain-point / GTM-experiment / gate entity types), the venture-priority and Gate 0–6 criteria sets, the stage taxonomy, the Forge meta-agent, and per-stage action templates (dormant by default). - **`venture-factory-capital`** — the optional Capital add-on (new in this work). The fundraising / money side of a 0→1 venture (see below). - **`command-center`** — the operating cockpit: workstreams, processes, tasks, and the portfolio dashboard a venture is run from day-to-day. - **`social-suite`** — social presence and analytics for member / audience growth. - **`marketing`** — campaign series, content briefs, content pieces, distribution runs, brand + voice profiles. - **`opportunity-studio`** — opportunity / lead discovery and qualification. A tenant can start blank (L1 foundation only) or batteries-included (foundation + studio-method + capital + operating workspaces). The factory composes coherently at either end. **The Capital add-on.** `venture-factory-capital` is config over existing primitives — a bundle of DB-driven entity types plus a go/no-go gate, *not* a new module. It declares the fundraising surface a venture needs: - `vf_fundraise_round` — a financing round (stage, target, raised, terms). - `vf_investor` — investors and their relationship to rounds. - `vf_financial_model` — the venture's financial model. - `vf_assumption` — the load-bearing assumptions a model and a raise depend on. - `vf_deck_artifact` — the pitch / go-no-go deck the venture produces. - a **go/no-go criteria set** — reusing the same scoring + gate machinery the Studio Method's Gate 0–6 sets use. Each entity type ships a Zod-backed `json_schema` (Critical Rule 2 — entity types are DB-driven, with a Zod schema per the tenant-modules static-literal invariant). The `vf_` method-namespaced prefix keeps every slug tenant-agnostic — never `praxium_*` — so the bundle installs into *any* venture tenant. It installs *on top of* L1, exactly like the Studio Method, and is discoverable in the install gallery as an optional add-on. **The venture-creation SOP set.** The 0→1 process is captured as a set of SOP *entities* (per [ADR-0055](https://github.com/sprinterhq/amble/blob/main/documents/adr/0055-sop-living-entity-over-action-spine.md) — SOP as living entity, not a new automation spine), importable and shared across venture tenants. They walk a venture through the lifecycle: ideate → validate → score → gate-check → scope → launch → grow → (sunset). Each SOP is a living, runnable document — a human can walk it, or an agent can drive it. ## How It Works ### The installer is the clone mechanism A new venture tenant is stood up in two moves: **install the workspace stack** (an operator action, in-app), then **run the installer** against the new slug to seed the data. `scripts/seed-venture-factory-tenant.ts` takes a `slug=<tenant>` parameter and seeds the venture-creation SOPs (and, with `--demo`, venture #1) into that tenant: ``` pnpm seed:venture-factory slug=<tenant> [--demo] [--apply] ├─ report which of the 7 venture-factory workspaces are installed ├─ hard-error if their entity types are missing (install the workspaces first) ├─ seed the venture-creation SOP set (idempotent) └─ (with --demo) seed Praxium as venture #1 + its canvas/capital records ``` The installer seeds **data, not workspaces.** It dry-runs by default (writes only with `--apply`), every write carries `tenant_id`, ids are deterministic (UUID-v5 keyed on the tenant slug) so re-runs converge, and it refuses to run until the workspaces' entity types are installed. Installing the workspace surfaces themselves is the operator's job — the in-app install gallery, or `install_bundle()` SQL ([ADR-0058](https://github.com/sprinterhq/amble/blob/main/documents/adr/0058-plugins-unified-install-surface.md)) — because `installWorkspaceFromTemplate` needs an authenticated request context and cannot run headless from a script. Standing up venture #2 is: install the stack from the gallery, then re-run the installer against the new slug — not forking a repo. ### Praxium — the reference tenant (dogfood) `features/custom/tenants/praxium/` is a *thin* `TenantModule` (per [ADR-0029](https://github.com/sprinterhq/amble/blob/main/documents/adr/0029-tenant-module-client-safe-index.md) — a client-safe `index.ts` plus a data-heavy `declarations.server.ts`). It declares *what to install*, not new mechanics. Praxium's own product — protocol intelligence for wellness studios — is modeled **as a venture inside the factory**: a `venture` record (venture #1), its ICP / JTBD / GTM-experiment canvas records in the Studio-Method surface, its fundraise round and financial model in the Capital surface, and its growth loops in the operating workspaces. The OS running the venture that is the OS's first reference customer is the dogfood. ### Human-led vs agent-driven modes The same SOPs and surfaces support two operating modes, and the factory is designed to slide between them: - **Human-led** — a founder/operator walks the SOPs and works the workspaces directly. SOP steps are checklists; gates are human go/no-go decisions; the canvas and capital records are filled by hand. The factory is a structured workspace. - **Agent-driven** — the Forge meta-agent and per-stage agents drive the same SOPs, with humans gating only the irreversible decisions (spend, kill, exit) as `waiting_human` tasks. Per-stage autopilot/cron *action templates* are installed by the Studio Method but ship **dormant by default** (gated by `isCronAllowed()` + an explicit enable) — the template proves the structure; live autonomous firing is a downstream epic. Most ventures run a blend: a human owns strategy and the irreversible gates while agents do research, scoring, drafting, and the repetitive growth-loop work. Because both modes share one set of SOPs, entity types, and criteria sets, switching a step from human to agent (or back) is a matter of *who runs it*, not a reimplementation. ## Spinning up a new venture tenant The end-to-end flow for cloning the factory into a new venture: 1. **Create the tenant** (Admin, or platform tenant provisioning). 2. **Install the workspace stack** — from the in-app install gallery (or `install_bundle()` SQL): the `venture-factory` foundation, optionally the `studio-method` and `capital` add-ons on top of L1, and the operating workspaces (command-center, social-suite, marketing, opportunity-studio). A freshly-authored bundle is installable into a live tenant only after it has merged and deployed. 3. **Run the installer** — `pnpm seed:venture-factory slug=<new-slug> --apply` seeds the venture-creation SOP set into the new tenant. This is the clone of the operating playbook. 4. **Seed venture #1** (optional) — add `--demo` to also create the first `venture` record and its canvas / capital / growth records, or the founder creates them by hand. 5. **Operate** — run the venture-creation SOPs human-led, agent-driven, or blended. Gates, scores, and the portfolio command center light up as records accumulate. Because every venture tenant runs the same installed code, the operating model, the SOPs, and the scoring rubrics are identical across the portfolio — only each venture's *data* differs. ## For Agents The Venture Factory reaches agents through the surfaces it installs — there is no Venture-Factory-specific tool to learn: - **SOPs as the operating playbook.** The venture-creation SOPs are SOP entities ([ADR-0055](https://github.com/sprinterhq/amble/blob/main/documents/adr/0055-sop-living-entity-over-action-spine.md)) an agent can run step by step. The `.claude/skills/venture-*` skills (`venture-ideate`, `venture-validate`, `venture-score`, `venture-gate-check`, `venture-scope`, `venture-launch`, `venture-growth-loop`, `venture-sunset`, and `venture-forge` for orchestration) encode each subprocess and are individually invocable. - **Records via the entity tools.** The `venture`, `vf_*` canvas, and capital entity types are DB-driven — an agent reads and writes them with `createEntity` / `createRelation` / `updateEntity`, the same as any other entity type. Stage advances, scoring, and gate checks are entity updates against criteria sets, not bespoke calls. - **Gates as criteria sets.** Go/no-go and Gate 0–6 decisions are criteria sets — an agent scores a venture against the rubric and the gate machinery produces the verdict. - **Dormant actions.** Per-stage autopilot/cron action templates exist on `actions` rows but do not fire until explicitly enabled (and only when `isCronAllowed()` permits) — an agent enabling a loop is enabling existing config, not building a new one. ## Design Decisions **The factory is installable surfaces, not a new engine.** The strongest temptation was a `features/venture-factory/` platform engine. That would be a parallel system competing with the workspace-template, bundle-installer, SOP, and criteria-set primitives the platform already owns. Instead the factory is *config over those primitives* — every layer is an install of existing code. This is the no-parallel-systems rule applied literally. **Three separate add-ons, not one mega-template.** The foundation, Studio Method, and Capital are *separate installable bundles* so a tenant can start blank or batteries-included and opt in per layer. Collapsing them into one install would destroy the optionality the operating model is built to deliver — a venture that wants the portfolio but not the fundraising surface (or vice versa) must be able to choose. **The installer is the clone mechanism.** Rather than a bespoke "create venture" code path, cloning the factory is *installing the stack from the gallery, then re-running one idempotent, tenant-parameterized seed script* for the data. The script seeds SOPs + the optional demo (not workspaces — those install via the gallery / `install_bundle()`), so venture #2..N cost a couple of commands, not a fork. **Slugs are method-namespaced, never tenant-named.** The Capital entity types use the `vf_` prefix (continuing the prior epic's move away from the tenant-specific `vs_*`). A slug named for a single tenant makes the bundle non-reusable — `vf_` keeps the types tenant-agnostic and the installer maps them into whatever tenant it targets. **Praxium dogfoods the product it sells.** The reference tenant is not a synthetic demo — it is a real venture (protocol intelligence for wellness studios) run as venture #1 inside the factory. Dogfooding the operating model end-to-end surfaces gaps a spec never would, and proves the "batteries-included" path and install ordering against a real workload. ## Related Modules - **Workspaces** (`features/workspaces/`, `features/custom/workspaces/`) — the workspace templates the factory installs. See [Workspaces](/docs/features/workspaces), [Workspace Templates](/docs/features/workspace-templates), [Custom Workspaces](/docs/features/custom-workspaces). - **Plugins** (`features/plugins/`) — the unified install surface (ADR-0058) the workspace stack and the add-on gallery install through (the data installer seeds on top of it). See [Plugins](/docs/features/plugins) and [Bundles](/docs/features/bundles). - **SOPs** (`features/custom/`, SOP entities) — the venture-creation playbook as living, runnable documents (ADR-0055). See [SOPs](/docs/features/sops). - **Command Center** — the operating cockpit a venture is run from. See [Command Center](/docs/features/command-center). - **Entity System** (`features/entities/`) — the `venture`, `vf_*` canvas, and Capital entity types whose `json_schema` drives forms / cards / details automatically. See [Entity System](/docs/features/entity-system). - **Multi-tenant** (`features/tenant/`) — the tenant boundary that makes each venture a tenant the installer points at. See [Multi-tenant](/docs/features/multi-tenant).