naive-framework 0.0.0-stage → 0.2.0

package/governance/venture-template/decision-rights.json

@@ -0,0 +1,186 @@
+{
+  "register": "decision-rights",
+  "updated": "2026-10-28",
+  "governed_by": "ratified operating-model decisions",
+  "template": true,
+  "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)"
+  },
+  "note": "Template for every entity. An entity may tighten a class (move it up a level) in <entity>/_meta/registers/decision-rights.json; loosening needs a founder decision.",
+  "classes": [
+    {
+      "id": "accept-verified-work",
+      "description": "Accept work whose done-criteria pass conformance checks",
+      "owner": "builder",
+      "level": "decide"
+    },
+    {
+      "id": "implementation-detail",
+      "description": "Implementation choices inside a handoff",
+      "owner": "builder",
+      "level": "decide"
+    },
+    {
+      "id": "schema-change-within-adr",
+      "description": "Schema or data change inside an accepted ADR, via the documented procedure",
+      "owner": "builder",
+      "level": "decide-inform"
+    },
+    {
+      "id": "production-data-write",
+      "description": "Writes to the production database",
+      "owner": "builder",
+      "level": "decide-inform",
+      "condition": "Only through the Architect's documented branch procedure"
+    },
+    {
+      "id": "security-tightening",
+      "description": "Narrowing permissions or closing a hole",
+      "owner": "builder",
+      "level": "decide-inform"
+    },
+    {
+      "id": "security-loosening",
+      "description": "Widening permissions, new privileged paths",
+      "owner": "architect",
+      "level": "recommend-approve",
+      "condition": "Marked for Architect review"
+    },
+    {
+      "id": "new-structure",
+      "description": "New service, store, package boundary or format",
+      "owner": "architect",
+      "level": "decide-inform",
+      "condition": "Requires an ADR; a second data store needs its own ADR"
+    },
+    {
+      "id": "irreversible-data-change",
+      "description": "Deleting or rewriting records, dropping originals",
+      "owner": "architect",
+      "level": "recommend-approve",
+      "condition": "Founder if it touches legal records or originals"
+    },
+    {
+      "id": "new-adr-within-strategy",
+      "description": "An ADR consistent with ledger decisions",
+      "owner": "architect",
+      "level": "decide-inform"
+    },
+    {
+      "id": "contradicts-ledger",
+      "description": "Anything that would contradict an in-force ledger decision",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "new-dependency-free",
+      "description": "Adopting a free, open-licence dependency",
+      "owner": "architect",
+      "level": "decide-inform",
+      "condition": "Add to the dependency register"
+    },
+    {
+      "id": "spend-money",
+      "description": "Any paid service, plan change or purchase",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "legal-or-terms",
+      "description": "Accepting terms, licences with obligations, legal positions",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "ownership-or-control",
+      "description": "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",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "public-commitment",
+      "description": "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)",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "production-ship",
+      "description": "Release to production users",
+      "owner": "founder",
+      "level": "recommend-approve",
+      "condition": "Founder or a named delegate"
+    },
+    {
+      "id": "strategy-or-constitution",
+      "description": "Strategy, product lineup, entity structure, methodology amendments",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "cross-entity",
+      "description": "A decision touching two ventures",
+      "owner": "chief-of-staff",
+      "level": "recommend-approve",
+      "condition": "The chief of staff of the workspace (umbrella) position recommends; the founder approves"
+    },
+    {
+      "id": "domain-fact",
+      "description": "What a source says; whether a record is official",
+      "owner": "domain-lead",
+      "level": "decide-inform"
+    },
+    {
+      "id": "experience-design",
+      "description": "Experience and interface design within decided product lines",
+      "owner": "product-design-lead",
+      "level": "decide-inform"
+    },
+    {
+      "id": "continue-or-stop",
+      "description": "Whether to start building a product, keep building it or stop, read against the telos exit criteria and the validation evidence (EE-040)",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "change-direction",
+      "description": "Changing the product, customer or business model when evidence shows the current direction is wrong; the telos steering says how (EE-040)",
+      "owner": "founder",
+      "level": "escalate"
+    },
+    {
+      "id": "set-priorities",
+      "description": "The order in which work is taken up across roles and handoffs (EE-040)",
+      "owner": "founder",
+      "level": "decide-inform"
+    },
+    {
+      "id": "defer-or-route",
+      "description": "Whether an idea is worked now or deferred, and to which role",
+      "owner": "chief-of-staff",
+      "level": "decide-inform"
+    },
+    {
+      "id": "spend-register-upkeep",
+      "description": "Record statements, tag charges by entity, flag anomalies",
+      "owner": "operations-finance-lead",
+      "level": "decide"
+    },
+    {
+      "id": "cancel-or-downgrade",
+      "description": "Cancel, downgrade or change the plan of a paid service",
+      "owner": "operations-finance-lead",
+      "level": "recommend-approve",
+      "condition": "Founder approves; Architect consulted if the service is in use"
+    },
+    {
+      "id": "move-payment-method",
+      "description": "Move an existing subscription to the business card or account",
+      "owner": "operations-finance-lead",
+      "level": "recommend-approve",
+      "condition": "Founder performs the change in the vendor account"
+    }
+  ]
+}

