naive-framework 0.0.0-stage → 0.2.0

package/knowledge/skills/industry-awareness/SKILL.md

@@ -0,0 +1,277 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, industry-awareness]
+ai-model: claude
+created: 2026-05-16
+source: hybrid
+name: industry-awareness
+description: >
+  Map the operator's terminology to industry-standard terminology and surface
+  existing industry solutions BEFORE the operator reinvents the wheel. Catch
+  the pattern where a non-industry-native operator describes a workflow problem
+  in their own terms, designs a custom solution, and only later discovers that
+  the pattern is well-trodden + has mature tooling. Auto-loads whenever the
+  operator describes a workflow, proposes a new internal tool, introduces
+  new terminology for a concept, discusses managing complexity, or asks
+  "what's the industry term for" / "is there software that does this" /
+  "how do enterprises handle this." Web-search-enabled; industry tooling
+  changes rapidly. Posture: friend when surfacing options + alternatives;
+  office-hours when challenging "should we build this?" assumptions.
+  MANDATORY TRIGGERS: industry term, industry standard, what's this called,
+  what software, what tool, existing solution, prior art, are we reinventing,
+  is there a tool for, what do they call this, best practice, common pattern,
+  standard workflow, enterprises use, how do companies handle, jira, linear,
+  notion, figma, github, asana, productboard, confluence.
+---
+
+# Industry Awareness Skill
+
+The methodology mechanism that prevents the operator from reinventing solved problems due to lack of industry exposure. Authored 2026-05-15 after a multi-session pattern surfaced: The owner (a non-industry-native operator) repeatedly described workflow problems in their own terms + designed custom solutions, only to discover later that industry-standard terminology + tooling already solved them.
+
+## Why this skill exists
+
+Non-industry-native operators have a real, structural blind spot: they don't know what they don't know. They describe problems using their own framing (often sharper than industry's), then design solutions from first principles. Sometimes the result is genuine innovation. Often, the result is a custom version of something that's been a $1B+ industry for a decade.
+
+Examples from past sessions:
+
+- **The operator console mockup ≈ Linear.** The operator designed a "project-level view" with topbar / sidebar / pillar cards / agent panel / activity feed / decisions log. Linear has shipped this exact shape since 2019. 30%+ of tech teams already migrated to it. The harness was structurally a hand-rolled, less-functional Linear.
+
+- **"Sprint" terminology mismatch.** The operator used "sprint" to mean "named work unit." Industry uses "sprint" to mean "time-boxed delivery cycle (1–2 weeks)." That usage was closer to **epic** or **initiative**. This caused the "sprint plan" doc to feel muddled — it was actually an *epic plan*.
+
+- **V1 enumeration → backlog.** The 250-row enumeration is structurally an issue backlog. Linear, Jira, ClickUp, Notion, and many others have managed backlogs for ~15 years.
+
+- **Status semantics on enumeration rows ≈ workflow states.** OPEN → TRIAGED → IN-SPRINT → DONE is the canonical issue workflow. Industry tools manage this natively + automatically.
+
+- **"Orchestration HTML" ≈ project dashboards.** Project dashboards have existed since the 1990s; modern variants (Linear views, Notion databases, Asana boards) handle this as their primary feature.
+
+In every case, the operator's framing was thoughtful + the methodology contribution was real. But the *delivery vehicle* could have been an off-the-shelf tool, freeing the operator's attention for what actually was novel (the methodology, the brand discipline, the version-identities work).
+
+The pattern: **operator's framing matters; industry tools handle the rest.** This skill enforces that distinction.
+
+## When to invoke
+
+This skill should auto-load when:
+
+- The operator describes a workflow pattern using their own terminology
+- The operator proposes to build a custom tool / dashboard / system
+- The operator introduces new terminology for a concept (especially methodology terminology)
+- The operator discusses managing complexity, scaling teams, or hiring
+- The operator references discrete domains (project management, design, content, accounting, etc.) without naming the industry tools
+- The user explicitly asks "what's the industry term for ___" or "is there software that does ___" or "how do enterprises handle ___"
+
+It should NOT load when:
+
+- The operator is in vision-expansion mode (0A / 0C) — let novel framing emerge first; check it against industry later
+- The operator's framing is genuinely novel (e.g., the V1/V2/V3 consumption-interaction-communication framing — that's specific to this operator; industry doesn't have a parallel)
+- The operator has explicitly decided to build custom for documented reasons (not lack-of-knowledge reasons)
+
+## The terminology mapping workflow
+
+When the operator uses non-standard terminology, the skill produces a mapping:
+
+```
+| Operator's term | Industry-standard term | Notes |
+|---|---|---|
+| Sprint (loosely)  | Epic / Initiative      | Sprint is reserved for time-boxed cycles |
+| Pillars           | Product/Brand/Business as functional areas | Common framing |
+| Enumeration       | Backlog                | Backlog is the industry term |
+| Pillar products   | Product portfolio      | "Portfolio" is the industry term for multi-product |
+| Articulation      | Specification / Discovery / Definition | Multiple industry terms |
+| Articulation closure | Definition of Ready / Pre-development gate | Loosely equivalent |
+| FE↔BE communication layer / “backend first with FE contracts” | API-first / contract-first / design-first | Assets: OpenAPI, AsyncAPI, fixtures; see contract-first skill |
+| Three pillars     | Functional areas / Business functions | Industry agnostic |
+```
+
+The mapping isn't a demand to switch. It's information so the operator can:
+- Communicate with industry-native collaborators
+- Search for tools / patterns / prior art using the right terms
+- Choose deliberately when to keep custom terms vs adopt industry ones
+
+Some custom terms are worth keeping. The version-identities discipline (consumption / interaction / communication) is more precise than industry's "phased rollout" framing. Foreshadowing as a brand invariant is sharper than "brand consistency." These are net-additions to the operator's vocabulary; they should stay.
+
+## The stack-recommendation workflow (per §44 amendment)
+
+A fourth use case, added 2026-05-16. Invoked proactively rather than reactively. The agent environment or operator can invoke this to ask:
+
+> **Given pillar X with current state Y and missing capability Z, recommend the industry tool(s) that fill the gap.**
+
+Example invocations:
+
+- Brand pillar needs visual asset management → recommend Figma + asset library
+- Business pillar needs financial tracking → recommend QuickBooks / Xero / Stripe Billing
+- Product pillar needs error tracking → recommend Sentry / Datadog / Bugsnag
+- Methodology layer needs decision-doc storage → recommend Notion / Obsidian / GitBook
+
+**Output:** same shape as the prior-art surface (3–5 dominant tools with audience fit + pricing + AI integration + reviewer assessments) but proactively triggered rather than reactively.
+
+**MCP-availability noted.** When recommending tools, include each tool's MCP-availability status — operators should prefer MCP-enabled tools where they fit equally well, since the harness can connect to them directly.
+
+## The prior-art check workflow
+
+When the operator proposes building something, the skill runs a prior-art check:
+
+1. **Restate the problem in industry terms** (from the terminology mapping).
+2. **Web-search for industry solutions** with the restated terms.
+3. **Identify the 3–5 dominant tools / patterns** that solve this problem.
+4. **For each, surface:**
+   - What they do
+   - Their primary audience
+   - Their pricing model
+   - Their AI integration status (matters in 2026)
+   - Recent reviewer assessments (last 12 months)
+5. **Present the build-vs-adopt frame** (next section).
+
+The skill is web-search-enabled because industry tooling moves fast. Recommendations made in 2024 are often stale by 2026.
+
+## The build-vs-adopt decision framework
+
+The skill doesn't always recommend adopt. Sometimes building custom is right. The frame:
+
+**Strong reasons to ADOPT (off-the-shelf):**
+- The pattern is mature (5+ years in market)
+- Multiple competing solutions exist (mature category)
+- The operator's customization needs are minor + the tools accommodate them
+- The operator's time is better spent on what's actually novel
+- The tool's AI integration is already mature
+- Team scaling is likely (off-the-shelf tools are team-ready)
+
+**Strong reasons to BUILD (custom):**
+- The methodology / approach is the actual product (not just internal use)
+- Existing tools structurally cannot represent the methodology
+- The operator is the customer + has unusual workflow constraints
+- The pattern is genuinely novel (no prior art exists)
+- The build is small enough to be cheap
+
+**Hybrid (most common):**
+- Adopt off-the-shelf for the operational layer (PM, ticketing, dashboards)
+- Build custom for the methodology-specific layer (the record conventions, the venture template, the brand discipline)
+- Connect them via integrations (MCPs, APIs, exports)
+
+In one past case: Linear handles the operational layer; Obsidian handles the methodology + knowledge layer; the operator console (eventually) handles the methodology-specific orchestration if Linear genuinely doesn't fit.
+
+## Output formats
+
+Three deliverables this skill produces, depending on what's needed:
+
+### Format 1 — Terminology bridge
+
+A side-by-side table mapping operator terms to industry terms (see "terminology mapping workflow" above).
+
+### Format 2 — Prior-art surface
+
+A walk through the 3–5 dominant industry tools / patterns for the operator's problem, with:
+- One-paragraph descriptions
+- Audience fit notes
+- Pricing summary
+- Recent reviewer assessments (cited)
+- A recommendation (or "deliberately don't adopt; build because X")
+
+### Format 3 — Build-vs-adopt analysis
+
+For a specific proposed build, an explicit cost-benefit:
+- What you'd be replicating (the existing tool's features)
+- What you'd lose by adopting (genuine customization needs)
+- What you'd gain by building (long-term methodology fit)
+- Cost estimates (operator's time + opportunity cost)
+- Recommendation with rationale
+
+## Posture
+
+This skill switches posture based on what's happening:
+
+- **Friend mode** when surfacing options — the operator is exploring; the skill helps broaden their view + introduce industry context they didn't know existed
+- **Office-hours mode** when challenging "should we build this?" assumptions — the skill presses the operator on whether the proposed build is genuinely novel or is restating a solved problem
+
+Default posture: friend (most queries are exploratory). Switch to office-hours when the operator is about to invest substantial time in a custom build that has a clear off-the-shelf alternative.
+
+## Proactivity calibration (per §45 amendment)
+
+The skill defaults to **LOW proactivity**. The operator's philosophy: struggle with something first to understand the pain point before being handed a solution. Premature solution-handing prevents deep understanding.
+
+**Default behavior — DO NOT proactively:**
+
+- Surface alternatives unless operator has clearly hit a pain point
+- Recommend tools for problems the operator hasn't yet articulated
+- Map operator's terms to industry equivalents on first mention
+- Push the operator toward off-the-shelf when they're still exploring
+
+**HIGH proactivity triggers (when the skill SHOULD surface things):**
+
+- Operator explicitly invokes the skill ("what's the industry term for X?" / "is there a tool for Y?" / "how do enterprises handle Z?")
+- Operator describes a clear pain point ("this is slow" / "this is expensive" / "this is breaking")
+- Operator is about to invest substantial time in a custom build with obvious alternatives — surface, framed as "here's prior art for your awareness; your call"
+- System-detected pain point (cost / time / quality threshold crossing — even if operator hasn't articulated)
+
+**Two intensities of surfacing:**
+
+- **"Alternative exists"** — lower-stakes; OK to mention briefly even at default proactivity ("by the way, this is sometimes called X in industry"). Drop in, move on.
+- **"Recommend a specific tool / decision"** — higher-stakes; only when operator is asking or has clearly hit pain.
+
+**Knowledge-base awareness:** track what the operator has demonstrated familiarity with. Don't repeat surface-level recommendations for things they clearly already know.
+
+## Cost-aware integration hierarchy (per §45 amendment)
+
+When recommending how to integrate with a tool/service, prefer in cost order:
+
+| Mode | Token cost | Latency | When preferred |
+|---|---|---|---|
+| Local file read | ~zero | near-zero | State we own |
+| **CLI** | low | fast | **Default when service has a mature CLI** |
+| MCP | medium-high | slower | When AI-typed interaction is core to the workflow (bulk creation from natural language, agent workflows) |
+| API direct | medium | medium | When no CLI / MCP, typed interaction needed |
+| Scraping / manual | high | slowest | Last resort |
+
+**Correction to earlier guidance:** prior versions of this skill said "MCP-first integration posture." That's wrong. The correct posture is **CLI-first where the service has a usable CLI; MCP only where AI-typed interaction is the core workflow.**
+
+When recommending tools, surface CLI availability alongside MCP availability. Operators who can use CLI should generally prefer it for daily operations.
+
+## What this skill is NOT
+
+- **Not a "always adopt industry" skill.** Sometimes building custom is right (the methodology itself; the brand voice; the version-identities discipline). The skill respects when the operator's framing is genuinely novel.
+- **Not a tool advertisement.** The skill surfaces tools with honest assessment, including limitations + costs, not marketing copy.
+- **Not a substitute for the operator's judgment.** The final decision is the operator's. The skill provides context.
+- **Not focused on a single industry.** Software / PM / design / content / accounting / hiring / sales — every domain has industry-standard tooling. The skill applies broadly.
+
+## How this skill prevents the operator-console pattern
+
+The operator console (then called the harness) was a 4-hour mockup that demonstrated "what work is being done across multiple projects." If this skill had loaded when the harness was being designed, it would have:
+
+1. **Mapped the terminology:** "project view," "agent panel," "decisions log," "roadmap" → these are all standard PM tool features.
+2. **Run prior-art check:** Linear, Jira, ClickUp, Asana, Notion, Productboard — all surface this exact shape.
+3. **Surfaced specific tools:** Linear's project view ≈ what was being mocked up.
+4. **Produced the build-vs-adopt frame:** "Build = 4-hour mockup + months to feature parity. Adopt = sign-up + import in an afternoon. Methodology fit: 80% Linear, 20% needs custom."
+5. **Recommended hybrid:** "Use Linear for operational layer; defer the operator console; revisit if Linear genuinely doesn't fit after real use."
+
+The operator console mockup is still useful — as design substrate, as the eventual "what we'd build if we ever need to differentiate from Linear." But it wasn't urgent and shouldn't have consumed primary attention until the alternative was understood.
+
+## Related skills
+
+- [[friend-mode]] / [[office-hours-mode]] — posture skills this one switches between
+- [[deliverable-discovery]] — finds missing deliverables in templates; different from finding industry solutions for existing workflows
+- [[template-generation]] — generates new templates; this skill checks whether the template is needed at all
+- [[cross-pillar-tradeoff]] — when an industry tool choice has cross-pillar implications (Product wants Linear; Business wants Jira; resolve via tradeoff)
+
+## When to web-search
+
+Web search is core to this skill. Always search when:
+
+- The operator names a specific tool ("Jira") — search recent (last 12 months) reviews + comparisons
+- The operator describes a category ("project management software") — search current market leaders
+- The operator asks about a workflow pattern — search if industry has a name for it
+- The operator is about to invest in building — verify "is this already built somewhere?"
+
+Search query patterns:
+
+- `<concept> industry term`
+- `<concept> standard tooling 2026`
+- `<tool A> vs <tool B> <use case>`
+- `best <category> software solo founder 2026`
+- `enterprise <concept> workflow`
+
+## Status
+
+- **2026-05-15:** Initial authoring. Surfaced from a session where the owner explicitly recognized the harness ≈ Linear pattern + asked for a methodology mechanism to catch this.
+
+## Methodology placement
+
+This skill is queued for ratification as part of v3.4 (or a v3.3.x point release). Captured in [[build-roadmap-and-html-orchestration-2026-05-12]] §40.

package/knowledge/templates/glossary.md

@@ -0,0 +1,23 @@
+---
+type: template
+tags: [everything-ecosystem, knowledge, glossary, template]
+ai-model: claude-opus-5.5
+created: 2026-10-29T06:04:07Z
+source: hybrid
+---
+
+# Template: package glossary
+
+Fills `<venture>/glossary/<package>.json` (`schema/glossary.schema.json`). A package's terms stay local to it: an agent working in another package sees only the terms marked `export`. See what a package sees with `mentura glossary/terms run --value <package>`.
+
+```json
+{
+  "package": "finance",
+  "terms": [
+    { "term": "burn multiple", "meaning": "net burn divided by net new ARR" },
+    { "term": "runway", "meaning": "months of cash at the current burn", "export": true }
+  ]
+}
+```
+
+Two packages may not export one term with different meanings. A package's own term wins over another's exported one.

package/knowledge/tooling/integrations.json

@@ -0,0 +1,127 @@
+[
+  {
+    "id": "filesystem",
+    "name": "File system and git",
+    "layer": "knowledge",
+    "role": "the default source: a venture's own folder, or any folder or git repository on the machine",
+    "interfaces": [
+      "files",
+      "cli"
+    ],
+    "status": "in-use",
+    "reason": "Every venture starts with its records in its own folder (EE-037)",
+    "connector": {
+      "module": "knowledge/connectors/filesystem.mjs",
+      "writes": [
+        "direct",
+        "none"
+      ],
+      "options": [
+        "root"
+      ],
+      "eval": "node knowledge/connectors/eval.mjs"
+    }
+  },
+  {
+    "id": "obsidian",
+    "name": "Obsidian",
+    "layer": "knowledge",
+    "role": "the personal and company vaults; a vault is a folder, so the filesystem connector reaches it",
+    "interfaces": [
+      "files",
+      "app"
+    ],
+    "status": "in-use",
+    "reason": "Every vault is an Obsidian vault"
+  },
+  {
+    "id": "github",
+    "name": "GitHub",
+    "layer": "knowledge",
+    "role": "records and docs as code in a repository: read from a branch, written by draft pull request",
+    "interfaces": [
+      "files",
+      "mcp",
+      "api",
+      "cli"
+    ],
+    "status": "in-use",
+    "reason": "Docs as code (EE-005); the second connector (EE-037)",
+    "credentials": [
+      "GITHUB_TOKEN"
+    ],
+    "connector": {
+      "module": "platform/connectors/github.mjs",
+      "writes": [
+        "pull-request",
+        "none"
+      ],
+      "options": [
+        "repo",
+        "ref",
+        "root",
+        "token",
+        "api",
+        "search"
+      ],
+      "eval": "node platform/connectors/eval.mjs (live: MENTURA_EVAL_GITHUB_REPO=owner/name)"
+    }
+  },
+  {
+    "id": "notion",
+    "name": "Notion",
+    "layer": "knowledge",
+    "role": "team-facing knowledge base",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Connector exists"
+  },
+  {
+    "id": "claude-docs",
+    "name": "Claude Docs",
+    "layer": "knowledge",
+    "role": "collaborative documents with comments",
+    "interfaces": [
+      "mcp"
+    ],
+    "status": "in-use"
+  },
+  {
+    "id": "google-drive",
+    "name": "Google Drive",
+    "layer": "knowledge",
+    "role": "documents shared with outside parties",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate"
+  },
+  {
+    "id": "claude-artifacts",
+    "name": "Claude artifacts",
+    "layer": "knowledge",
+    "role": "published pages and dashboards over the records",
+    "interfaces": [
+      "app"
+    ],
+    "status": "in-use"
+  },
+  {
+    "id": "jev",
+    "name": "Jev (TypeSafe AI)",
+    "layer": "knowledge",
+    "role": "routes a venture to the connectors that fit its use cases: given what the venture keeps and where, it ranks the registry's connectors and integrations, and `mentura connect` asks it first",
+    "interfaces": [
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): Mentura uses Jev to route users to the proper or best connectors",
+    "credentials": [
+      "TYPESAFE_API_KEY"
+    ]
+  }
+]

package/knowledge/tooling/questions.md

@@ -0,0 +1,46 @@
+---
+type: reference
+source: hybrid
+created: 2026-10-26T21:57:48Z
+ai-model: claude-opus-5.5
+tags: [everything-ecosystem, knowledge, tooling, tool-selection]
+description: "What to ask when someone wants help choosing knowledge-layer tools: the dimensions, example questions, and how common tools answer them. Used by operations/skills/tool-selection."
+---
+
+# Knowledge layer: choosing tools
+
+Opt-in. Use this only when someone asks for help choosing (see `operations/skills/tool-selection/SKILL.md`). The questions below are examples of each kind, not a script.
+
+## Dimensions that matter
+
+| Dimension | Why it matters | Example question | Type |
+|---|---|---|---|
+| Who writes | Solo, a team, outside parties and agents need different tools | Who will write and edit this: just you, your team, people outside the company, agents? | choice (several) |
+| Where it lives | Local files you own versus a hosted service | Does any of it have to stay on your own machine? | yes/no (often a must-have) |
+| Agent access | Agents read and write through files, MCP or an API | How much should agents write here, rather than only read? | score: none / read / draft / write freely |
+| Shape | Linked notes, structured databases, long documents, specs next to code | Is most of it linked notes, tables of records, or documents that ship with code? | choice |
+| Working together | Live co-editing and comments versus review by pull request | When two people change the same page, do they need to do it at the same time? | yes/no |
+| Sensitivity | Legal, health or customer records may not belong in a hosted tool | Will this hold anything you couldn't put in a third-party cloud? | yes/no (must-have) |
+| Cost and scale | Per-seat pricing grows with the team | How many people will need access in a year? | score: 1 / 2–10 / 10–50 / 50+ |
+| Exit | Plain files leave cleanly; some formats don't | If you stopped using it, how bad would a lossy export be? | score: fine / annoying / serious |
+| What exists | Switching cost is real | What do you use today, and what would it take to move it? | free text, turned into a switching-cost score |
+
+## How common tools answer them
+
+Presets are general descriptions and should be checked against current product terms before a hard-to-reverse choice.
+
+| Tool | Who writes | Where it lives | Agent access | Shape | Live co-editing | Exit |
+|---|---|---|---|---|---|---|
+| Obsidian | Mostly one person; teams through a shared sync | Local Markdown files (optional paid sync) | Files, so any agent with folder access | Linked notes | No | Clean: plain Markdown |
+| GitHub (docs as code) | Anyone who can use pull requests; agents easily | Hosted git, cloned locally | Files, CLI, API, MCP | Docs that ship with code | No; review by pull request | Clean: plain files with history |
+| Notion | Teams and outside guests | Hosted | API and MCP | Databases and pages | Yes, with comments | Partial: Markdown/CSV export loses some structure |
+| Claude Docs | People and Claude together | Hosted on claude.ai | MCP | Documents with comments | Yes | Export to Markdown, Word, PDF |
+| Google Drive | Outside parties, non-technical readers | Hosted | API and MCP | Documents and sheets | Yes | Good: Office formats |
+
+## Worked example: Torian, 2026-10-26
+
+Situation as recorded: one founder plus agents, specs belong with code (docs as code, G-020), principles and philosophy kept in a personal vault, some collaboration with Claude on drafts, nothing that must be off-cloud at this stage.
+
+- Must-haves: agents must write freely; docs that govern code must live in the repo. Notion and Google Drive pass but are not needed for either.
+- Fit: GitHub for specs and design docs, Obsidian for vaults, Claude Docs for drafts written with Claude. All three are low lock-in except Claude Docs, which is used only for drafts and exports cleanly.
+- Result: matches `integrations.json` today. Notion stays a candidate for when a team or outside readers need a shared knowledge base.

package/operations/FOUNDER_OPERATING_MODEL_CAMPAIGN_2026-10-14.md

@@ -0,0 +1,16 @@
+---
+type: knowledge
+publish: false
+source: hybrid
+created: "2026-10-14"
+updated: "2026-10-18"
+ai-model: grok-bot
+status: STUB
+tags: [operating-model, stub]
+---
+
+# Operating model campaign (stub)
+
+The full design of the operating model for the agent team (roles, decision rights, handoff contract, escalation classes and decision ledger) is kept privately.
+
+The operational rules a skill needs are in the skills and templates that cite this note: the handoff contract is in `templates/handoff-v2.md`, and roles and decision rights are in `venture-template/AGENT_ROLES_AND_DECISION_RIGHTS.md`.

package/operations/departments.json

@@ -0,0 +1,162 @@
+{
+  "version": "0.1.0",
+  "note": "The departments a venture can import (EE-047). Each is one top-level category of APQC's cross-industry Process Classification Framework (version 7.x names), tagged with its place in Porter's value chain. A venture lists the ones it uses in venture.json `departments` and gets a folder for each only then (EE-048); each department's governance side (charter, policies, decision rights) sits under governance/departments/ and its operations side (work, assets, tools) under operations/departments/. The priors say how likely a venture needs the department in each phase, in need-now's format (EE-028); version 0.x, ours and unevaluated.",
+  "departments": [
+    {
+      "id": "strategy",
+      "label": "Strategy",
+      "apqc": { "id": "1.0", "name": "Develop Vision and Strategy" },
+      "value_chain": "support",
+      "porter": "firm infrastructure",
+      "governance": "Strategic decisions and the link to the telos",
+      "operations": "Planning cadence, market research",
+      "base": { "discovery": 0.2, "validation": 0.3, "beachhead": 0.5, "scale": 0.8, "platform": 0.9 },
+      "when": [{ "if": "people>=3", "at_least": 0.6 }],
+      "why": "Until a team plans together, the purpose layer holds the venture's strategy"
+    },
+    {
+      "id": "products",
+      "label": "Products and services",
+      "apqc": { "id": "2.0", "name": "Develop and Manage Products and Services" },
+      "value_chain": "primary",
+      "porter": "technology development",
+      "governance": "Product decision rights",
+      "operations": "Specs, roadmaps and the work of building (MAD, for software)",
+      "base": { "discovery": 0.6, "validation": 0.9, "beachhead": 1, "scale": 1, "platform": 1 },
+      "when": [{ "if": "products>=1", "at_least": 0.9 }],
+      "why": "The venture's offering; Porter files product development under technology development, a support activity, but for a venture whose product is its work it is primary"
+    },
+    {
+      "id": "marketing-and-sales",
+      "label": "Marketing and sales",
+      "apqc": { "id": "3.0", "name": "Market and Sell Products and Services" },
+      "value_chain": "primary",
+      "porter": "marketing and sales",
+      "governance": "Brand guidelines and the publication policy",
+      "operations": "The marketing website (EE-044), campaigns, marketing assets, the sales pipeline",
+      "base": { "discovery": 0.3, "validation": 0.7, "beachhead": 0.9, "scale": 1, "platform": 1 },
+      "when": [],
+      "why": "Validation needs an audience; the marketing website and outreach start here"
+    },
+    {
+      "id": "supply-chain",
+      "label": "Supply chain",
+      "apqc": { "id": "4.0", "name": "Manage Supply Chain for Physical Products" },
+      "value_chain": "primary",
+      "porter": "inbound logistics, operations and outbound logistics",
+      "governance": "Supplier approval",
+      "operations": "Sourcing, production, inventory and shipping",
+      "base": { "discovery": 0, "validation": 0.1, "beachhead": 0.2, "scale": 0.3, "platform": 0.3 },
+      "when": [],
+      "why": "Only for physical goods; the builder adds it when the venture makes or ships them"
+    },
+    {
+      "id": "service-delivery",
+      "label": "Service delivery",
+      "apqc": { "id": "5.0", "name": "Deliver Services" },
+      "value_chain": "primary",
+      "porter": "operations",
+      "governance": "Service standards",
+      "operations": "Delivery runbooks and engagements",
+      "base": { "discovery": 0, "validation": 0.2, "beachhead": 0.4, "scale": 0.5, "platform": 0.5 },
+      "when": [{ "if": "offering:service", "at_least": 0.7 }],
+      "why": "For ventures that sell a service"
+    },
+    {
+      "id": "customer-service",
+      "label": "Customer service",
+      "apqc": { "id": "6.0", "name": "Manage Customer Service" },
+      "value_chain": "primary",
+      "porter": "service",
+      "governance": "Support policies and refunds authority",
+      "operations": "Support channels, help content, customer feedback",
+      "base": { "discovery": 0, "validation": 0.2, "beachhead": 0.6, "scale": 0.9, "platform": 0.9 },
+      "when": [],
+      "why": "Once paying customers exist"
+    },
+    {
+      "id": "human-capital",
+      "label": "Human capital (HR)",
+      "apqc": { "id": "7.0", "name": "Develop and Manage Human Capital" },
+      "value_chain": "support",
+      "porter": "human resource management",
+      "governance": "HR policies, the handbook, hiring decision rights",
+      "operations": "Recruiting, onboarding, payroll runs",
+      "base": { "discovery": 0, "validation": 0, "beachhead": 0.2, "scale": 0.7, "platform": 0.9 },
+      "when": [{ "if": "people>=2", "at_least": 0.7 }],
+      "why": "With the first hire; agents alone are covered by the team plan"
+    },
+    {
+      "id": "it",
+      "label": "Information technology",
+      "apqc": { "id": "8.0", "name": "Manage Information Technology (IT)" },
+      "value_chain": "support",
+      "porter": "technology development",
+      "governance": "Tool approval (scored by Jev, EE-042)",
+      "operations": "Accounts, integrations, devices and access",
+      "base": { "discovery": 0, "validation": 0.1, "beachhead": 0.2, "scale": 0.5, "platform": 0.7 },
+      "when": [{ "if": "people>=5", "at_least": 0.6 }],
+      "why": "A solo founder's tools live in the integrations list; IT becomes its own department with a team"
+    },
+    {
+      "id": "finance",
+      "label": "Finance and accounting",
+      "apqc": { "id": "9.0", "name": "Manage Financial Resources" },
+      "value_chain": "support",
+      "porter": "firm infrastructure",
+      "governance": "Spending authority, controls and audit",
+      "operations": "Books, invoices, budgets and tax",
+      "base": { "discovery": 0.2, "validation": 0.5, "beachhead": 0.8, "scale": 1, "platform": 1 },
+      "when": [{ "if": "legal_form", "at_least": 0.7 }, { "if": "funding", "at_least": 0.8 }],
+      "why": "Once money comes in or goes out, or the venture has a legal entity"
+    },
+    {
+      "id": "assets",
+      "label": "Assets and facilities",
+      "apqc": { "id": "10.0", "name": "Acquire, Construct, and Manage Assets" },
+      "value_chain": "support",
+      "porter": "procurement",
+      "governance": "Purchase approval",
+      "operations": "Equipment, property and leases",
+      "base": { "discovery": 0, "validation": 0, "beachhead": 0.1, "scale": 0.3, "platform": 0.4 },
+      "when": [],
+      "why": "Only with physical assets or premises"
+    },
+    {
+      "id": "risk-and-compliance",
+      "label": "Legal, risk and compliance",
+      "apqc": { "id": "11.0", "name": "Manage Enterprise Risk, Compliance, Remediation, and Resiliency" },
+      "value_chain": "support",
+      "porter": "firm infrastructure",
+      "governance": "Policies, the risk register, contract approval",
+      "operations": "Filings, contract work, privacy requests",
+      "base": { "discovery": 0, "validation": 0.1, "beachhead": 0.3, "scale": 0.6, "platform": 0.8 },
+      "when": [{ "if": "legal_form", "at_least": 0.5 }],
+      "why": "With a legal entity, customer data or contracts"
+    },
+    {
+      "id": "external-relationships",
+      "label": "External relationships",
+      "apqc": { "id": "12.0", "name": "Manage External Relationships" },
+      "value_chain": "support",
+      "porter": "firm infrastructure",
+      "governance": "Who may speak for the venture",
+      "operations": "Investor relations, partners, press and government affairs",
+      "base": { "discovery": 0, "validation": 0.1, "beachhead": 0.3, "scale": 0.6, "platform": 0.8 },
+      "when": [{ "if": "funding", "at_least": 0.6 }],
+      "why": "Investors, partners or press"
+    },
+    {
+      "id": "capabilities",
+      "label": "Business capabilities",
+      "apqc": { "id": "13.0", "name": "Develop and Manage Business Capabilities" },
+      "value_chain": "support",
+      "porter": "firm infrastructure",
+      "governance": "Process ownership",
+      "operations": "Process improvement, knowledge management, quality",
+      "base": { "discovery": 0, "validation": 0, "beachhead": 0.1, "scale": 0.4, "platform": 0.7 },
+      "when": [],
+      "why": "When processes are repeated by enough people to be worth improving"
+    }
+  ]
+}