naive-framework 0.0.0-stage → 0.2.0

package/governance/skills/stakeholder-update/SKILL.md

@@ -0,0 +1,177 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, stakeholder-update]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: stakeholder-update
+description: >
+  Compose a stakeholder update tailored to audience + cadence. Reads project
+  state (recent SESSION_LOG entries, articulation closure status, metrics
+  review outputs, decisions log) and produces an update in the right register
+  for the audience: exec brief / engineering detail / customer-facing / investor
+  update / board materials. Sponsored by Chief of Staff role.
+  MANDATORY TRIGGERS: stakeholder update, status update, weekly update,
+  monthly update, board update, investor update, all-hands update, customer
+  comms, launch announcement, executive brief, engineering update, /stakeholder-update.
+---
+
+# Stakeholder Update Skill
+
+The Chief-of-Staff-sponsored skill for composing updates tailored to specific audiences + cadences.
+
+## Why stakeholder-update exists
+
+Per [[../../venture-template/roles/chief-of-staff|Chief of Staff role]], CoS owns the rhythm of stakeholder communications — all-hands, board updates, investor updates, customer comms. These updates draw from project state but need translation: an engineering team's progress reads differently to engineers vs. the board vs. customers. The skill handles the translation.
+
+## When to invoke
+
+- Weekly / monthly / quarterly status updates to leadership or board
+- Launch announcement composition
+- Customer-facing release notes
+- Investor update emails
+- All-hands deck or script
+- Escalation comms (a risk needs surfacing to specific stakeholders)
+- The user explicitly asks for a stakeholder update or asks "how do I summarize this for X?"
+
+## What stakeholder-update produces
+
+A stakeholder update sized to the audience + cadence. Structure varies by type:
+
+### Executive brief (CEO / exec team / board)
+
+- **Headline** — one sentence: most important development since last update
+- **Status** — green / yellow / red on key initiatives
+- **Highlights** — 3-5 bullets, mostly outcomes (shipped, achieved, decided)
+- **Risks + asks** — what's at risk + what the audience can help with
+- **Numbers** — relevant metrics (from [[../metrics-review/SKILL|metrics-review]] outputs)
+- Length: 1-2 paragraphs + scorecard
+
+### Engineering detail (technical team / CTO)
+
+- **What shipped** — with PR / commit references where useful
+- **What's in flight** — with progress %
+- **What's blocked** — with specific blockers + needed help
+- **Technical decisions** — ADRs from the period
+- Length: bullet-heavy; can be longer
+
+### Customer-facing (release notes / community)
+
+- **What's new** — user-facing capabilities, in customer register (not engineer register)
+- **What's better** — improvements, in customer-relevant framing
+- **What's coming** — light foreshadowing of next version (per [[../foreshadowing-audit/SKILL|foreshadowing-audit]] discipline)
+- Length: short; voice-aligned with brand
+
+### Investor update (monthly/quarterly to investors)
+
+- **Headline** — milestone or shift since last update
+- **KPIs** — revenue, growth, churn, runway
+- **Highlights** — wins + significant developments
+- **Lowlights** — losses + risks (honesty here builds trust)
+- **Asks** — intros, hiring help, customer connections
+- **Runway** — months remaining at current burn
+- Length: 1-2 pages
+
+### All-hands update (internal team-wide)
+
+- **Wins** — celebrate
+- **Progress on goals** — OKRs / strategic plan
+- **What's changing** — org changes, process changes, priority shifts
+- **Q&A or open thread** — invite engagement
+- Length: deck + script, ~15-20 minutes
+
+## How to compose a stakeholder update
+
+When this skill is loaded, the AI should:
+
+### Step 1 — Clarify the audience + cadence
+
+Ask:
+- Who's the audience? (CEO / exec team / engineering team / board / investors / customers / all-hands)
+- What's the cadence? (one-off / weekly / monthly / quarterly)
+- What's the date range covered? (since last update / since launch / this quarter)
+- Are there specific topics to emphasize or de-emphasize?
+
+### Step 2 — Read project state
+
+Pull from:
+- Recent SESSION_LOG entries (the project's institutional memory)
+- Articulation closure inventory (what's done vs in-flight vs deferred)
+- Metrics review outputs (numbers + interpretation)
+- Decision log (significant calls)
+- Idea archive (what was tried + decided against, if relevant)
+- The per-project orchestration HTML (current state overview)
+
+If any input is missing, surface to the operator.
+
+### Step 3 — Translate to the audience register
+
+The single most important step. The same project state reads differently to different audiences:
+
+- **Executives** want outcomes + decisions + risks + asks
+- **Engineering** wants technical specifics + decisions + unblocking help
+- **Customers** want what's new + what's better + brand-aligned voice
+- **Investors** want numbers + trajectory + honest assessment
+- **All-hands** wants progress + celebration + clarity
+
+The skill's job is to take the same underlying state and render it in the right register.
+
+### Step 4 — Draft + iterate
+
+Draft the update; surface to the operator; iterate. Updates often need 2-3 passes to land the tone correctly.
+
+### Step 5 — Track the update
+
+Save to:
+
+```
+projects/<entity>/business/stakeholder-updates/<date>-<audience>.md
+```
+
+Or in a per-audience update log if the project uses one.
+
+Frontmatter:
+
+```yaml
+---
+type: stakeholder-update
+update-audience: exec | engineering | customer | investor | all-hands | board
+cadence: weekly | monthly | quarterly | one-off
+date: <date>
+date-range-start: <date>
+date-range-end: <date>
+author: <name>
+tags: [stakeholder-update, <entity>, <audience>]
+---
+```
+
+### Step 6 — Surface to the orchestration HTML
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|§32]], stakeholder updates show in the Business pillar section of the orchestration HTML with their audience + date.
+
+## Posture
+
+Stakeholder-update runs in a **mode that matches the audience**:
+
+- **Executive / board / investor updates** — office-hours-mode posture. Sharp, evidence-driven, honest about risks.
+- **Customer / all-hands** — friend-mode posture. Generative, energetic, celebratory.
+- **Engineering** — office-hours-mode by default; engineers appreciate directness.
+
+The skill should declare its posture explicitly so the operator can adjust if needed.
+
+## What stakeholder-update is NOT
+
+- **Not a substitute for direct communication.** Updates supplement; they don't replace conversation with stakeholders.
+- **Not spin.** Especially for investor + board updates, honesty about lowlights builds trust. Spin destroys it.
+- **Not a release-notes generator.** Customer-facing release notes are one stakeholder-update flavor; if the operator just wants release notes, do that — but the skill is broader.
+
+## Relationship to other skills
+
+- [[../metrics-review/SKILL|metrics-review]] — feeds the numbers section of most updates
+- [[../articulation-closure/SKILL|articulation-closure]] — feeds the what-shipped section
+- [[../friend-mode/SKILL|friend-mode]] / [[../office-hours-mode/SKILL|office-hours-mode]] — posture per audience
+- [[../canonicalize/SKILL|canonicalize]] — recurring update types (weekly investor, monthly all-hands) have canonical formats
+
+## Status
+
+- **2026-05-14:** Initial authoring.