package/governance/venture-template/index.md

@@ -0,0 +1,151 @@
+---
+type: venture-template
+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, master-reference, 2026-05-14]
+canonical-for: "what-a-company-is"
+related:
+  - "[[governance/venture-template/README]]"
+  - "[[governance/venture-template/pillars/product]]"
+  - "[[governance/venture-template/pillars/brand]]"
+  - "[[governance/venture-template/pillars/business]]"
+  - "[[sad/SAD_SKILL_v3]]"
+---
+
+# What a company is — the master reference
+
+> **Canonical for:** "what a company is" — the three-pillar reference that the methodology builds toward. This document is the master index; the per-pillar files at `pillars/` and per-role files at `roles/` are the substantive expansions.
+
+A company is **three pillars** working together to **deliver value to a defined audience through one or more products**:
+
+- **[[pillars/product|Product]]** — what the company makes (canonical company products).
+- **[[pillars/brand|Brand]]** — how the company shows up (and brand products, when present).
+- **[[pillars/business|Business]]** — how the company sustains itself (and business products, when present).
+
+Each pillar has teams, roles, and deliverables. **Each pillar can also have products of its own** — Product holds the canonical company products (required); Brand and Business may have products as optional extensions (podcasts, partnership programs, training certifications, etc.). The product-type taxonomy (software / content / service / hardware / hybrid / partnership / program) is orthogonal to which pillar a product sits under — see §35 in [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap]] for the multi-pillar product shape.
+
+Some teams + concerns sit cleanly under one pillar; others span multiple. The pillar model is reference, not boundary — the cross-pillar overlap zones are where most interesting company work happens.
+
+## The pillars are recursive
+
+Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §36]], the three-pillar structure is not just top-level. **Each pillar's products are themselves companies-in-miniature, with their own three-pillar structure.**
+
+A podcast that lives as a Brand-pillar product of the reference project has its own Product pillar (the show), its own Brand pillar (the show's identity within or distinct from the reference project's parent brand), and its own Business pillar (the show's operations, overhead, revenue model). A partnership program living as a Business-pillar product has its own Product, Brand, and Business sub-pillars.
+
+This recursion is how companies organically birth other companies. A sub-project starts as a pillar product under a parent; develops its own three-pillar structure as it matures; eventually either spins out as an independent entity (flat-promotion) or remains a permanent sub-company nested under the parent.
+
+The methodology applies fractally. Articulation closure, version-identity, deliverable templates, skills, hooks — everything works the same way at every recursion level. The reference project gets the same methodology treatment as its parent; a sub-feature would get the same treatment in turn if it grew enough to warrant a sub-company structure.
+
+## The methodology is fluid
+
+Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §37]], this template (and every methodology template) is **explicit about what to consider but implicit about how to document**. The deliverables listed in each pillar file are recommendations + principles + examples — not rigid shapes that every project must produce identically.
+
+The AI surfaces principles, ideas, and deliverables in conversation based on the specific project's context. Different projects, different ambition tiers, different product types — different shapes of documentation. Same considerations.
+
+Documentation is malleable per project + per recursion level. The methodology supports the operator's judgment about what's worth documenting and in what depth — it doesn't override it.
+
+---
+
+## The three pillars at a glance
+
+### Product
+
+*What the company makes.*
+
+Product is the thing the audience uses, reads, plays with, learns from, or builds with. Software apps, hardware devices, content libraries, services, platforms — all forms of "product." Product owns the product spec stack (vision → version → product → data model → impl → behavioral → verification) and everything that translates into running code or shipped artifacts.
+
+Primary deliverables (Tier 1, every Product pillar produces these): product profile, idea-dumps, research synthesis, vision spec, version spec, product spec, roadmap, audience definition, success metrics framework.
+
+Plus product-type-specific deliverables (Tier 2). For software product: data model spec, impl spec, behavioral spec, verification spec, sitemap, IA, UX flows, microcopy, wireframes, component library, accessibility checklist, deploy workflow. For content product: editorial calendar, production workflow, distribution strategy. For service product: service catalog, engagement model, delivery playbooks. Etc. See [[pillars/product]] for the full breakdown.
+
+Typical teams: Engineering, Design (overlap with Brand), Product Management, QA, Data Engineering, DevRel (overlap with Brand + Business), Security (overlap with Business).
+
+Typical roles: CTO, VP Engineering, Engineering Manager, Tech Lead, Senior Engineer, Staff Engineer, Designer, UX Researcher, PM, Group PM, Data Engineer, ML Engineer, Security Engineer, DevRel Engineer.
+
+### Brand
+
+*How the company shows up.*
+
+Brand is the company's identity — visual, verbal, emotional. Brand is the source of truth for what the company looks like, sounds like, and stands for. Brand is what makes the product recognizable, the marketing trustworthy, and the business memorable.
+
+Brand is **imported by the other two pillars, never duplicated**. Product.design wikilinks to brand identity for tokens; business wikilinks to brand voice for marketing copy. If Brand changes, the others reconcile — not the other way around.
+
+Primary deliverables (Tier 1): brand profile, brand identity (colors, typography, logo, imagery style), brand voice + tone + narrative, asset library (wordmark, mark, favicon, OG image), foreshadowing discipline + invariants, version-identities (when persona evolves across product versions).
+
+Typical teams: Marketing, Content, Community, Design (overlap with Product), Communications, Creative Studio.
+
+Typical roles: CMO, VP Marketing, Brand Director, Creative Director, Copywriter, Content Lead, Community Manager, Social Media Manager, PR Lead, Brand Designer.
+
+### Business
+
+*How the company sustains itself.*
+
+Business is the commercial + operational surface — the part of the company that handles money, people, contracts, and the everyday machinery of being a going concern. Business doesn't make the product (that's Product) and doesn't define the identity (that's Brand) — it does everything else that keeps the company running.
+
+Primary deliverables (Tier 1): business profile, market thesis, business model, pricing, sales collateral, ops runbooks, metrics framework, partnership memos, anti-scraping / ToS clauses, app store listing, pitch decks, investor materials, contracts.
+
+Typical teams: Operations, Finance, Sales, Business Development, People, Legal, Customer Success (overlap with Product), Trust & Safety (overlap with Brand + Product).
+
+Typical roles: COO, CFO, CRO / VP Sales, VP BD, Head of People, Head of Ops, General Counsel, Customer Success Lead, Sales Engineer, BD Manager.
+
+---
+
+## Cross-pillar overlap zones
+
+The pillars are reference categories; reality has overlap. The cleanest convention: **primary-pillar tag + secondary-pillar tag in frontmatter**, with overlap zones surfaced explicitly when both pillars contribute substantively.
+
+| Overlap zone | Primary pillar | Secondary pillar | Example deliverables |
+|---|---|---|---|
+| Design System | Product | Brand | Component library, design tokens, visual system docs |
+| Marketing Site | Brand | Business | Landing pages, about page, conversion surfaces |
+| Developer Experience | Product | Brand | SDK docs, API reference, dev portal, code samples |
+| Sales Collateral | Brand | Business | Pitch deck, one-pagers, battle cards |
+| Partnership Materials | Brand | Business | Partner brief, co-marketing assets, joint case studies |
+| PR Strategy | Brand | Business | Press kit, narrative arcs, exec briefing docs |
+| Analytics + Instrumentation | Product | Business | Event taxonomy, metric definitions, dashboards |
+| Customer Success | Business | Product | Onboarding flows, support runbooks, feedback loops |
+| Pricing-as-Product | Business | Product | Pricing tiers, paywalls, plan-gate UX |
+| Trust & Safety | Product | Brand + Business | Moderation tooling, community standards, legal posture |
+| All three (company-wide) | — | — | Mission, Vision, Values, Hiring Rubric, All-Hands, Strategic Plan |
+
+## Company-wide roles (not pillar-specific)
+
+Some roles orchestrate across all three pillars rather than sitting under one. They have their own files at `roles/`:
+
+- **[[roles/ceo|CEO]]** — Chief Executive. Cross-pillar lead; sets direction, hires pillar leads, makes the highest-stakes calls.
+- **Founder** — pre-CEO state for early-stage companies; often plays multiple pillar-lead roles simultaneously. *(to author)*
+- **Chief of Staff** — cross-pillar orchestrator; the CEO's force multiplier. *(to author)*
+- **Board / Advisors** — external governance + counsel. *(to author)*
+
+---
+
+## The methodology's relationship to this template
+
+Per [[sad/pipeline-canonical-view-2026-05-14|the canonical pipeline view]]:
+
+- **Articulate** (0A → 1C): populate the company template for V[N]. Every Tier 1 + Tier 2 deliverable has at least a draft by the end of 1C Articulation Closure.
+- **Build** (2.1 → 2.Final): translate the populated template into running reality.
+- **Ship** (3.1 → 3.4): make the template's commitments verifiable in production.
+- **Operate** (4.1 → 4.4): maintain + evolve + amend.
+
+The methodology doesn't replace the template; it activates it.
+
+---
+
+## What this template is NOT
+
+- **Not an org chart.** Roles describe responsibilities, not headcount.
+- **Not a compliance checklist.** Not every project needs every pillar or every team.
+- **Not entity-class specific (yet).** Current template assumes default modern tech company. Variants for hobby projects, open-source tools, content companies, service companies, hardware companies, and other shapes are queued for authoring.
+- **Not exhaustive of all possible roles.** The per-role files cover the roles most worth formalizing (CEO + pillar leads). Other roles can be added when methodology mechanisms (skills, hooks, commands) need them as context.
+
+## Status
+
+- **2026-05-14:** Initial authoring. Index + 3 pillars + CEO role. Subsequent roles and entity-class variants queued.

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

@@ -0,0 +1,209 @@
+---
+type: venture-template-pillar
+ai-model: claude
+pillar: brand
+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, brand, methodology, 2026-05-14]
+canonical-for: "brand-pillar-reference"
+related:
+  - "[[governance/venture-template/index]]"
+  - "[[governance/venture-template/pillars/product]]"
+  - "[[governance/venture-template/pillars/business]]"
+---
+
+# Brand pillar
+
+> **Purpose:** *How the company shows up.* The source of truth for identity — visual, verbal, emotional. Imported by the other pillars, never duplicated.
+
+---
+
+## Brand pillar products (optional)
+
+Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §35]], the Brand pillar **may** have products of its own — things produced by Brand as expressions of identity that are themselves "products" rather than supporting artifacts for the Product pillar.
+
+Common Brand-pillar products:
+
+- **Brand-led podcasts / YouTube channels** — when content is brand expression, distinct from a Product-pillar content product
+- **Brand campaigns** — films, photoshoots, narrative arcs shipped as standalone works (Nike's "Find Your Greatness," Apple's "1984")
+- **Brand-led events** — conferences, meetups, summits (when the brand IS the event's reason for being)
+- **Merchandise / branded goods**
+- **Brand books / identity manuals** when published externally
+- **Community programs** — when brand-led, not product-led
+- **Sponsorships + brand activations** as recurring offerings
+
+If a Brand-pillar product exists, it runs through the methodology the same way a Product-pillar product does. It has a spec stack (often lighter than software), a roadmap, an articulation-closure inventory, and traverses the four lanes. Its product-type (content / event / merchandise / etc.) determines which Tier 2 deliverable templates apply — independent of the fact that it lives under Brand.
+
+Most early-stage companies do NOT have Brand-pillar products. They have Brand-pillar deliverables (identity, voice, assets) that *support* the Product-pillar product. Brand-pillar products emerge when the brand itself becomes the audience's primary touchpoint, distinct from the canonical product.
+
+**Brand-pillar products are themselves recursive.** Per [[_ideas/build-roadmap-and-html-orchestration-2026-05-12|§36]], a Brand-pillar product (say, a podcast) has its own three-pillar structure: its own Product (the show — episodes, formats, hosts), its own Brand (the show's identity within or distinct from parent brand), and its own Business (hosting costs, sponsor relationships, revenue tracking). The methodology applies fractally — a podcast that's a Brand-pillar product still needs Business-pillar work, handled through the podcast's *own* Business sub-pillar.
+
+---
+
+## What the Brand pillar owns
+
+The Brand pillar owns everything that defines what the company looks like, sounds like, and stands for. Brand is the **source of truth for identity**. When Product needs colors for the design system, it imports them from Brand. When Business needs voice guidelines for marketing copy, it imports them from Brand. **Brand assets exist in exactly one place; everyone else wikilinks.**
+
+Concretely, Brand owns:
+
+- **Visual identity** — colors, typography, logo, wordmark, imagery style, illustration style, iconography
+- **Verbal identity** — tagline (`brand.tagline` in venture.json, EE-046), voice, tone, narrative register, microcopy register, naming conventions
+- **Asset library** — production exports of logos, wordmarks, favicons, OG images, social cards, brand patterns
+- **Foreshadowing discipline** — how the brand evolves predictably across versions; invariants that hold across V1 → V[N]
+- **Version-identities** — per-version persona (one-new-persona-per-version rule); ties to product's version scoping
+- **Brand guidelines** — the document(s) that capture rules for using brand assets in any context
+- **Community standards** — how the brand expects users to interact with it and each other (overlap with Trust & Safety)
+
+Brand **does not** own:
+- The product spec stack — that's Product. Brand provides the visual + verbal identity Product applies.
+- Marketing copy generation — that's Business (or Brand for narrative-heavy work). Brand provides the voice + tone guidelines marketing copy follows.
+- Business model — that's Business. Brand may inform commercial positioning but doesn't define pricing or partnerships.
+
+---
+
+## Typical teams
+
+- **Marketing.** Acquisition, retention, lifecycle. Sits under Brand when the framing is "expressing the brand"; sits under Business when the framing is "operationalizing commercial growth." Most companies have both flavors; the methodology convention is that brand-led marketing sits under Brand.
+- **Content.** Editorial, long-form writing, social, video. The content team is Brand's voice incarnate.
+- **Community.** Forums, Discord, Slack, in-product community. The team that interfaces with users qua community members rather than qua customers.
+- **Design** (overlap with Product). Brand designers (visual systems, brand expression) sit under Brand; product designers (UX, interaction) sit under Product. The design system itself is the overlap artifact.
+- **Communications.** PR, exec comms, internal comms. The team that manages how the brand shows up in external + internal contexts beyond marketing.
+- **Creative Studio.** Production for high-touch creative work (campaigns, films, photoshoots). Often retainer/agency-supplemented.
+
+---
+
+## Typical roles
+
+**Pillar lead:**
+- *To author:* [[../roles/cmo|CMO]] — Chief Marketing Officer. Pillar lead for Brand in most modern companies. (Some companies use "Chief Brand Officer" or "Chief Creative Officer" instead — the role is the same.)
+
+**Senior + management roles:**
+- VP Marketing — runs marketing day-to-day
+- Brand Director — owns brand identity + guidelines
+- Creative Director — owns creative output across channels
+- Content Lead / VP Content — owns editorial + content production
+- Communications Director — PR + exec + internal comms
+- Community Lead / VP Community — community programs + moderation
+
+**Specialist IC roles:**
+- Copywriter — long-form + short-form copy
+- Brand Designer — visual systems, identity work
+- Content Producer — video, podcast, long-form content
+- Social Media Manager — channel-specific content + community
+- Community Manager — daily community operations
+- PR Lead — press + analyst relations
+
+---
+
+## Tier 1 deliverables — every Brand pillar produces these
+
+1. **Brand profile** (`<entity>/brand/profile.md`) — sub-profile describing what Brand is for this entity.
+2. **Brand idea-dumps** (`<entity>/brand/_ideas/`) — raw brand thinking, hypotheses, inspirations.
+3. **Brand identity** (`<entity>/brand/identity.md`) — colors, typography, logo, wordmark, imagery, iconography. **Canonical for visual identity.**
+4. **Brand voice** (`<entity>/brand/voice.md`) — tone, narrative, register, microcopy guidelines. **Canonical for verbal identity.**
+5. **Asset library** (`<entity>/brand/assets/`) — production exports of all brand assets.
+6. **Foreshadowing invariants** — explicit rules about what about the brand cannot change without re-introducing the audience. (See the reference project's I1–I9 invariants as the canonical example.)
+7. **Version-identities document** — per-version persona evolution; the one-new-persona-per-version discipline. (Optional for projects without strong persona discipline; required when the brand evolves significantly across versions.)
+8. **Brand narrative** — the company's story, often in 1-paragraph / 1-page / 1-pager variants for different contexts.
+9. **Naming policy** — for product names, feature names, internal vocabulary. (Light when the brand has one product; heavier when the brand has many.)
+
+---
+
+## Tier 2 deliverables — per-company-type / per-context
+
+Most Brand work is consistent across product types — a Brand pillar for a software company looks pretty similar to a Brand pillar for a content company. The main Tier 2 splits are by **brand maturity** and **brand context**.
+
+### Early-stage (pre-launch, MVP)
+
+- Brand hypothesis (working theory, not committed)
+- One reference asset (logo or wordmark) as proof-of-concept
+- Voice samples in the right register
+- Defer everything else until the product is in users' hands
+
+### Established (post-launch, scaling)
+
+- Brand guidelines document (full guide, exportable to partners + vendors)
+- Asset specifications (file formats, sizing, color profiles, usage rules)
+- Brand audit cadence (annual or semi-annual review)
+- Trademark + IP protection plan (overlap with Business / Legal)
+
+### Multi-surface (brand spans multiple products or surfaces)
+
+- Cross-surface brand consistency rules
+- Per-surface adaptation guidelines (when the same brand needs different application in different products)
+- Brand hierarchy (parent brand → sub-brands; e.g., the reference project → the reference project Journey, the reference project News)
+
+### Multi-version (brand evolves across product versions)
+
+- Version-identities document (one-persona-per-version rule applied)
+- Foreshadowing invariants (what cannot change between versions without breaking continuity)
+- Version-to-version migration guide for brand assets
+
+---
+
+## Tier 3 deliverables — idea-derived
+
+Examples from the reference project's Brand pillar:
+
+- "Caveat fallback issue + Pinyon Script swap decision" — captured as `font-revision-post-v1-ship` idea
+- "Foreshadowing mechanism for V1 → V2 audience expansion" — captured as `foreshadowing-mechanism` idea
+- "Brand Vol I v2 corrections + Voice Vol II R2 §04 reframing" — captured as a brand-revisions sprint
+
+Tier 3 deliverables surface when conversations reveal brand work that doesn't fit any standard template.
+
+---
+
+## Brand's role in the methodology — the import discipline
+
+**Brand is the source of truth for identity. The methodology mechanism is that other pillars *import* from Brand by wikilink; they never copy or duplicate.**
+
+Concrete examples:
+
+- A design system component library imports `[[brand/identity#typography]]` for the type scale.
+- A marketing page imports `[[brand/voice#headline-register]]` for the headline tone.
+- An app store listing imports `[[brand/identity#mark]]` for the icon and `[[brand/voice#description-register]]` for the long description.
+
+If Brand changes, the importers reconcile. **The methodology will not accept a duplicate of a brand asset in another pillar's folder.** The deliverable-discovery skill should detect this and flag it.
+
+### Why this matters
+
+The reference project V1 brand revert (2026-05-13) happened in part because a system font cascade was treated as "the font" when Brand had specified an explicit web font. The cascade was effectively a duplicate of brand identity in Product (the CSS) that drifted out of sync. The import discipline is the fix: Product imports from Brand; the Brand authority is single-source.
+
+---
+
+## Cross-pillar overlap zones (Brand side)
+
+How Brand participates in overlap zones with Product and Business:
+
+- **Brand × Product → Design System.** Brand owns visual tokens + voice; Product owns interaction + behavior; the design system is the shared artifact, **canonical-for: design-system**, lives under Product but imports Brand identity by wikilink.
+- **Brand × Product → Developer Experience.** Brand owns dev portal aesthetic + developer-facing voice; Product owns SDK + API docs. Cross-references both ways.
+- **Brand × Business → Sales Collateral.** Brand owns voice + identity; Business owns commercial framing + audience targeting. Sales collateral lives under Business but imports Brand assets.
+- **Brand × Business → Partnership Materials.** Same shape as sales collateral. Brand assets + voice; Business commercial framing.
+- **Brand × Business → PR Strategy.** Brand owns narrative arcs + exec voice; Business owns analyst + investor + press relationship management.
+- **Brand × Product + Business → Trust & Safety.** Brand owns community standards + voice for moderation messaging; Product owns moderation tooling; Business owns legal + policy posture.
+
+---
+
+## Methodology mechanisms that touch Brand
+
+- **Skills:** `brand-pillar` (auto-loads on Brand work), `version-identity` (the one-persona-per-version discipline), `foreshadowing-audit` (per-version brand-evolution check), `articulation-closure` (Brand-pillar deliverable matrix's gating), `deliverable-discovery` (catches Brand Tier 3 candidates).
+- **Hooks:** `pre-commit` (surfaces brand-load-bearing files for explicit confirmation), `pre-deploy` (checks brand assets are present in code per the v3.2 amendment about explicit font loading).
+- **Selective slash commands:** `/foreshadowing-audit` (runs the V[N] → V[N+1] check on demand).
+
+---
+
+## Related per-role files
+
+- *To author:* [[../roles/cmo|CMO]] — Brand pillar lead
+
+---
+
+## Status
+
+- **2026-05-14:** Initial authoring. Tier 1 + Tier 2 surfaced; Tier 3 illustrated from the reference project examples. CMO role file queued.