naive-framework 0.0.0-stage → 0.2.0

package/governance/venture-template/pillars/business.md

@@ -0,0 +1,255 @@
+---
+type: venture-template-pillar
+ai-model: claude
+pillar: business
+source: hybrid
+created: 2026-05-14
+last-reviewed: 2026-05-14
+authorship: hybrid
+authors: [the author, Claude]
+ip-sensitivity: normal
+scope: global
+scope-entity: "[[everything-ecosystem]]"
+tags: [venture-template, pillar, business, methodology, 2026-05-14]
+canonical-for: "business-pillar-reference"
+related:
+  - "[[governance/venture-template/index]]"
+  - "[[governance/venture-template/pillars/product]]"
+  - "[[governance/venture-template/pillars/brand]]"
+---
+
+# Business pillar
+
+> **Purpose:** *How the company sustains itself.* The commercial + operational surface — money, people, contracts, partnerships, day-to-day machinery of being a going concern.
+
+---
+
+## Business pillar products (optional)
+
+Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §35]], the Business pillar **may** have products of its own — commercial or operational offerings that are themselves "products" rather than supporting artifacts for the Product pillar.
+
+Common Business-pillar products:
+
+- **Partnership programs** — formal partner offerings with tier structures, partner benefits, joint go-to-market
+- **Training programs + certifications** — for users, developers, partners; sold or freely offered
+- **Sales kits / partner enablement bundles** — productized as deliverables to partners
+- **Services + service tiers** — when service is sold by Business as a standalone offering, distinct from a Product-pillar service product
+- **Enterprise consulting / professional services** — accompanies the main product but is itself a productized offering
+- **Investor relations products** — annual reports, board package as a recurring product
+- **Affiliate / referral programs** — productized growth mechanisms
+- **Marketplace operations** — when the company runs a marketplace as a Business-pillar product (e.g., the marketplace UX is Product, but the operational marketplace product — listings, ranking, dispute resolution, take-rate management — is Business)
+
+Business-pillar products carry their own articulation closure inventory, roadmap, and life-cycle through the four lanes. Their product-type (partnership / program / service / etc.) determines which Tier 2 deliverable templates apply.
+
+Most early-stage companies do NOT have Business-pillar products. They have Business-pillar deliverables (business model, pricing, ops runbooks) that *support* the Product-pillar product. Business-pillar products emerge when the company has growing commercial reach and the operational offerings themselves become significant enough to manage as products.
+
+**Business-pillar products are themselves recursive.** Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|§36]], a Business-pillar product (say, a partnership program) has its own three-pillar structure: its own Product (the program offering), its own Brand (often distinct from parent — "the reference project for Educators" has its own positioning), and its own Business (revenue model, partner ops, legal structure, possibly its own P&L). The methodology applies fractally — a partnership program is its own sub-company with the same three-pillar treatment.
+
+---
+
+## What the Business pillar owns
+
+The Business pillar owns everything that isn't the product (Product) or the identity (Brand) but is necessary for the company to function as a going concern. This is the broadest pillar in scope and the one that varies most by company stage.
+
+Concretely, Business owns:
+
+- **Commercial.** Business model, pricing, revenue strategy, sales motion, partnerships, BD, contracts.
+- **People.** Hiring, onboarding, performance management, compensation, culture, all-hands.
+- **Operations.** Internal tooling, vendor management, procurement, office/remote ops.
+- **Finance.** Bookkeeping, fundraising, runway management, financial reporting.
+- **Legal.** Contracts, IP, ToS, privacy, regulatory compliance, employment law.
+- **Customer Success.** Onboarding, support, retention, expansion (overlap with Product).
+- **Trust & Safety.** Policy, enforcement, escalation (overlap with Product + Brand).
+- **Strategy & Planning.** Annual planning, OKRs, board materials, investor relations.
+
+Business **does not** own:
+- The product itself — that's Product. Business may shape the product through commercial constraints (pricing, target market) but doesn't author specs.
+- Identity — that's Brand. Business uses brand assets but doesn't define them.
+
+---
+
+## Typical teams
+
+- **Operations.** General ops, internal tooling, vendor management. Often where the most cross-pillar coordination happens.
+- **Finance.** Accounting, FP&A, fundraising support. Small team but high-leverage.
+- **Sales.** Inbound, outbound, account management. Sits under Business when commercial; sometimes under Brand when growth-led / marketing-led.
+- **Business Development.** Partnerships, channel deals, ecosystem relationships. Distinct from Sales — BD signs partners, Sales signs customers.
+- **People** (sometimes called HR / People Ops). Hiring, performance, comp, culture.
+- **Legal.** General counsel, contract review, IP, regulatory. Often outside counsel + small in-house team early; in-house team grows with scale.
+- **Customer Success** (overlap with Product). Owns post-sale customer relationship. CS feedback loops back to Product; CS commercial expansion sits squarely under Business.
+- **Trust & Safety** (overlap with Brand + Product). Policy lives under Business; community standards under Brand; tooling under Product. Coordination across all three required.
+
+---
+
+## Typical roles
+
+**Pillar lead:**
+- *To author:* [[../roles/coo|COO]] — Chief Operating Officer. Pillar lead for Business in most modern companies. (Some companies split Business into multiple C-level roles; COO most often owns the broadest scope.)
+
+**Cross-cutting C-level:**
+- **CFO** — Chief Financial Officer. Owns Finance; reports to CEO; sits under Business but has independent board reporting.
+- **General Counsel** — heads Legal; reports to CEO; often considered C-level in companies with legal complexity.
+- **CRO** — Chief Revenue Officer. Owns Sales + sometimes BD. C-level in revenue-driven companies.
+- **CPO** — Chief People Officer. Owns People; C-level in companies that have scaled past ~150 people.
+
+**VP-level + management roles:**
+- VP Sales — runs Sales day-to-day; reports to CRO (or CEO if no CRO)
+- VP Operations — runs Ops
+- VP BD — runs Business Development
+- Head of People — runs People (pre-CPO scale)
+- Head of Customer Success — runs CS
+- VP Legal — runs Legal (under GC or directly to CEO)
+
+**Specialist IC + lead roles:**
+- Customer Success Lead — runs a CS pod or customer segment
+- Sales Engineer — technical sales support
+- BD Manager — owns specific partner relationships
+- Recruiter — sources + closes candidates
+- Accountant / Controller — owns books + reporting
+- Office Manager / Operations Coordinator — handles day-to-day ops
+
+---
+
+## Tier 1 deliverables — every Business pillar produces these
+
+1. **Business profile** (`<entity>/business/profile.md`) — sub-profile describing what Business is for this entity.
+2. **Business idea-dumps** (`<entity>/business/_ideas/`) — raw business thinking, commercial hypotheses, partnership ideas.
+3. **Market thesis** — who the customer is, what the market looks like, why this entity should exist commercially.
+4. **Business model** — how the entity makes money (or, for non-commercial entities, how it sustains itself).
+5. **Pricing** — explicit pricing strategy + tiers. (Even free / pre-revenue entities should declare "currently free + the path to monetization.")
+6. **Sales collateral** — pitch decks, one-pagers, battle cards (overlap with Brand).
+7. **Partnership memos** — for each major partner, a memo describing the relationship + terms.
+8. **Operational runbooks** — for each recurring ops task (deploy, incident, on-call, etc.), a runbook.
+9. **Metrics framework** — what metrics the company tracks, definitions, dashboards (overlap with Product on Analytics).
+10. **Marketing collateral** — landing pages, email sequences, ads (overlap with Brand on voice).
+11. **Anti-scraping / ToS clauses** — legal posture for product data + IP (overlap with Product on enforcement).
+12. **App store listings** (for app-distribution products) — store metadata, copy, screenshots, preview videos (overlap with Brand).
+13. **Pitch deck** — investor / partner pitch (overlap with Brand on narrative).
+14. **Investor materials** — board decks, update emails, financial reports.
+15. **Contracts** — customer agreements, vendor agreements, NDAs, employment agreements.
+16. **Hiring rubric** — what we hire for, by role + by level (overlap with company-wide).
+
+---
+
+## Tier 2 deliverables — per-company-stage
+
+Business pillar varies most by company stage. The typical splits:
+
+### Pre-revenue / pre-product
+
+- Business hypothesis (lightweight model)
+- One-pager describing the entity
+- Founder bios / why-this-team narrative
+- Initial market scan
+- Pre-product fundraising deck (if applicable)
+- Defer most operational deliverables until product is in users' hands
+
+### Early-stage (post-launch, pre-PMF)
+
+- Refined business model (post-first-customer-conversations)
+- Pricing v1 + first-customer pricing
+- Light ops runbooks (deploy, incident)
+- Initial metrics framework (vanity metrics tolerated; deep cohorts not yet)
+- Fundraising materials (seed → Series A)
+- First sales collateral (often founder-led sales)
+
+### Growth-stage (post-PMF, scaling)
+
+- Full ops runbooks (incident, on-call, escalation, vendor management)
+- Full metrics framework (cohort analysis, retention, unit economics, growth accounting)
+- Sales playbooks (per segment + per stage)
+- People processes (hiring, onboarding, performance management, comp)
+- Partnership program (formal partner tier structure)
+- Legal compliance program (privacy, security, regulatory)
+- Investor reporting cadence
+- Customer success program
+
+### Mature-stage
+
+- All of the above + board governance, strategic planning cycle, M&A capability, IPO readiness (if applicable)
+
+---
+
+## Tier 2 deliverables — per-business-model
+
+Different business models have different Tier 2 deliverables.
+
+### Subscription (SaaS, content subscription, membership)
+
+- Pricing tiers + feature gating matrix
+- Churn analysis + retention dashboards
+- Upgrade/downgrade flows (overlap with Product)
+- Annual contract vs. monthly mix model
+
+### Transactional (e-commerce, marketplace)
+
+- Transaction fee structure
+- Take-rate analysis
+- Buyer + seller acquisition costs
+- Refund + dispute policies
+
+### Advertising-supported
+
+- Ad inventory pricing
+- Audience segmentation
+- Advertiser relationships
+- Privacy + data policy (heavy overlap with Legal)
+
+### Open-source + commercial
+
+- OSS license decision
+- Commercial license / SaaS offering structure
+- Community → customer conversion model
+- Contributor agreements
+
+### Free / non-commercial
+
+- Sustainability model (grants, donations, sponsorships, founder-funded, etc.)
+- Sustainability cadence + runway
+- Optional "what would make this commercial" deferred plan
+
+---
+
+## Tier 3 deliverables — idea-derived
+
+Examples from the reference project:
+
+- "Privacy positioning" — captured in marketing/privacy-positioning.md
+- "App store preview briefs" — Tier 2-ish for app-distribution products, but the specific brief format was Tier 3 for the reference project
+- "Concentric-rings allowlist governance" — V1 search policy, lives at the Product × Business overlap
+- "Anti-scraping plan" — V1 IP protection posture, lives at the Product × Business overlap
+
+---
+
+## Cross-pillar overlap zones (Business side)
+
+How Business participates in overlap zones with Product and Brand:
+
+- **Business × Product → Analytics + Instrumentation.** Product owns instrumentation; Business owns metric definitions + dashboards.
+- **Business × Product → Customer Success.** Product owns in-product onboarding + feedback; Business owns support runbooks + CS ops.
+- **Business × Product → Pricing-as-Product.** Business owns pricing strategy + tiers; Product owns paywall implementation + plan-gate UX.
+- **Business × Brand → Sales Collateral.** Brand owns voice + identity; Business owns commercial framing + sales playbooks.
+- **Business × Brand → Partnership Materials.** Brand owns assets + voice; Business owns terms + relationship management.
+- **Business × Brand → PR Strategy.** Brand owns narrative; Business owns analyst + investor + press relationships.
+- **Business × Product + Brand → Trust & Safety.** Business owns policy + legal posture; Product owns moderation tooling; Brand owns community standards.
+
+---
+
+## Methodology mechanisms that touch Business
+
+- **Skills:** `business-pillar` (auto-loads on Business work), `metrics-review` (overlap with Product on analytics), `articulation-closure` (Business-pillar deliverable matrix's gating), `deliverable-discovery`.
+- **Hooks:** `pre-deploy` (gates on Business deliverables that are deploy-blocking — e.g., ToS, privacy policy, app-store listing readiness).
+- **Selective slash commands:** `/metrics-review`, `/stakeholder-update` (composes a stakeholder update from project state).
+
+---
+
+## Related per-role files
+
+- *To author:* [[../roles/coo|COO]] — Business pillar lead
+- *To author:* CFO, GC, CRO, CPO as methodology mechanisms need them
+
+---
+
+## Status
+
+- **2026-05-14:** Initial authoring. Tier 1 surfaced; Tier 2 split by stage + business-model; Tier 3 illustrated from the reference project. COO role file queued.

package/governance/venture-template/pillars/product.md

@@ -0,0 +1,254 @@
+---
+type: venture-template-pillar
+ai-model: claude
+pillar: product
+source: hybrid
+created: 2026-05-14
+last-reviewed: 2026-05-14
+authorship: hybrid
+authors: [the author, Claude]
+ip-sensitivity: normal
+scope: global
+scope-entity: "[[everything-ecosystem]]"
+tags: [venture-template, pillar, product, methodology, 2026-05-14]
+canonical-for: "product-pillar-reference"
+related:
+  - "[[governance/venture-template/index]]"
+  - "[[governance/venture-template/pillars/brand]]"
+  - "[[governance/venture-template/pillars/business]]"
+  - "[[sad/SAD_SKILL_v3]]"
+---
+
+# Product pillar
+
+> **Purpose:** *What the company makes.* The product itself + everything required to specify it, build it, ship it, and operate it.
+
+---
+
+## Product pillar products
+
+Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §35]], each pillar can have products. Product pillar holds the **canonical company products** — the thing(s) the audience uses, reads, plays with, learns from, or builds with.
+
+A company may have one Product-pillar product (the simple case) or many (e.g., the reference project's seven surfaces: The reference project, the reference project News, the reference project SDK, the reference project Forum, etc.). Each Product-pillar product carries its own:
+
+- Spec stack (vision → version → product → data model → impl → behavioral → verification)
+- Audience definition + success metrics
+- Roadmap
+- Articulation closure inventory
+- Build → ship → operate lane traversal
+
+Multi-product Product pillars share some company-wide deliverables (the entity's overarching mission, the cross-product strategic plan) but most product-specific deliverables are per-product.
+
+**Product-pillar products are themselves recursive.** Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|§36]], each Product-pillar product is itself a company-in-miniature with its own three-pillar structure: its own Product sub-pillar (the product itself + any sub-products), its own Brand sub-pillar (the product's identity within or distinct from parent), and its own Business sub-pillar (the product's commercial / operational concerns specific to its scope). The reference project's seven surfaces are the canonical example — each surface is itself a sub-company. The methodology applies fractally; articulation closure, version-identity, deliverable templates all work the same way at every recursion level.
+
+---
+
+## What the Product pillar owns
+
+The Product pillar owns the **product spec stack** and everything downstream of it that's specific to the product as a thing-the-audience-uses. This is the pillar where SAD v3 lives — the methodology is Product-pillar-focused, software-product-type-focused at its current state of development.
+
+Concretely, Product owns:
+
+- The product's vision, version scoping, and full spec stack
+- The product's data model, architecture, and implementation
+- The product's user experience, information architecture, and accessibility
+- The product's verification — does it do what we said it would?
+- The codebase (or content library, or service offering — whatever the product type implies)
+- The deploy/distribute workflow that gets the product to the audience
+- The product's internal observability + performance instrumentation (often co-owned with Business via the Analytics overlap zone)
+
+Product **does not** own:
+- Brand identity (visual + verbal) — that's Brand. Product *imports* brand into its UI + microcopy.
+- Marketing copy or commercial positioning — that's Business or Brand depending on the artifact.
+- Pricing — that's Business (with Product input via the Pricing-as-Product overlap zone).
+
+---
+
+## Typical teams
+
+Teams under Product (primary pillar). Overlap teams are noted explicitly.
+
+- **Engineering.** Backend, frontend, infrastructure, mobile. The team that writes code.
+- **Design** (overlap with Brand). Product design (UX, IA, interaction). Sits under Product when the work is "how the product behaves"; sits under Brand when the work is "how the company visually shows up." Most companies need both kinds of design and the boundary is a frequent source of friction. The methodology convention: product designers sit under Product; brand designers sit under Brand; the design system itself is a Product × Brand overlap.
+- **Product Management.** PMs, group PMs, technical PMs. Owns the product-spec authoring + version scoping work.
+- **QA / Quality.** Test engineering, automation, manual QA. Owns the verification → ship gate.
+- **Data Engineering.** Pipelines, warehousing, data platform. Sits under Product when the data is the product (analytics product, dataset product) or when data infra is product-critical.
+- **DevRel** (overlap with Brand + Business). Developer relations sits cross-pillar: code samples + SDK docs are Product; developer-facing voice + content is Brand; developer partnerships + community programs are Business.
+- **Security** (overlap with Business). Product security (vuln management, threat modeling) is Product; corporate security + compliance + legal posture is Business.
+
+---
+
+## Typical roles
+
+Roles under Product. Per-role files exist for those that get methodology mechanisms; others are listed here for reference.
+
+**Pillar lead:**
+- [[../roles/cto|CTO]] — Chief Technology Officer. Sets Product pillar's technical direction.
+
+**Senior IC + management roles:**
+- VP Engineering — runs the engineering organization day-to-day
+- Engineering Manager (EM) — manages a team of engineers
+- Tech Lead — sets technical direction within a team
+- Staff / Principal / Distinguished Engineer — senior IC roles
+- Senior Engineer — experienced IC
+- Software Engineer — IC
+
+**Specialist IC roles:**
+- Designer — product designer (UX + interaction)
+- UX Researcher — user research, usability testing
+- Data Engineer — pipelines, warehousing
+- ML Engineer — machine learning systems
+- Security Engineer — application + infrastructure security
+- DevRel Engineer — developer relations
+- Site Reliability Engineer (SRE) — infra reliability + observability
+
+**Product Management:**
+- VP Product — runs the product organization
+- Group PM — manages a group of PMs
+- Product Manager (PM) — owns one or more product areas
+- Technical PM — PM for technical / API / infra products
+
+---
+
+## Tier 1 deliverables — every Product pillar produces these
+
+Universal Product-pillar deliverables, regardless of product type:
+
+1. **Product profile** (`<entity>/product/profile.md`) — sub-profile under the entity profile; describes what the Product pillar is for this entity.
+2. **Idea-dumps** (`<entity>/product/_ideas/`) — raw idea capture, per the two-layer data model.
+3. **Research synthesis** (`<entity>/product/RESEARCH_SYNTHESIS.md`) — compiled from `_sources/`; produced in Phase 0B.
+4. **Idea map** (`<entity>/product/IDEA_MAP.md`) — compiled from `_ideas/`; produced in Phase 0A.
+5. **Vision spec** (`<entity>/product/spec/VISION_SPEC.md`) — permanent unconstrained vision; produced in Phase 0C.
+6. **Version spec** (`<entity>/product/spec/VERSION_SPEC_v[N].md`) — subtractive cut of vision for version N; produced in Phase 1A.
+7. **Product spec** (`<entity>/product/spec/PRODUCT_SPEC.md`) — intent, scope, user taxonomy; produced in Phase 1B.
+8. **Roadmap** (`<entity>/product/roadmap-*.html` or `.md`) — engineering + content + brand + ops deliverables, ordered for build.
+9. **Audience definition** — who this version is for; what they want; what they don't.
+10. **Success metrics framework** — what "working" looks like, measured (overlap with Business).
+11. **Session log** (`<entity>/product/SESSION_LOG.md`) — institutional memory across all phases.
+12. **Code pointer** (`<entity>/product/code/pointer.md`) — frontmatter pointing to the repo at `<repos>/<repo>/`.
+
+---
+
+## Tier 2 deliverables — per-product-type
+
+Additional deliverables depending on what kind of product. The methodology assumes "default = software product" because SAD v3 was authored for software; other product types have their own deliverable shapes and are queued for variant authoring.
+
+### Software product
+
+The most fully-developed product-type. Tier 2 deliverables:
+
+- Data model spec (`DATA_MODEL_SPEC.md`)
+- Implementation spec (`IMPL_SPEC.md`)
+- Behavioral spec (`BEHAVIORAL_SPEC.md`)
+- Verification spec (`VERIFICATION_SPEC.md`)
+- Phase 1B-Final cross-spec review (`PHASE_1B_FINAL_REVIEW.md`)
+- Sitemap + URL structure
+- Information architecture doc
+- UX flows (per F-flow in PRODUCT_SPEC)
+- Microcopy + states (empty / loading / error)
+- Accessibility checklist
+- Responsive breakpoints
+- Wireframes (per page)
+- Component library catalogue
+- Articulation closure inventory
+- Deploy workflow (CI/CD config)
+- Operational runbooks
+- Tests (unit / integration / E2E)
+- Verification test plan (§9-style)
+
+#### Software sub-types (further specialization)
+
+- **Web app** — sitemap is primary; SEO, analytics, OG/share assets matter.
+- **Mobile app** — store-listing copy + screenshots primary; platform-specific UX patterns.
+- **API / SDK** — auth model + reference docs primary; backwards-compat policy.
+- **CLI tool** — install/uninstall + help text primary; package manager strategy.
+- **Library** — semantic versioning policy; example apps; contributor docs.
+- **Platform** (multi-tenant) — governance + isolation model; tenancy boundary docs.
+
+### Content product
+
+Additional deliverables when the product is content (newsletter, podcast, book, course, documentary):
+
+- Editorial calendar
+- Content production workflow
+- Distribution strategy (channels, cadence)
+- Audience growth plan
+- Editorial guidelines (separate from brand voice — content-specific)
+- Episode / issue / chapter template
+
+### Service product
+
+Additional deliverables when the product is a service (consulting, agency, coaching):
+
+- Service catalog
+- Engagement model (proposal → SOW → delivery → handoff)
+- Delivery playbooks per service offering
+- Pricing tiers (overlap with Business)
+- Case study template
+
+### Hardware product
+
+Additional deliverables when the product is hardware (consumer device, industrial):
+
+- Bill of materials (BOM)
+- Manufacturing plan
+- Supplier qualification
+- Certification roadmap (FCC, CE, UL, etc.)
+- Field service / warranty model
+- Unboxing + setup experience design
+
+### Hybrid
+
+Real products are often hybrid (software + content; software + service; hardware + software companion app). Hybrid products produce the union of relevant Tier 2 deliverables.
+
+---
+
+## Tier 3 deliverables — idea-derived
+
+Discovered per-project; not in any standard template. Surfaced by the deliverable-discovery skill (per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap idea-dump §33–§34]]).
+
+Examples from the reference project:
+
+- Concentric-rings source classification
+- Foreshadowing audit (V[N] foreshadows V[N+1] audience)
+- Version-identities document (one-persona-per-version discipline)
+- Anti-scraping plan (Twitter-posture for civic data)
+- District-map SVG strategy
+- Portrait standards
+
+Tier 3 deliverables originate from conversation; they get added to the deliverable templates inventory as they accumulate across projects and start to feel reusable.
+
+---
+
+## Cross-pillar overlap zones (Product side)
+
+How Product participates in overlap zones with Brand and Business:
+
+- **Product × Brand → Design System.** Product owns interaction patterns + component behavior; Brand owns visual tokens + voice; the design system is the shared artifact.
+- **Product × Brand → Developer Experience.** Product owns SDK + API docs; Brand owns the developer-facing voice + dev portal aesthetic.
+- **Product × Business → Analytics.** Product owns instrumentation + event taxonomy; Business owns metric definitions + dashboards.
+- **Product × Business → Customer Success.** Product owns onboarding flows + in-product feedback; Business owns support runbooks + customer success ops.
+- **Product × Business → Pricing-as-Product.** Product owns paywalls + plan-gate UX; Business owns pricing tiers + commercial strategy.
+- **Product × Brand + Business → Trust & Safety.** Product owns moderation tooling; Brand owns community standards; Business owns legal posture.
+
+---
+
+## Methodology mechanisms that touch Product
+
+- **Skills:** `product-pillar` (auto-loads on Product work), `software-product` / `content-product` / `service-product` / `hardware-product` (per-type guidance), `articulation-closure` (the Product-pillar deliverable matrix's gating), `build-roadmap`, `version-identity`.
+- **Hooks:** `pre-deploy` (gates on articulation-closure verification), `post-tool-use` (timestamp on compiled-artifact edits), `session-start` (read SESSION_LOG before any code work).
+- **Selective slash commands:** `/articulation-close` (runs the closure gate), `/discover-deliverables` (gap discovery for Tier 3 candidates), `/spec` (begins spec stack authoring).
+
+---
+
+## Related per-role files
+
+- [[../roles/ceo|CEO]] — cross-pillar lead who sets Product direction
+- *To author:* [[../roles/cto|CTO]] — Product pillar lead
+- *To author:* VP Engineering, Designer, PM, QA roles as methodology mechanisms need them as context
+
+---
+
+## Status
+
+- **2026-05-14:** Initial authoring. Software product type developed; other product types listed but Tier 2 deliverables not yet detailed exhaustively. CTO role file queued.

package/governance/venture-template/render-roles.py

@@ -0,0 +1,11 @@
+# Regenerates AGENT_ROLES_AND_DECISION_RIGHTS.md from roles/agent-roles.json and decision-rights.json.
+import json,os
+os.chdir(os.path.dirname(os.path.abspath(__file__)))
+cat=json.load(open('roles/agent-roles.json')); dr=json.load(open('decision-rights.json'))
+md=["---","type: reference","source: machine","created: "+cat["updated"],"ai-model: claude-opus-5.5","generated-from: roles/agent-roles.json, decision-rights.json","tags: [venture-template, roles, agents, decision-rights]","---","","# Agent roles and decision rights","","*Generated by `render-roles.py`. Decided in "+cat["governed_by"]+". Roles are templates; entities instantiate positions ([[position-schema]]).*","","## Roles","","| Role | Occupant | Model tier | Decides | Research | Reviews | Escalates to |","|---|---|---|---|---|---|---|"]
+for r in cat["roles"]: md.append("| **%s** | %s | %s | %s | %s | %s | %s |"%(r['name'],r['occupant'],r['tier'],'; '.join(r['decides']),r['research'],r['reviews'],r['escalates_to'] or '—'))
+md+=["",cat["conformance"],"","## Decision rights (template)","","| Class | Owner | Level | Condition |","|---|---|---|---|"]
+for c in dr["classes"]: md.append("| %s | %s | **%s** | %s |"%(c['description'],c['owner'],c['level'],c.get('condition','')))
+md+=["","Levels: "+"; ".join("**%s**: %s"%(k,v) for k,v in dr["levels"].items())]
+open('AGENT_ROLES_AND_DECISION_RIGHTS.md','w').write("\n".join(md)+"\n")
+print(len(cat["roles"]),"roles;",len(dr["classes"]),"classes")

package/governance/venture-template/roles/README.md

@@ -0,0 +1,85 @@
+---
+type: venture-template-roles-readme
+ai-model: claude-opus-5
+source: hybrid
+created: 2026-05-14
+last-reviewed: 2026-08-10
+updated: 2026-08-10
+authorship: hybrid
+authors: [the author, Claude]
+ip-sensitivity: normal
+scope: global
+scope-entity: "[[everything-ecosystem]]"
+tags: [venture-template, roles, methodology, position-schema]
+related:
+  - "[[position-schema]]"
+---
+
+# `roles/` — role **templates** (not the org chart)
+
+Per-role files describe what a seat *is in general* — responsibilities, non-responsibilities, pillar home. They are **role templates**.
+
+**Position instances** (filled or vacant seats *in a specific company*, with occupancy human/agent/vacant/hybrid and team/project assignments) live on the entity under `business/org/positions/` (or brand/product `org/`). Canonical system: [[position-schema]]. Template: `_meta/templates/tpl-position.md`.
+
+```
+venture-template/roles/<slug>.md   →  what the role is
+<entity>/business/org/positions/   →  the seat here + who/what fills it
+```
+
+The roles folder is **selective, not exhaustive**. Most ICs and many specialist roles don't have a file here — they live in the pillar files at `pillars/` or as one-off position instances. A role gets its own template file when:
+
+1. Methodology mechanisms invoke it as context (e.g., `/ceo-review` reads `ceo.md` to know what to evaluate).
+2. The role is common across most companies regardless of stage / industry.
+3. The role has distinct enough deliverables + collaboration patterns to warrant its own page (rather than being one section in a pillar file).
+4. **Staffing posture matters** (e.g. forward-deployed engineer as a `human-required` archetype).
+
+## Status of role files
+
+| Role | Status | Pillar | File |
+|---|---|---|---|
+| CEO | Authored 2026-05-14 | Company-wide | [[ceo]] |
+| CTO | Authored 2026-05-14 | Product (lead) | [[cto]] |
+| CMO | Authored 2026-05-14 | Brand (lead) | [[cmo]] |
+| COO | Authored 2026-05-14 | Business (lead) | [[coo]] |
+| Founder | Authored 2026-05-14 | Company-wide | [[founder]] |
+| Chief of Staff | Authored 2026-05-14 | Company-wide | [[chief-of-staff]] |
+| HR Manager | Stub 2026-08-10 | Business | [[hr-manager]] |
+| Talent Acquisition Manager | Stub 2026-08-10 | Business | [[talent-acquisition-manager]] |
+| Department Head (pattern) | Stub 2026-08-10 | Pattern | [[department-head]] |
+| Forward-Deployed Engineer | Stub 2026-08-10 | Product | [[forward-deployed-engineer]] |
+| CFO | Future | Business | `cfo.md` |
+| General Counsel | Future | Business | `general-counsel.md` |
+| CRO / VP Sales | Future | Business | `cro.md` |
+| CPO (People) | Future | Business | `cpo.md` |
+| VP Engineering | Future | Product | `vp-engineering.md` |
+| Designer (Product) | Future | Product (× Brand) | `designer-product.md` |
+| Designer (Brand) | Future | Brand (× Product) | `designer-brand.md` |
+| Product Manager | Future | Product | `pm.md` |
+| Engineering Manager | Future | Product | `em.md` |
+| Customer Success Lead | Future | Business (× Product) | `cs-lead.md` |
+
+**Authoring wave:** 6 exec roles authored 2026-05-14. Functional stubs (HR, TA, FDE, department-head pattern) added 2026-08-10 with [[position-schema]]. Next priority remains CFO + General Counsel when Business scope expands beyond COO.
+
+## Per-role file structure
+
+Every per-role file follows the same shape:
+
+1. **Purpose** — one paragraph on what the role is for
+2. **Primary pillar + secondary pillars** — where the role sits
+3. **Typical responsibilities** — what the role owns
+4. **Typical deliverables** — artifacts the role produces or sponsors
+5. **Reporting + collaboration patterns** — who the role reports to + who reports to it
+6. **Stage variations** — how the role changes from early-stage to mature
+7. **Methodology mechanisms** — skills, hooks, or commands that invoke this role
+8. **Status**
+
+Stubs may omit later sections until expanded.
+
+## How this folder relates to the pillars
+
+Pillar files (`pillars/*.md`) list typical roles by pillar with one-line descriptions. Per-role files expand those into substantive descriptions. The two cross-link:
+
+- Pillar file lists "CTO — Product pillar lead" with a link to `roles/cto.md`.
+- Per-role file links back to `pillars/product.md` for the pillar context.
+
+When pillar work needs role-specific guidance (e.g., articulation closure for the Product pillar needs to know what the CTO should review), the methodology mechanism reads both the pillar file and the role file.