package/governance/tooling/integrations.json

@@ -0,0 +1,37 @@
+[
+  {
+    "id": "decision-ledger",
+    "name": "Decision ledger",
+    "layer": "governance",
+    "role": "G-NNN and D-NNN decisions",
+    "interfaces": [
+      "files"
+    ],
+    "status": "in-use",
+    "reason": "_meta/registers/decision-ledger.json"
+  },
+  {
+    "id": "github-governance",
+    "name": "GitHub branch protection and CODEOWNERS",
+    "layer": "governance",
+    "role": "who may merge",
+    "interfaces": [
+      "api",
+      "files"
+    ],
+    "status": "candidate",
+    "reason": "Torian merges by hand today"
+  },
+  {
+    "id": "slack",
+    "name": "Slack",
+    "layer": "governance",
+    "role": "approvals and escalations",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Connector available, not signed in"
+  }
+]

package/governance/venture-template/AGENT_ROLES_AND_DECISION_RIGHTS.md

@@ -0,0 +1,58 @@
+---
+type: reference
+source: machine
+created: 2026-10-14
+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 ratified operating-model decisions. Roles are templates; entities instantiate positions ([[position-schema]]).*
+
+## Roles
+
+| Role | Occupant | Model tier | Decides | Research | Reviews | Escalates to |
+|---|---|---|---|---|---|---|
+| **Founder** | person | person | strategy; constitutional changes; money; legal terms; public commitments; production ship (or a named delegate); anything irreversible at company scale | any | escalation classes only | — |
+| **Chief of Staff** | agent | frontier | intake and first-principles restatement; routing to roles; priorities within approved strategy; what to defer and to whom; register upkeep | rediscovery across ledgers and registers; light research to frame an idea | none; it routes | next level's chief-of-staff, then founder |
+| **Domain Lead** | agent | frontier | what the sources say and how reliable they are; domain design within decided strategy; which sources to add to the source register | primary sources, law, official records, academic and industry literature | domain accuracy of others' work on request | ecosystem chief-of-staff |
+| **Architect (architecture and infrastructure)** | agent | frontier | ADRs inside decided strategy; repository, data stores, runtimes, formats; build handoffs and done-criteria; accepting work in classes marked for review; operating procedures (e.g. database branch procedure) | technology evaluation, vendor and library docs, prior art | fit to intent, only for marked decision classes | ecosystem chief-of-staff |
+| **Product and Design Lead** | agent | frontier | experience and interface design within decided product lines; microcopy within brand voice | users, comparable products, design references, accessibility | fit to experience intent for marked classes | ecosystem chief-of-staff |
+| **Builder** | agent | workhorse-coding | how to implement within the handoff; implementation details, refactors within scope; shipping work that passes conformance (the reversible-work rule) | current docs, APIs, library versions, error messages, before and during coding | never its own work | architect |
+| **Business Lead** | agent | frontier | market, pricing and financial research and models within strategy | markets, competitors, financial and regulatory sources | commercial claims in others' work on request | ecosystem chief-of-staff (money and legal go to founder) |
+| **Operations and Finance Lead** | agent | frontier | keeping the spend register current from statements; flagging renewals, duplicates and unused subscriptions; moving existing commitments to the business card or account; budget-versus-actual reports | vendor pricing, plans and terms; banking and expense tools | cost and terms of proposed dependencies | founder for any new expense, plan upgrade, cancellation of an in-use service, or terms |
+
+Checks with objective criteria (tests, goldens, invariants, rebuilds) run as CI and scripts: no model and no reviewer (the conformance rule).
+
+## Decision rights (template)
+
+| Class | Owner | Level | Condition |
+|---|---|---|---|
+| Accept work whose done-criteria pass conformance checks | builder | **decide** |  |
+| Implementation choices inside a handoff | builder | **decide** |  |
+| Schema or data change inside an accepted ADR, via the documented procedure | builder | **decide-inform** |  |
+| Writes to the production database | builder | **decide-inform** | Only through the Architect's documented branch procedure |
+| Narrowing permissions or closing a hole | builder | **decide-inform** |  |
+| Widening permissions, new privileged paths | architect | **recommend-approve** | Marked for Architect review |
+| New service, store, package boundary or format | architect | **decide-inform** | Requires an ADR; a second data store needs its own ADR |
+| Deleting or rewriting records, dropping originals | architect | **recommend-approve** | Founder if it touches legal records or originals |
+| An ADR consistent with ledger decisions | architect | **decide-inform** |  |
+| Anything that would contradict an in-force ledger decision | founder | **escalate** |  |
+| Adopting a free, open-licence dependency | architect | **decide-inform** | Add to the dependency register |
+| Any paid service, plan change or purchase | founder | **escalate** |  |
+| Accepting terms, licences with obligations, legal positions | founder | **escalate** |  |
+| Who owns or controls the venture: admitting or removing a cofounder, issuing, granting or reclassifying shares or units, signing a SAFE, note or priced round, granting investor rights, forming a board or changing its powers, agreeing to sell or wind down. Founder decisions made with counsel (EE-022); agents prepare options and documents only | founder | **escalate** |  |
+| Publishing, announcing, or sending anything outside on the company's behalf. Every publication passes the venture's publication policy: named channel and content, the channel's checks and preview, a person approves (EE-025) | founder | **escalate** |  |
+| Release to production users | founder | **recommend-approve** | Founder or a named delegate |
+| Strategy, product lineup, entity structure, methodology amendments | founder | **escalate** |  |
+| A decision touching two ventures | chief-of-staff | **recommend-approve** | The chief of staff of the workspace (umbrella) position recommends; the founder approves |
+| What a source says; whether a record is official | domain-lead | **decide-inform** |  |
+| Experience and interface design within decided product lines | product-design-lead | **decide-inform** |  |
+| Whether an idea is worked now or deferred, and to which role | chief-of-staff | **decide-inform** |  |
+| Record statements, tag charges by entity, flag anomalies | operations-finance-lead | **decide** |  |
+| Cancel, downgrade or change the plan of a paid service | operations-finance-lead | **recommend-approve** | Founder approves; Architect consulted if the service is in use |
+| Move an existing subscription to the business card or account | operations-finance-lead | **recommend-approve** | Founder performs the change in the vendor account |
+
+Levels: **decide**: Role decides; the work itself is the record; **decide-inform**: Role decides and records it (PR, register entry); founder may read, need not act; **recommend-approve**: Role recommends; the named approver decides (DACI); **escalate**: Founder decides (RAPID for the few with vetoes)

