Canonical Components · v18

LOCKED 2026-05-24 by Reviewer. This is the locked component structure every new 0HR brand installs once intake is submitted.

Source: canonical v18 spec lives in code at apps/portal/lib/canonical/components-v18.ts (repo). Updates require Reviewer lock pass. Supersedes: the prior flat 14-component model (kept in components.ts for backward compat with existing brand.config slugs).

The three-level model

BRAND ENGINEERING   ← one-time onboarding setup per brand (NOT a numbered level)
  · Brand Intake · Brand Diagnostic · Brand Blueprint (7 foundation outputs)

L1 · LEAD GEN       ← Sprint 1 · 3 weeks · Invisible → In Demand · Qualified Leads × CLTV
  01 Content Distribution
  02 Lead Generation
  03 Lead Qualification

L2 · CLIENT ACQUISITION  ← Sprint 2 · 6 weeks · Inconsistent → Predictable · LTV > CAC
  04 Client Acquisition
  05 Client Retention
  06 Referral Engine

L3 · DAILY OPERATIONS    ← Sprint 3 · 9 weeks · Trapped → Liberated · $ Net Profit / Hours → ∞
  07 Offer Architecture · 08 Workforce Operations · 09 Owner Liberation
  [DEFERRED · not yet ratified]

Slug taxonomy

Every sub-deliverable has a stable slug: <level>.<component>.<sub-component>. Examples:

• l1.lead-gen.lm-bundle — the Lead Magnet Bundle (Landing + Quiz + Access + LM Content + Delivery Email)
• l2.client-acq.pre-sell — the Pre-Sell page (3 style variants: Short · Long · VSL)
• l2.client-acq.booking-flow — Schedule + Confirmation + Qualifying Page + Reschedule

Bundle pattern

A Bundle = ONE generation call that produces multiple coherent sub-pieces. Why: when several deliverables share the same magnet/audience/voice, generating them separately invites drift. Generating them as a unit guarantees coherence.

Bundles in v18:

• l1.lead-gen.lm-bundle → Landing + Quiz + Access + LM Content + Delivery Email
• l1.lead-gen.dynamic-retargeting → Nurture 7-Email + Retargeting Ads
• l2.client-acq.booking-flow → Schedule + Confirmation + Qualifying Page + Reschedule

Multiple Bundle instances per brand: e.g. MCM has 3 LM Bundles (wellness-plan, resource-guide, chapter-17), each producing its own 5 sub-pieces.

Reference rule (2-4 refs per deliverable)

Every sub-deliverable pulls 2-4 reviewer-rated 4-5/5 library refs for pattern extraction. Locked in lib/install/components.ts getDynamicReferences:

• Min 2 rated 4-5/5 refs → otherwise gen logs warning + falls back to top unrated
• Max 4 refs → above this = noise dilution (per pattern-extraction analysis)
• Slug aliases share refs where relevant (landing covers landing_page, marketing_website)

Per-deliverable spec depth

Each sub-deliverable has its own page under /os/brand/canonical/:

Generation pipeline

The canonical pipeline at lib/install/components.ts reads:

1. Canonical prompt from lib/prompts/components/<slug>.md (6-block structure)
2. 2-4 library refs filtered by slug aliases · rated 4-5/5
3. Pattern extraction via Claude Opus 4.7 per ref (cached per session)
4. Brand foundation context (positioning + targeting + offer blueprints)
5. Variant-specific context (for bundle instances)

Then fires Claude with hard rules: no em-dash · no fabrication · Title Case · brand voice locks.

Output writes to brand.config.engine.components[<slug>].content_json (or bundles[<bundle-slug>][<instance-slug>] for bundles).

Two-stage lock per sub-deliverable

draft  →  copy_locked  →  hifi_locked  →  live
        (Reviewer QA Doc)   (Reviewer QA preview)  (Reviewer says publish)

Score ≠ approval. Edits ≠ approval. Only explicit "lock it" from Reviewer → portal fires the lock endpoint.

Approval routing

Per role taxonomy: