naive-framework 0.0.0-stage → 0.2.0

package/evidence/skills/metrics-review/SKILL.md

@@ -0,0 +1,177 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, metrics-review]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: metrics-review
+description: >
+  Run a metrics review against current project / product state — read the
+  metrics framework, evaluate against targets, surface trends, identify
+  outliers, recommend actions. Business-pillar discipline with overlap into
+  Product (instrumentation + event taxonomy). COO-sponsored. Runs at weekly /
+  monthly / quarterly cadences, or on-demand when investigating a sudden change.
+  MANDATORY TRIGGERS: metrics review, KPI review, metrics dashboard, what are
+  our numbers, how is the product performing, weekly metrics, monthly metrics,
+  quarterly review, cohort analysis, retention, conversion, growth metrics,
+  /metrics-review.
+---
+
+# Metrics Review Skill
+
+The Business-pillar workflow for reviewing product / commercial / operational metrics on a recurring cadence.
+
+## Why metrics-review exists
+
+Metrics frameworks are Tier 1 Business-pillar deliverables. But authoring the framework isn't enough — it needs recurring review to produce signal. Without a metrics-review discipline, the framework atrophies; numbers get measured but not interpreted; trends go unnoticed until they're crises.
+
+## When to invoke
+
+- **Cadence-driven:** weekly / monthly / quarterly metrics review meetings
+- **Event-driven:** a sudden spike or drop needs interpretation; a launch needs post-launch review
+- **Decision-driven:** a strategic decision requires current-state understanding (pricing change, scope change, hiring decision)
+- **User-driven:** the operator asks "what are our numbers?" or equivalent
+
+## What metrics-review produces
+
+A metrics review at any cadence produces:
+
+### 1. The scorecard
+
+A snapshot of every load-bearing metric vs. its target:
+
+```
+| Metric | Target | Current | Δ from last review | Status |
+|---|---|---|---|---|
+| Weekly active users | 10K | 8.5K | +12% WoW | ↻ trending toward target |
+| Trial-to-paid conversion | 8% | 6.2% | -1.1pp | ✗ below target |
+| Monthly recurring revenue | $50K | $42K | +5% MoM | ↻ trending toward target |
+| Net retention | 110% | 107% | flat | ↻ stable, slightly below |
+| Page-load p95 | < 1s | 1.4s | +0.2s | ✗ regressing |
+```
+
+Status icons: ✓ at-or-above-target / ↻ trending / ✗ below-target-or-regressing.
+
+### 2. The narrative
+
+Per metric category (acquisition, activation, retention, revenue, referral; or whatever taxonomy the project uses), 1-2 sentences on what's happening + why.
+
+### 3. The action items
+
+Concrete actions surfaced by the review:
+
+- **Investigate** — for metrics where the cause isn't clear
+- **Intervene** — for metrics that need direct action
+- **Adjust target** — for metrics where the target itself was wrong
+- **Hold** — for metrics that are fine; no action needed
+
+Every action has an owner, due date, and follow-up cadence.
+
+### 4. Trend observations
+
+Patterns that span multiple metrics:
+
+- "Acquisition is healthy, activation is regressing — investigate onboarding flow"
+- "Revenue trending up but retention regressing — at-risk for churn cliff"
+- "All metrics flat for 6 weeks — investigate whether instrumentation is broken"
+
+## How to run a metrics review
+
+When this skill is loaded, the AI should:
+
+### Step 1 — Identify the metrics framework
+
+Read the entity's metrics framework deliverable (typically at `<entity>/business/metrics-framework.md` or equivalent). Identify:
+- Which metrics are tracked
+- What the targets are
+- What the cadence is
+- Where the current data lives
+
+If no metrics framework exists, surface the gap and enter backfill per
+`operations/skills/_patterns/gate-backfill.md`. Skill-specific notes:
+
+## Backfill / missing assets
+
+| Missing | Recovery |
+|---|---|
+| No metrics framework | Author minimal framework first (Tier 1 Business); then review |
+| Framework but no instrumentation | Product owns event taxonomy; review exits with instrumentation debt lines, not fake numbers |
+| Instrumentation but no cadence | Set cadence; run first review immediately |
+| Review overdue | Run review now; do not skip to “adjust targets” without a scorecard |
+
+**Freeze:** do not change product goals or pricing from “metrics” that lack a framework and current values.  
+**Exit:** framework exists; at least one dated scorecard; action items owned.
+
+### Step 2 — Identify the data source
+
+Where do the actual numbers live? Options:
+- Analytics platform (PostHog, Amplitude, Mixpanel, etc.)
+- Internal dashboard
+- Manual SQL queries against the database
+- Spreadsheet maintained by the team
+
+The skill doesn't fetch data directly (in most environments); it prompts the operator to provide the current numbers OR walks the operator through how to fetch them.
+
+### Step 3 — Walk the scorecard
+
+For each metric:
+- Current value vs. target
+- Delta from last review
+- Status (✓ / ↻ / ✗)
+- Brief interpretation
+
+### Step 4 — Build the narrative
+
+Group metrics by category (acquisition, activation, retention, revenue, referral, or project-specific). For each category, 1-2 sentences on the story the data tells.
+
+### Step 5 — Surface action items
+
+For each ✗ (below target) or surprising ✓ (above target):
+- What's the most likely cause?
+- What action does it suggest?
+- Who owns it?
+- When's the follow-up?
+
+For each ↻ (trending), note the trajectory and the date by which the trend should be confirmed.
+
+### Step 6 — Identify cross-metric patterns
+
+Step back from individual metrics. What patterns span multiple? Are some metrics signaling something the others aren't?
+
+### Step 7 — Update the orchestration HTML
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|§32]], surface the scorecard + action items in the Business pillar section of the orchestration HTML. The most recent review's date + status snapshot is visible at a glance.
+
+## Posture
+
+Metrics-review runs in **office-hours mode**. The work is critical evaluation — sharp framing, demand evidence, identify weakest claims. Friend mode is wrong for metrics reviews; numbers don't care about the operator's feelings.
+
+Exception: if the metrics review surfaces something that needs vision-expansion (e.g., "we should rethink what we're measuring"), briefly shift to friend mode for the re-vision conversation, then return to office-hours for the review's conclusion.
+
+## Cadence
+
+Different metrics warrant different review cadences:
+
+- **Daily** — system-health metrics (uptime, error rate, queue depth)
+- **Weekly** — operational metrics (WAU/DAU, conversion, support volume)
+- **Monthly** — business metrics (MRR, retention, expansion, churn)
+- **Quarterly** — strategic metrics (LTV/CAC, payback period, market share)
+
+The cadence should be in the metrics framework deliverable.
+
+## What metrics-review is NOT
+
+- **Not the source of metrics.** The framework is the source; the review interprets.
+- **Not a substitute for instrumentation.** If the data isn't there, review can't help. Surface the gap.
+- **Not a vanity-metrics exercise.** Metrics that don't connect to action are noise. The review should challenge metrics that don't drive decisions.
+- **Not Product-pillar work.** It's Business with overlap into Product. Product owns instrumentation + event taxonomy; Business owns metric definitions + dashboards.
+
+## Relationship to other skills
+
+- [[../business-pillar/SKILL|business-pillar]] — auto-loads on Business work; metrics-review is one of its workflows
+- [[../office-hours-mode/SKILL|office-hours-mode]] — the right posture
+- [[../stakeholder-update/SKILL|stakeholder-update]] — metrics-review outputs often feed stakeholder updates
+
+## Status
+
+- **2026-05-14:** Initial authoring.

package/evidence/tooling/integrations.json

@@ -0,0 +1,153 @@
+[
+  {
+    "id": "ee-evals",
+    "name": "Repo evals",
+    "layer": "evidence",
+    "role": "skill and harness evals in evidence/evals",
+    "interfaces": [
+      "files"
+    ],
+    "status": "in-use"
+  },
+  {
+    "id": "github-checks",
+    "name": "GitHub checks",
+    "layer": "evidence",
+    "role": "CI results as evidence",
+    "interfaces": [
+      "api"
+    ],
+    "status": "in-use"
+  },
+  {
+    "id": "stripe",
+    "name": "Stripe",
+    "layer": "evidence",
+    "role": "per-product revenue for the P&L",
+    "interfaces": [
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Lineup draft names it as the revenue source"
+  },
+  {
+    "id": "amplitude",
+    "name": "Amplitude",
+    "layer": "evidence",
+    "role": "product analytics",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Connector available, not signed in"
+  },
+  {
+    "id": "vercel",
+    "name": "Vercel",
+    "layer": "evidence",
+    "role": "web analytics and deployments: visitors, users and page views per site, for the products a venture deploys there",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): business operations needs to know how audiences receive a product, not how its code is built, so analytics are a source of truth for validation evidence",
+    "credentials": [
+      "VERCEL_TOKEN"
+    ],
+    "links": [
+      "https://vercel.com/docs/analytics"
+    ]
+  },
+  {
+    "id": "cloudflare",
+    "name": "Cloudflare",
+    "layer": "evidence",
+    "role": "web analytics and traffic for sites and Workers a venture deploys there",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): business operations needs to know how audiences receive a product, not how its code is built, so analytics are a source of truth for validation evidence",
+    "credentials": [
+      "CLOUDFLARE_API_TOKEN"
+    ],
+    "links": [
+      "https://developers.cloudflare.com/web-analytics/"
+    ]
+  },
+  {
+    "id": "netlify",
+    "name": "Netlify",
+    "layer": "evidence",
+    "role": "site analytics for ventures that deploy there",
+    "interfaces": [
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): business operations needs to know how audiences receive a product, not how its code is built, so analytics are a source of truth for validation evidence",
+    "credentials": [
+      "NETLIFY_AUTH_TOKEN"
+    ]
+  },
+  {
+    "id": "google-analytics",
+    "name": "Google Analytics 4",
+    "layer": "evidence",
+    "role": "website and app analytics: users, sessions, acquisition and conversions",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): business operations needs to know how audiences receive a product, not how its code is built, so analytics are a source of truth for validation evidence",
+    "credentials": [
+      "GOOGLE_APPLICATION_CREDENTIALS"
+    ]
+  },
+  {
+    "id": "posthog",
+    "name": "PostHog",
+    "layer": "evidence",
+    "role": "product analytics: active users, funnels and retention",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): business operations needs to know how audiences receive a product, not how its code is built, so analytics are a source of truth for validation evidence",
+    "credentials": [
+      "POSTHOG_API_KEY"
+    ]
+  },
+  {
+    "id": "listen-labs",
+    "name": "Listen Labs",
+    "layer": "evidence",
+    "role": "AI-moderated customer interviews with recruited participants: qualitative evidence for problem, solution, pricing and product-market-fit validation, and later audience research",
+    "interfaces": [
+      "app"
+    ],
+    "status": "candidate",
+    "reason": "Owner, 2026-10-28 (EE-039): a research tool for the validation phase and any phase it serves. Its site states no API or MCP server yet, so studies come in as exported reports until one is confirmed (docs.listenlabs.ai)",
+    "links": [
+      "https://listenlabs.ai"
+    ]
+  },
+  {
+    "id": "jev",
+    "name": "Jev (TypeSafe AI)",
+    "layer": "evidence",
+    "role": "scores validation sub-scores and need-now priors as probabilities",
+    "interfaces": [
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "The validation schemas name it as the scorer (EE-026, EE-028)",
+    "credentials": [
+      "TYPESAFE_API_KEY"
+    ]
+  }
+]

package/governance/layer.json

@@ -0,0 +1,102 @@
+{
+  "layer": "governance",
+  "purpose": "Say who owns and controls the venture and who may decide what: ownership (cap table), founders, boards, investor rights and exits, roles, decision rights, where it publishes and who may publish what (the publication gate), the venture template and its pillars, and escalation to the owner.",
+  "skills": [
+    {
+      "id": "brand-pillar",
+      "path": "governance/skills/brand-pillar/SKILL.md"
+    },
+    {
+      "id": "business-pillar",
+      "path": "governance/skills/business-pillar/SKILL.md"
+    },
+    {
+      "id": "chief-of-staff",
+      "path": "governance/skills/chief-of-staff/SKILL.md"
+    },
+    {
+      "id": "cross-pillar-tradeoff",
+      "path": "governance/skills/cross-pillar-tradeoff/SKILL.md"
+    },
+    {
+      "id": "executive-roles",
+      "path": "governance/skills/executive-roles/SKILL.md"
+    },
+    {
+      "id": "office-hours-mode",
+      "path": "governance/skills/office-hours-mode/SKILL.md"
+    },
+    {
+      "id": "product-pillar",
+      "path": "governance/skills/product-pillar/SKILL.md"
+    },
+    {
+      "id": "role-and-candidate-authoring",
+      "path": "governance/skills/role-and-candidate-authoring/SKILL.md"
+    },
+    {
+      "id": "stakeholder-update",
+      "path": "governance/skills/stakeholder-update/SKILL.md"
+    },
+    {
+      "id": "cofounder-structure",
+      "path": "governance/skills/cofounder-structure/SKILL.md"
+    },
+    {
+      "id": "board-design",
+      "path": "governance/skills/board-design/SKILL.md"
+    },
+    {
+      "id": "equity-and-share-classes",
+      "path": "governance/skills/equity-and-share-classes/SKILL.md"
+    },
+    {
+      "id": "financing-and-investor-rights",
+      "path": "governance/skills/financing-and-investor-rights/SKILL.md"
+    },
+    {
+      "id": "exit-planning",
+      "path": "governance/skills/exit-planning/SKILL.md"
+    },
+    {
+      "id": "publication-policy",
+      "path": "governance/skills/publication-policy/SKILL.md"
+    }
+  ],
+  "records": [
+    "decision-rights",
+    "role",
+    "pillar",
+    "ownership",
+    "board",
+    "founder-agreement",
+    "exit",
+    "publication-policy",
+    "decision-record",
+    "venture-role"
+  ],
+  "reads": [
+    "handoff",
+    "evidence",
+    "venture",
+    "telos"
+  ],
+  "writes": [
+    "decision",
+    "handoff"
+  ],
+  "checks": [
+    "schema/check-governance.mjs",
+    "schema/payouts.mjs",
+    "schema/check-publication.mjs",
+    "schema/decisions.mjs"
+  ],
+  "gaps": [
+    "Roles have no schema",
+    "Escalations land in handoffs; nothing collects open escalations for the owner",
+    "MAD's governance-tier answers are derived from these records by MAD's derive-answers (MAD repo, operations/skills/methodology-selection/derive-answers.mjs), which does not yet read telos steering, venture regulation or the continue-or-stop, change-direction and set-priorities classes (EE-040)",
+    "The decision matrix (schema/decisions.mjs) gathers decision records, unconfirmed foundation statements and gated drafts; need-now suggestions, failing checks and forecasts are not gathered yet, and nothing writes decision records through the router yet (EE-054)",
+    "Decision records carry provenance, outcomes and unlocks (EE-058), but nothing yet closes an activity to a person or agent until the decision that unlocks it is made, nothing prompts for actual outcomes when they fall due, and Mentura's decision analytics are not built"
+  ],
+  "name": "governance"
+}

package/governance/references/references.json

@@ -0,0 +1,26 @@
+{
+  "layer": "governance",
+  "references": [
+    {
+      "id": "keller-2020-strategic-brand-management",
+      "title": "Strategic Brand Management: Building, Measuring, and Managing Brand Equity (5th edition)",
+      "authors": [
+        "Kevin Lane Keller",
+        "Vanitha Swaminathan"
+      ],
+      "year": 2020,
+      "kind": "book",
+      "summary": "Brand equity built through brand elements: names, URLs, logos, symbols, characters, spokespeople, slogans, jingles, packaging and signage, chosen for memorability, meaningfulness, likability, transferability, adaptability and protectability (chapter 4).",
+      "url": "https://www.pearson.com/en-us/subject-catalog/p/Keller-Strategic-Brand-Management-Building-Measuring-and-Managing-Brand-Equity-Subscription-5th-Edition/P200000005947/9780134892498",
+      "checked": "2026-10-28",
+      "informs": [
+        "field:venture.brand",
+        "field:venture.brand.tagline"
+      ],
+      "stance": {
+        "is": "adapted",
+        "why": "The brand record follows Keller's brand elements; Keller's 'slogan' is split into the enduring tagline (on the venture) and a campaign's slogan (on the campaign), as marketing practice does (EE-046)."
+      }
+    }
+  ]
+}

package/governance/skills/board-design/SKILL.md

@@ -0,0 +1,68 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, governance, board, advisors]
+ai-model: claude-opus-5.5
+created: 2026-10-27T15:49:30Z
+source: hybrid
+name: board-design
+description: >
+  Help a founder decide whether and when to have a board, formal or advisory;
+  its size and seats (founder, investor, independent, observer); who appoints
+  each seat; which matters only the board may decide; and which powers the
+  founders keep. Also covers advisors and an advisory board. Records it in
+  governance/board.json. Founder decision with counsel (EE-022).
+  MANDATORY TRIGGERS: board, board of directors, board seat, independent
+  director, observer, advisory board, advisor, adviser, reserved matters,
+  protective provisions, board control, when do I need a board.
+---
+
+# Board design
+
+Governance layer, ownership-and-control kit (EE-022). Writes `board.json`; `check-governance.mjs` checks every seat against `ownership.json`.
+
+## 1. Whether, and when
+
+| State | Board |
+| --- | --- |
+| Hobby, lifestyle, sole owner | None. A corporation still has directors in law, often just the founder; record that as a one-seat formal board |
+| Managed growth, bootstrapped | Optional. An **advisory board** often helps more than a formal one: advice without giving up control |
+| First priced round (seed or Series A) | A **formal board** is usually a condition of the round. `check-governance.mjs` requires one with venture-capital funding |
+| Later rounds, many investors | Larger board, independent directors, committees (audit, compensation) |
+
+A SAFE or note alone usually does not bring a board seat.
+
+## 2. Size and seats
+
+- Odd numbers avoid deadlock. A common seed board is three: two founder seats and one investor seat, or one founder, one investor and one independent agreed by both. A common Series A board is five.
+- **Who appoints each seat matters more than who sits there.** Seats appointed by the common shareholders (in practice, the founders) keep control with the founders; seats appointed by a preferred class go to investors; an independent seat chosen by the board balances them.
+- **Observers** attend but do not vote; investors often ask for one in place of a seat.
+- Write each seat as `{ id, person, type, appointed_by }`; an investor seat's `appointed_by` must hold the `board-seat` right in `ownership.json`.
+
+## 3. Powers: what the board decides and what founders keep
+
+- **Reserved matters** (only the formal board decides): issuing or reclassifying shares, the annual budget, hiring or removing the CEO, selling, merging or winding down, large debt.
+- **Investor protective provisions** are separate: votes held by the preferred shareholders themselves, whatever the board says (NVCA model documents). They usually cover new senior shares, changing their rights, selling the company and changing the board's size.
+- What founders keep depends on the seats they appoint, their share of the votes (including super-voting shares, see `equity-and-share-classes`) and what is left out of the reserved matters.
+
+## 4. Advisors and the advisory board
+
+- An advisory board advises and decides nothing; `check-governance.mjs` refuses reserved matters on it.
+- Advisors usually get small common-stock grants with vesting, often over two years, under a standard agreement. The Founder Institute's FAST (Founder/Advisor Standard Template) is the common starting point. Record the advisor as a holder (`kind: advisor`) with `agreement` and the grant in `ownership.json`, and their seat on the advisory board.
+- Agree what the advisor will actually do and how often before agreeing the grant.
+
+## 5. Cadence
+
+Formal boards of early companies commonly meet every six weeks to quarterly; advisory boards quarterly or as needed. Record `meets`.
+
+## Guardrails (all five ownership-and-control skills)
+
+- These are **founder decisions made with counsel** (decision class `ownership-or-control`, level escalate). An agent lays out the options, the trade-offs and the sources, drafts the records and documents, and stops. It never signs, files or agrees to anything.
+- Rules differ by country, state and legal form. Everything here is the common US startup default unless it says otherwise; name the jurisdiction before relying on it.
+- The signed documents are the truth. The records in `governance/` summarise them so agents and checks can read them; when the two disagree, fix the record.
+- Sources below are named from the method author's knowledge and still need recording with `find-reference` (URL and checked date) before a default is treated as settled.
+
+## Sources
+
+- Brad Feld and Mahendra Ramsinghani, *Startup Boards* (Wiley, 2013).
+- National Venture Capital Association (NVCA) model legal documents: Voting Agreement, Certificate of Incorporation.
+- Founder Institute, FAST (Founder/Advisor Standard Template).

package/governance/skills/brand-pillar/SKILL.md

@@ -0,0 +1,90 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, brand-pillar]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: brand-pillar
+description: >
+  Provide Brand pillar context — teams, roles, Tier 1 deliverables (identity,
+  voice, asset library, foreshadowing invariants, version-identities),
+  cross-pillar overlap zones, and the import discipline (Brand is the source of
+  truth; other pillars wikilink, never duplicate). Auto-loads when working on
+  brand identity, voice, visual systems, marketing, community, PR, brand-led
+  products, or any Brand-pillar concern. References venture-template/pillars/brand.md
+  as the canonical reference. Per SAD v3.3+ amendment §33.
+  MANDATORY TRIGGERS: brand pillar, brand work, brand identity, voice, tone,
+  logo, wordmark, OG image, typography, colors, marketing, content, community,
+  PR, CMO, foreshadowing, version-identities, narrative, naming, brand assets,
+  brand book, brand guidelines, brand campaign.
+---
+
+# Brand Pillar Skill
+
+The context-providing skill for Brand-pillar work. Auto-loads when brand-pillar concerns surface in conversation.
+
+## What this skill provides
+
+- **Brand pillar reference** — [[../../venture-template/pillars/brand|venture-template/pillars/brand.md]] for the canonical Brand pillar description
+- **CMO role context** — [[../../venture-template/roles/cmo|venture-template/roles/cmo.md]]
+- **The import discipline** — Brand is the source of truth for identity; other pillars wikilink to Brand, never duplicate
+- **Tier 1 deliverable awareness** — identity, voice, asset library, foreshadowing invariants, version-identities
+- **Optional Brand-pillar products** — when present (campaigns, brand-led podcasts, events, merchandise, brand books)
+
+## When to invoke
+
+Auto-loads when:
+
+- Brand identity work is happening (colors, typography, logo, imagery)
+- Voice + tone + narrative work is happening
+- Marketing, content, community, or PR work surfaces
+- A foreshadowing audit is being run (V[N] → V[N+1] persona evolution)
+- Version-identities document is being authored
+- Brand assets are being shipped (favicon, OG image, wordmark exports)
+- Naming decisions are being made (product names, feature names)
+- Brand-load-bearing files appear in commits (per pre-commit ritual)
+
+## What this skill emphasizes
+
+When loaded, the AI should keep in mind:
+
+1. **Brand is the source of truth.** Other pillars import from Brand by wikilink. Watch for duplication — if Product or Business is defining identity locally, that's drift. The methodology will not accept a duplicate brand asset in another pillar's folder.
+
+2. **Foreshadowing is structural.** V[N] must foreshadow V[N+1]'s audience and capabilities. Brand changes between versions are deliberate, not accidental. The version-identities discipline + foreshadowing invariants prevent brand whiplash across versions.
+
+3. **CMO is the pillar lead.** Brand-pillar sign-offs map to CMO authority. When brand-load-bearing files ship, CMO awareness is implicit.
+
+4. **Brand-pillar products are optional.** Most early-stage companies don't have them. They emerge when the brand itself becomes the audience's primary touchpoint distinct from the canonical product. Don't force a Brand-pillar product structure on a project that just needs identity + voice.
+
+5. **The import-not-duplicate discipline is methodology-load-bearing.** A V1 brand revert (2026-05-13) happened in part because a system font cascade was effectively a duplicate of brand identity in Product that drifted out of sync. The discipline is the fix.
+
+## Brand authoring posture
+
+Brand work typically lands in friend mode (vision expansion — what could the identity be?) and shifts to office-hours mode when converging on the canonical identity. Mode-aware:
+
+- **Identity hypothesis / early-stage** — friend mode dominant
+- **Identity convergence / brand book authoring** — mixed mode; friend for breadth, office-hours for what makes the cut
+- **Brand audit / foreshadowing audit** — office-hours mode (looking for inconsistency, drift, weakness)
+
+## Cross-pillar overlap behavior
+
+When work crosses pillars:
+
+- **Design system** (Brand × Product) — Brand owns visual tokens + voice; Product owns interaction. Co-authored artifact.
+- **Marketing site** (Brand × Business) — Brand owns voice + identity; Business owns conversion strategy.
+- **Developer experience** (Brand × Product) — Brand owns dev portal aesthetic + voice; Product owns SDK / API docs.
+- **Sales collateral** (Brand × Business) — Brand owns voice + identity; Business owns commercial framing.
+- **PR strategy** (Brand × Business) — Brand owns narrative; Business owns press / analyst / investor relationships.
+- **Trust & safety** (Brand × Product × Business) — Brand owns community standards + voice for moderation messaging.
+
+## Related skills
+
+- [[../version-identity/SKILL|version-identity]] — Brand-led; runs at version boundaries
+- [[../articulation-closure/SKILL|articulation-closure]] — Brand-pillar deliverables in the closure inventory
+- [[../friend-mode/SKILL|friend-mode]] / [[../office-hours-mode/SKILL|office-hours-mode]] — posture skills for Brand work
+- [[../product-pillar/SKILL|product-pillar]] — companion pillar; design system overlap zone
+- [[../business-pillar/SKILL|business-pillar]] — companion pillar; sales collateral + PR overlap zones
+
+## Status
+
+- **2026-05-14:** Initial authoring. References venture-template/pillars/brand.md as the canonical Brand pillar reference.