package/governance/venture-template/COMPANY_VAULT_DEFINITION_2026-10-25.md

@@ -0,0 +1,204 @@
+---
+type: architecture-spec
+source: hybrid
+created: 2026-10-25T23:05:00Z
+ai-model: claude-opus-5.5
+authority: architectural
+decision-status: in-force
+status: ACTIVE
+governed-by:
+  - "[[SAD_SKILL_v3_AMENDMENT_2026-10-25_docs-as-code-and-workspace-layout]]"
+  - "[[governance/venture-template/index]]"
+related:
+  - "[[POLITY_VAULT_TARGET_STRUCTURE_2026-10-13]]"
+  - "ADR-0006-repository-structure (tchjhnsn/polity: docs/adr/ADR-0006-repository-structure.md)"
+  - "[[everything-ecosystem/MAD/layers/README]]"
+tags: [venture-template, company-vault, governance, delivery, docs-as-code, workspace]
+description: "What a company's vault is once design and implementation docs move into the repo. Uses MAD's four layers: governance and delivery live in the vault, software engineering and automation in the repo, and company functions MAD doesn't cover stay in the vault. Proposes folders, a sorting test, and how vault and repo link."
+last-revised: 2026-10-26T00:44:21Z
+revision-note: "Re-framed on MAD's four layers (Torian, 2026-10-26); open questions decided as G-023"
+---
+
+# What a company vault is
+
+## Why this is needed
+
+Under G-020, design and implementation documentation moves into the repo. That defines the repo well: **the repo is the product and the account of how it is built.**
+
+It leaves the vault defined only by what is left over, which is the wrong way to define anything. This document defines the vault on its own terms.
+
+## The definition
+
+> **A company vault is how the company governs and runs itself.** It holds what the company has decided and why, what it is delivering and in what order, who is responsible, and how it is known and earns its keep. It is the company's handbook, its book of record and its operating desk. The repo holds what a product is and how it is built.
+
+### The layers are MAD's (revised 2026-10-26)
+
+The first draft invented three layers (governance, delivery and operation, build). Torian meant the four layers MAD already defines in `everything-ecosystem/MAD/layers/`. Using them means the vault and repo split falls out of a model the workspace already maintains, rather than a second one.
+
+| MAD layer | What MAD asks about | Home |
+|---|---|---|
+| **Governance** | Whether it's worth building, who decides, how value is judged (13 questions: evidence, funding, regulation, decision rights, success measure, review point, goal setting, what happens when evidence says the direction is wrong) | **Vault**, `governance/` |
+| **Delivery** | How work is planned, sequenced and handed over (15 questions: requirements stability, how work arrives, fixed commitments, stage gates, which artifact decides the plan) | **Vault**, `delivery/` |
+| **Software engineering** | How each part is specified, built and checked, asked per part (15 questions: kind of part, who depends on its interface, invariants, which artifact defines correct behaviour) | **Repo**, `docs/` beside the part |
+| **Automation** | How it's built, tested, released and run without hand work (12 questions: build, merge, release, infrastructure, observability, reliability) | **Repo**, as config and code (CI, infrastructure), with its docs in `docs/` |
+
+The line between vault and repo is the line between MAD's upper two layers and its lower two. Governance and delivery decide *whether, who, what and when*. Software engineering and automation decide *how*.
+
+Two consequences follow.
+
+**MAD covers software only, and a company is more than its software.** MAD's governance layer asks about one piece of software ("who decides whether *this software* gets built"). A company also has corporate records, people, brand, money and legal duties, which no MAD layer covers yet (MAD requirement 10: software only for now). These stay in the vault as **company functions** beside the two MAD layers, rather than being forced into them. If MAD later grows past software, they are the candidates for a company-level governance layer.
+
+**Where a document lives is itself a MAD answer.** MAD requirement 12 says a project's repo structure and file formats are questions at each layer, answered by the chosen templates. Two practice questions settle which document is canonical:
+- delivery: *which artifact decides what the current plan is when people disagree?*
+- software engineering: *which artifact defines correct behaviour for this part, and wins when artifacts disagree?*
+
+The folder layout follows those answers. A part built spec-as-source keeps its spec in the repo as the winning artifact. A project run waterfall keeps its signed-off plan in the vault's `delivery/` as the winning artifact. The folders below are a default, and a project's MAD answers can override them.
+
+### Where the MAD record lives
+
+MAD stores each project's answers as JSON in `.mad/record.json` (MAD does this for itself). One record covers all four layers for one project. Proposed default: **the record lives in the repo** at `.mad/`, because a repo is cloned alone and its engineering and automation answers have to travel with it. The vault's `governance/` and `delivery/` folders hold the readable decisions and plans, and cite the record's governance and delivery answers by question id. A company with several products has one record per repo, listed in `delivery/portfolio.md`.
+
+Systems of record outside both (the database, GitHub issues and PRs, the bank, the state's corporate filings, signed contracts) are referenced from the vault, never copied into it.
+
+## What the prior art says
+
+**Governance is separate from management.** COBIT and ISO/IEC 38500 split *governance* (evaluate, direct, monitor: the board's job) from *management* (plan, build, run, monitor). The split keeps the people running a thing from also grading it ([Hyperproof on COBIT](https://hyperproof.io/cobit-it-governance/), [Orbus on COBIT principle 5](https://www.orbussoftware.com/resources/blog/post/cobit-5-principle-5-separating-governance-from-management)).
+
+This lines up with MAD: MAD's governance layer is evaluate, direct and monitor; its delivery layer is plan and run; software engineering and automation are build and run.
+
+**A company handbook is a different thing from product docs.** GitLab is the strongest example of documentation done in the open. It keeps two separate bodies:
+- the **handbook**, covering values, governance and the board, each department and how the company works;
+- the **product documentation**, which lives with the product and is its single source of truth for usage.
+
+The handbook links to the product docs rather than restating them ([GitLab handbook](https://handbook.gitlab.com/handbook/about/), [GitLab documentation style guide, mirror](https://gitlab-doc-test.readthedocs.io/zh-cn/latest/development/documentation/styleguide/)). That is the vault/repo split almost exactly.
+
+**A management system has a known shape.** Every ISO management-system standard (9001 quality, 27001 security, 42001 AI) shares one high-level structure. Clauses 4–10 are **context, leadership, planning, support, operation, performance evaluation, improvement** ([ANSI on Annex SL](https://blog.ansi.org/ansi/annex-sl/), [Modulos on ISO 42001 clauses 4–10](https://docs.modulos.ai/frameworks/iso-42001/clauses-4-10.html)). It is a good coverage check: a company vault that has nothing for one of these has a gap.
+
+**Documents have a hierarchy.** Quality systems run *policy → procedure → work instruction → record*. A procedure crosses functions; a work instruction covers one task at one station ([Advisera](https://advisera.com/9001academy/knowledgebase/how-to-structure-quality-management-system-documentation/), [QMS UK](https://www.qmsuk.com/news/iso-9001-processes-procedures-and-work-instructions)). This maps cleanly:
+- **Policies and procedures** are company → vault.
+- **Work instructions** for a system (runbooks, deploy steps) are build → repo.
+- **Records** are vault registers and ledgers, or a pointer to the system of record.
+
+**A company must keep corporate records.** Statutes require permanent minutes of board and shareholder meetings, actions taken without a meeting, the articles and bylaws, and registers of directors and shareholders. The cap table usually sits alongside ([Iowa Code §490.1601](https://www.legis.iowa.gov/DOCS/IACODE/2001/490/1601.html), [Inc Authority on corporate minutes](https://www.incauthority.com/blog/corporate-minutes/)). None of this has a home in the vault today.
+
+**Investors and acquirers expect a fixed set of areas.** Due-diligence rooms converge on: corporate and governance, financials, legal and compliance, intellectual property, team and HR, product and technology, market and strategy, traction and metrics ([Visible](https://visible.vc/blog/data-rooms-faq/), [Drooms](https://drooms.com/es/startup-fundraising-data-room-checklist)). A vault organized this way can produce a data room from what already exists.
+
+**Small-company operating systems name the same parts.** EOS has six components: vision, people, data (scorecard), issues, process, traction (priorities and meeting cadence). The vault already has most of them as registers and positions ([EOS Worldwide](https://www.eosworldwide.com/traction-component)). Treat this source as promotional; it is useful only as a checklist.
+
+## The sorting test (replaces the earlier one)
+
+The test in the v3.0.17 draft ("would it still hold if the code were rewritten?") is wrong for domain design. A domain model of how a court works survives a rewrite, yet G-020 puts domain design in the repo. The better test:
+
+> **Is it about the company, or about a product?**
+> - About **how the company decides, runs, staffs, sells or presents itself** → vault.
+> - About **what a product is, the domain it models, or how it is built and run** → repo.
+
+Edge cases:
+
+| Document | Goes to | Why |
+|---|---|---|
+| Vision of a product | Repo (`docs/vision.md`) | About the product. The company's mission is a vault document; the product vision answers to it |
+| Product roadmap / version plan | Vault, delivery | Sequencing and commitment are company decisions; the repo holds what each version contains |
+| Domain research (sources on how a government works) | Repo | It informs the domain model. Strategy research (market, competitors) stays in the vault |
+| ADR | Repo | Systems decision. Founder decisions (D-numbers) stay in the vault ledger |
+| Runbook, deploy, on-call | Repo | Work instruction for a system |
+| Incident review | Repo for the technical record; vault if it changes policy | |
+| Brand identity and voice | Vault | How the company is known |
+| Design tokens, component library | Repo | Implements the brand |
+| Pricing, contracts, cost model | Vault | Business. A cost model's code (e.g. `stage1_cost_model.py`) is still a business tool and stays with it |
+| Marketing copy | Repo of the site that ships it | It is shipped content. Campaign strategy stays in the vault |
+
+## Proposed folders for a company vault
+
+Folders follow MAD's layers. The two upper layers get one folder each, with subfolders that match the groups of MAD questions they answer. Company functions that MAD doesn't cover sit beside them. Inside each folder, the constitution's "folder means standing" rule still applies.
+
+```
+companies/<company>/
+├── entity-profile.md            the company's constitution (identity, scope, stage)
+│
+│   MAD governance layer: whether it's worth building, who decides, how value is judged
+├── governance/
+│   ├── charter/                 mission, values, philosophy, guiding principles
+│   ├── evidence/                is the problem real, can we reach the people: market, competitors, strategy research
+│   ├── decisions/               decision rights, founder decision ledger (D-NNN), continue/stop reviews
+│   ├── policies/                company policies (data, security, AI use, conduct, publishing), regulatory exposure
+│   └── scorecard/               the success measure and goals for the next stretch (pointers to live data)
+│
+│   MAD delivery layer: how work is planned, sequenced and handed over
+├── delivery/
+│   ├── portfolio.md             every product and harness, its stage, its repo and its .mad record
+│   ├── roadmap/                 version plans and sequencing, by product; fixed outside commitments
+│   ├── work/                    work queue, campaigns, handoffs, stage gates, phase status
+│   └── cadence/                 operating rhythm: reviews, retros, planning cycles
+│
+│   Company functions (outside MAD, which covers software only)
+├── corporate/                   minute book index, bylaws, board and shareholder actions, cap table pointer
+├── organization/                positions, roles, occupancy, hiring, people policies
+├── operations/                  running the company: vendors, accounts, tools, spend, support
+├── brand/                       identity, voice, narrative, asset index
+├── business/                    model, pricing, sales, partnerships, finance, legal and compliance, fundraising
+│
+├── _meta/registers/             risk, dependency, open questions, fragmentation (records)
+├── _ideas/  _archive/  deferred/
+│
+```
+
+The MAD software-engineering and automation layers live in the company's product repos at `~/workspace/code/companies/<company>/<repo>/` (code, `docs/` per part, CI and infrastructure, `.mad/record.json`). Repos never sit inside the vault (G-025).
+
+`strategy/` from the first draft folds into `governance/evidence/`, because the questions it answers (is the problem real, can we reach the people who have it) are MAD governance questions. `corporate/` moves out of `governance/` because MAD's governance layer is about whether software is worth building, not about the legal entity.
+
+**Coverage against ISO's seven clauses:**
+
+| Clause | Folder |
+|---|---|
+| Context | `governance/evidence` |
+| Leadership | `governance/charter`, `governance/policies`, `organization/` |
+| Planning | `delivery/roadmap`, `_meta/registers/` (risk) |
+| Support | `operations/`, `organization/` |
+| Operation | `delivery/work`; the repo for building and running the product |
+| Performance evaluation | `governance/scorecard` |
+| Improvement | `delivery/cadence` (retros), `_archive/` with supersession |
+
+**Against a due-diligence room:**
+
+| Data-room area | Folder |
+|---|---|
+| Corporate | `corporate/` |
+| Financial | `business/finance` |
+| Legal | `business/legal` |
+| IP and product/tech | the repos, plus `governance/policies` |
+| Team | `organization/` |
+| Market | `governance/evidence` |
+| Traction | `governance/scorecard` |
+
+## How the vault and the repo relate
+
+1. **Down by path.** The vault points at the repo through `delivery/portfolio.md` (generated from `_meta/workspace.json`) and through `implemented-in:` on any principle, policy or decision that a repo carries out.
+2. **Up by ID, not by path.** A repo is cloned alone (on GitHub, in a cloud agent, by a contributor), so a relative path into the vault breaks there. Repo documents cite what governs them by stable ID instead: a decision (`D-122`, `G-020`), a principle id, a policy id, or the entity id. A small resolver (the registers plus `workspace.json`) turns the ID into a file. This also makes the governance link survive folder moves.
+3. **Each decision is recorded once.** Company decisions live in the vault ledger. Systems decisions live as ADRs in the repo. An ADR that implements a founder decision names its D-number.
+4. **Work lives where it is done.** Company-level work (campaigns, handoffs, priorities) is in `delivery/work`. Code-level work is GitHub issues and PRs, which the vault links to rather than mirrors.
+5. **Nothing is restated.** A vault document summarizes a repo document only as far as a reader needs to decide whether to follow the link. This is GitLab's SSOT rule and the constitution's pointer rule.
+
+## What changes for Polity (illustration, not a plan)
+
+| Today | Proposed |
+|---|---|
+| `business/org/positions/` | `organization/positions/` |
+| `business/FRAGMENTATION_REGISTER.md` | `_meta/registers/` |
+| `product/planning/` (handoffs, roadmaps, phase status) | `delivery/` |
+| `product/planning/DECISION_LEDGER_2026-08-12.md` | `governance/decisions/` |
+| `product/spec/adrs/` | `polity/docs/adr/` (repo) |
+| `product/research/`: strategy research | `governance/evidence/` |
+| `product/research/`: domain research | repo |
+| `product/spec/`, `design/` | repo `docs/` |
+
+## Decisions (Torian, 2026-10-26, recorded as G-023)
+
+Torian answered the six open questions. Where the answer was "your recommendation", the recommendation is written out here.
+
+1. **Sensitive records stay out of git.** Signed contracts, minutes that carry personal data, HR files and financial statements go in an encrypted store outside git. The vault keeps an index entry for each one (id, date, what it is, where it is stored, a checksum) in `corporate/` or `business/`. Decisions, policies and anything meant to be read and versioned stay in git.
+2. **A hybrid of one repo and one per company.** The vault is one repo for shared material (`_meta/`, `_sessions/`, `_issues/`, `ideas/`, and projects without a repo of their own). Each company vault is its own private repo at `vault/companies/<company>/`, which the vault repo ignores and lists in `_meta/workspace.json`. That lets a company vault be shared with a future co-founder or board without exposing the rest of the vault. *Corrected 2026-10-26 (G-025):* the workspace folder itself is not a repo, the shared repo is the vault, and product repos sit beside the vault in `code/`, never inside it. *Corrected again 2026-10-26 (G-026):* company vaults are not separate repos. `companies/` stays in the vault repo; each company's code repos sit in `code/companies/<company>/`.
+3. **Projects get the same shape, scaled down.** A non-company project has an entity profile and its repo. It adds `governance/` and `delivery/` only when it has something to put in them. Company functions (`corporate/`, `organization/`, `brand/`, `business/`, `operations/`) are left out unless the project needs one.
+4. **Folder names are MAD's layer names.** `governance/` and `delivery/` take MAD's names and follow MAD if it renames a layer. The charter stays at `governance/charter/`.
+5. **The MAD record lives in the repo** at `.mad/record.json`, whole, with all four layers. The vault cites its governance and delivery answers by question id.
+6. **MAD gets a company-level layer soon**, without waiting for MAD to grow beyond software. It covers what the company functions hold (corporate, organization, brand, business, operations), so MAD can recommend how a company organizes its vault. Logged as work item W-013 for the MAD project.

package/governance/venture-template/README.md

@@ -0,0 +1,74 @@
+---
+type: venture-template-readme
+ai-model: claude
+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, methodology, three-pillars, reference, 2026-05-14]
+related:
+  - "[[sad/SAD_SKILL_v3]]"
+  - "[[_ideas/build-roadmap-and-html-orchestration-2026-05-12]]"
+  - "[[sad/pipeline-canonical-view-2026-05-14]]"
+---
+
+# `venture-template/` — what this folder is
+
+The **Company Template** is the reference description of what a company *is*. It is **outside the methodology** but the methodology references it.
+
+The methodology (the four-lane pipeline at `methodology/`) describes *how work moves*. The company template describes *what the work is building toward*. The two compose: the methodology brings the company template to life, version by version.
+
+## The three-layer formalization
+
+Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap idea-dump §33]]:
+
+1. **Layer 1 — The methodology** (`everything-ecosystem/methodology/`). The four-lane pipeline + rituals.
+2. **Layer 2 — The company template** (this folder). What a company is — three pillars + teams + roles + overlap zones.
+3. **Layer 3 — Deliverable templates** (`everything-ecosystem/deliverables/`, to be authored). Per-pillar, per-product-type, plus Tier 3 idea-discovered.
+
+Glue: skills (auto-running) + hooks (lifecycle events) + selective slash commands (often as buttons in the per-project orchestration HTML).
+
+## Folder contents
+
+```
+venture-template/
+├── README.md                   ← This file
+├── index.md                    ← Master reference — what a company is
+├── pillars/
+│   ├── product.md              ← Product pillar reference
+│   ├── brand.md                ← Brand pillar reference
+│   └── business.md             ← Business pillar reference
+└── roles/
+    ├── README.md               ← Index of role files + status
+    ├── ceo.md                  ← Chief Executive — cross-pillar lead
+    ├── (cto.md — Product lead — to-author)
+    ├── (cmo.md — Brand lead — to-author)
+    ├── (coo.md — Business lead — to-author)
+    └── (founder.md, chief-of-staff.md, etc. — to-author)
+```
+
+## How the methodology references this template
+
+- **Articulate lane** populates the template per V[N]. The end of Articulate is "the company template is fully populated for this version" — every Tier 1 + Tier 2 deliverable in [[index]] has at least a draft.
+- **Build lane** translates the populated template into running reality — code (Product), assets shipped (Brand), operational surfaces online (Business).
+- **Ship lane** makes the template's commitments verifiable in production.
+- **Operate lane** maintains and evolves the template, amending the methodology when the template proves insufficient.
+
+## What this template is NOT
+
+- **Not a one-size-fits-all prescription.** Not every project needs every pillar; not every pillar needs every team. The template is reference material, not a compliance checklist.
+- **Not an org chart.** Roles describe *responsibilities*, not headcount. A solo operator may play multiple roles; an established company may split one role across many people.
+- **Not entity-class specific (yet).** The current template assumes a default modern tech company. Variants for other entity-classes (open-source-tool, hobby, content-company, service-company) are queued for authoring as those project shapes accumulate enough reference material to generalize from.
+- **Not the methodology.** The methodology lives at `methodology/`. This template is what the methodology *fills*.
+
+## Status
+
+- **2026-05-14:** Initial scaffold. index + 3 pillars + 1 role (CEO) authored. Other roles + product-type-specific variants queued.
+
+## Where ideas about this template go
+
+Idea-dumps about the company template structure go to `vault/Torian/everything-ecosystem/_ideas/` with frontmatter `scope-entity: [[everything-ecosystem]]` and tag `venture-template`. The dump at [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap]] §33–§34 currently holds the structural thinking that produced this folder.