---
type: MePB
asset_id: MePB-BMF-MF-DemandGenPack-v01
version: v01
status: Draft — pendiente ratificación Victor
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
fecha_creacion: 2026-06-10
fecha_ultima_actualizacion: 2026-06-10
intellbank: IB-XX-Maestro
subbank: MF-XX-MetaFactorias
metafactory_id: MF-BMF-DemandGenPack
tipo_metaplaybook: Type D — Domain MetaFactory MetaPlaybook
capa_bmf: L2
dominio: Producción de Kits de Materiales de Generación de Demanda por producto/servicio
metodologia: Híbrida — B2C / B2O / B2B
audiencia: Factory Builders y operadores de factorías de kits (EmpowerLabs y organizaciones derivadas)
riesgo: Medio — activos market-facing; el QA de oferta y de voz es crítico
proposito: Blueprint constitucional de la MetaFactoría de DemandGenPack — define qué es un Kit, su arquitectura de estaciones, registros y contratos de delegación para que cualquier factoría (EL u otra) produzca kits replicables
relacionados: "[[FM-EL-OfertaIrresistible-v01]] · MF-BMF-HybridDemand-v02 · MF-BMF-GTM-v02 · MePB-BMF-MetaFactoryBuilder-v01"
tags: [metafactoria, type-d, kits, demand-gen, hibrido, b2o]
---

## Asset Header

- **Asset ID:** MePB-BMF-MF-DemandGenPack-v01
- **MetaFactory ID:** MF-BMF-DemandGenPack
- **Tipo:** Type D — Domain MetaFactory MetaPlaybook · **Capa:** L2
- **Status:** Draft · **Owner:** Victor Heredia · **Sherpa:** Jay · **Ratificador:** Victor Heredia
- **Dominio:** Kits de Materiales de Generación de Demanda (metodología híbrida B2C/B2O/B2B)
- **Documento companion (futuro):** FAC-EL-DemandGenPack-v01 — instancia EmpowerLabs de esta MetaFactoría

---

## 1. Propósito y alcance del dominio

### 1.1 Por qué existe esta MetaFactoría

Cada producto o servicio que sale al mercado necesita el mismo paquete de materiales de generación de demanda — y hoy ese paquete se produce ad-hoc, con calidad variable y sin contratos. Esta MetaFactoría convierte la producción de ese paquete en un sistema gobernado: define **qué es un Kit Demand Gen**, qué componentes lo integran, qué estaciones lo producen y qué gates lo validan, de forma replicable para cualquier producto, organización y modalidad de mercado (B2C, B2O, B2B).

### 1.2 La unidad del dominio: el Kit Demand Gen

Un **Kit Demand Gen** es el paquete canónico de 8 componentes que un producto o servicio necesita para generar demanda de forma sistemática:

| # | Componente | Función en el journey |
|---|-----------|----------------------|
| K1 | Conceptualización y especificaciones del producto | Fundamento — qué es, para quién, mecanismo propio |
| K2 | Landing page con oferta irresistible | Captura y conversión |
| K3 | Video corto (1–3 min) | Hook — atención y reconocimiento del problema |
| K4 | Video largo (15–45 min) | Conversión profunda — educación y future pacing |
| K5 | Paper / artículo corto | Divulgación — nombrar el problema, sacar del dolor |
| K6 | Whitepaper | Autoridad — el producto a fondo, evidencia |
| K7 | MasterPlaybook Inteligente (MPI) | Educa-captura-convierte: contenido profundo + Sherpa IA en modalidad MPI + paquete Q&A + tagging hacia CRM |
| K8 | Paquete de posts | Distribución — alimentar canales |

**Principio rector del Kit:** la **oferta es el corazón**; los 8 componentes son expresiones de ella. Ningún componente se produce antes de que la oferta pase sus gates ([[FM-EL-OfertaIrresistible-v01]]). El mapeo psicológico de componentes al journey sigue la secuencia pain→pleasure definida en esa fórmula.

### 1.3 Modalidad híbrida

El Kit es el mismo en estructura para B2C, B2O y B2B; lo que varía es la **configuración** (nicho por avatar vs por rol, tipo de garantía, registro de evidencia, canal). La tabla de adaptación híbrida vive en [[FM-EL-OfertaIrresistible-v01]] §3 y es módulo obligatorio de toda factoría instanciada.

---

## 2. Declaración de herencia

| Capa | Autoridad | Relación |
|------|-----------|----------|
| L0 | Big MetaFactory Kernel | Hereda gobernanza base |
| L0.5 | MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01 | Cumple estructura de MetaPlaybooks |
| L1 | MePB-BMF-MetaFactoryBuilder-v01 | Construida bajo su protocolo Type D |
| L2 (pares) | MF-BMF-HybridDemand-v02 | **Interfaz, no herencia:** HDG-MF gobierna el sistema de demanda (journey unaware→refer); esta MF produce los kits que ese sistema consume |
| L2 (pares) | MF-BMF-GTM-v02 | **Interfaz:** la estación E04-DemandGen del pipeline GTM solicita kits a esta MetaFactoría |

En caso de conflicto, gana la autoridad de capa superior.

---

## 3. Arquitectura de estaciones (arquetipos)

Siete arquetipos de estación. Definen QUÉ debe existir — el CÓMO se delega al Factory Builder de cada instancia.

### EST-01 · Inteligencia

- **Propósito:** reunir la materia prima cognitiva del kit — investigación de mercado y del problema, contraste contra el vault (Gate G0), y ensamblaje del **BrainX del Kit** (selección de Brain Codes expertos pertinentes al dominio del producto).
- **Inputs:** brief del producto · vault (Brain Codes, research previo) · fuentes externas.
- **Outputs:** dossier de inteligencia del kit · market research con **scorecard /50 y decisión** (módulo MOD-07, nivel N1 mínimo / N2 default) · configuración BrainX del kit.
- **Interfaces:** registro de Brain Codes (BC-) · spec de ensamblaje BrainX (módulo MOD-03) · [[FM-EL-MarketResearch-v01]] (MOD-07).
- **Delegación:** Factory Builder + BrainX Builder. **Gate de salida:** sin scorecard con veredicto Advance, EST-02 no se activa.

### EST-02 · Oferta

- **Propósito:** ejecutar [[FM-EL-OfertaIrresistible-v01]] (6 fases, 5 gates) y producir el Offer Canvas del producto.
- **Inputs:** dossier de inteligencia · brief del producto · Objection Bank.
- **Outputs:** **OFC-[ENT]-[Producto]-OfferCanvas-vNN** con veredicto de gates G1–G5.
- **Interfaces:** schema Offer Canvas (módulo MOD-01).
- **Delegación:** Factory Builder. **Gate duro:** sin Offer Canvas en PASS, las estaciones EST-04 a EST-07 no se activan.

### EST-03 · Concepto y Especificaciones

- **Propósito:** producir la conceptualización formal del producto/servicio: definición, mecanismo propio nombrado, escalera de ofertas (3 niveles + continuidad), modelo de entrega.
- **Inputs:** Offer Canvas · dossier de inteligencia.
- **Outputs:** SPEC del producto (K1).
- **Interfaces:** schema de spec de producto.
- **Delegación:** Factory Builder.

### EST-04 · Narrativa

- **Propósito:** producir la narrativa maestra del kit — mensajes núcleo por fase del journey (pain→pleasure), lenguaje del cliente, hooks, story y estructura de evidencia — de la que TODOS los componentes derivan su copy. Una sola fuente de verdad narrativa por kit.
- **Inputs:** Offer Canvas · SPEC · estándar de voz (VVP).
- **Outputs:** documento de narrativa maestra del kit.
- **Interfaces:** mapeo componente→journey ([[FM-EL-OfertaIrresistible-v01]] §1 Fase 5).
- **Delegación:** Factory Builder.

### EST-05 · Producción de Componentes

- **Propósito:** producir los 8 componentes (K1–K8) a partir de la narrativa maestra y el Offer Canvas. Incluye los guiones audiovisuales (la producción de video puede sub-delegarse) y el **paquete MPI completo**: contenido (análisis del problema, investigación, solución, beneficios, calculadora opcional, recursos), instrucciones de modalidad para el Sherpa IA, paquete Q&A, e instrucciones de tagging hacia el CRM.
- **Inputs:** narrativa maestra · Offer Canvas · SPEC · plantillas del Template Registry.
- **Outputs:** K2–K8 en versión candidata.
- **Interfaces:** contratos de artefacto (§4) · spec modalidad MPI (módulo MOD-02) · spec tagging CRM (módulo MOD-04).
- **Delegación:** Factory Builder + factorías de contenido existentes (editorial, video) vía contrato.

### EST-06 · Integración y Activación

- **Propósito:** conectar el kit a la infraestructura de ejecución — CRM (OneRocket en la instancia EL), taxonomía de tags, métricas de captura — y publicar.
- **Inputs:** componentes K2–K8 aprobados · spec de tagging.
- **Outputs:** kit activado en canales + mapa de tags operando.
- **Interfaces:** MCP del CRM · spec tagging (MOD-04).
- **Delegación:** Factory Builder + Ops.

### EST-07 · QA y Release

- **Propósito:** validar el kit completo contra el modelo QA (§6) y promoverlo.
- **Inputs:** kit candidato completo.
- **Outputs:** veredicto PASS/FAIL por check · entrada en Control Plane · release.
- **Interfaces:** tabla QA §6 · registry §7.
- **Delegación:** Factory Builder (ejecución) · Ratificador humano (promoción).

---

## 4. Registro de artefactos del dominio

| Artefacto | Prefijo sugerido | Estación origen | Contrato mínimo |
|-----------|------------------|------------------|-----------------|
| Manifiesto del Kit | KIT- | EST-07 | ID, producto, modalidad (B2C/B2O/B2B), estado de los 8 componentes, tripleta |
| Dossier de inteligencia | ANA-/RES- | EST-01 | Fuentes, contraste vault, claims verificados |
| Configuración BrainX del kit | BX- | EST-01 | Brain Codes incluidos + roles, versión |
| Offer Canvas | OFC- | EST-02 | Per [[FM-EL-OfertaIrresistible-v01]] §4, gates G1–G5 |
| Spec de producto (K1) | SPEC- | EST-03 | Definición, mecanismo nombrado, escalera, entrega |
| Narrativa maestra | NAR- | EST-04 | Mensajes por fase journey, lenguaje cliente, hooks |
| Landing (K2) | LP- | EST-05 | 9 bloques (FM §1 Fase 5.3), CTA, oferta visible |
| Guion video corto (K3) | VC- | EST-05 | Hook-Story-Offer, 1–3 min |
| Guion video largo (K4) | VL- | EST-05 | Educación + future pacing, 15–45 min |
| Paper (K5) | PP- | EST-05 | Nombrar problema + costo de no actuar |
| Whitepaper (K6) | WP- | EST-05 | Problema a fondo + solución + evidencia |
| Paquete MPI (K7) | MPI- | EST-05 | Contenido + prompt modalidad Sherpa + Q&A pack + tag map |
| Paquete de posts (K8) | POSTS- | EST-05 | Serie mapeada a journey y canales |
| Mapa de tags CRM | TAGMAP- | EST-06 | Taxonomía de tags + triggers + campos |

Todo artefacto lleva Asset ID con naming canónico `TIPO-ENTIDAD-Proyecto-Nombre-vNN`, tripleta Owner + Sherpa + Ratificador, y se versiona — nunca in-place.

---

## 5. Registro de módulos del dominio

| Módulo | Estado | Define |
|--------|--------|--------|
| MOD-01 · Oferta Irresistible | ✅ [[FM-EL-OfertaIrresistible-v01]] (Draft) | Construcción y validación de la oferta; schema Offer Canvas |
| MOD-02 · Modalidad MPI del Sherpa | ❌ Pendiente — spec a producir | Cómo opera un Sherpa IA en modalidad MasterPlaybook Inteligente: comportamiento, contexto, Q&A pack, validaciones |
| MOD-03 · Ensamblaje BrainX | ❌ Pendiente — spec a producir | Cómo se compone el BrainX de un kit a partir de Brain Codes (referencia: PP-XX-SX-SherpaXComoPlataforma-BrainX-v01) |
| MOD-04 · Integración CRM / Tagging | ❌ Pendiente — spec a producir | Taxonomía de tags, mapping de campos, triggers (instancia EL: OneRocket vía MCP HighLevel — referencia: DC-EL-GHL-EndpointsYMCP-v01) |
| MOD-05 · Metodología híbrida | 🟡 Parcial — FM §3 + MKT-EL-SX-PropuestaValor-B2O-v03 | Configuración B2C/B2O/B2B por variable de oferta y canal |
| MOD-06 · LoopX de Producción | ❌ Pendiente — spec a producir | Dashboard de seguimiento de producción de kits (distinto del BrainX Loop orbital de prospectos) |
| MOD-07 · Investigación de Mercado | ✅ [[FM-EL-MarketResearch-v01]] (Draft) | Playbook de 7 fases con 3 niveles (N1 Scan / N2 Standard / N3 Deep), configuración B2C/B2O/B2B y scorecard /50 como gate de salida de EST-01 |

Los módulos pendientes son los gaps formales del dominio; cada uno se produce como activo independiente y se registra aquí por referencia — **nunca se incrustan** en este documento.

## 5b. Registro de plantillas (referencias)

Las plantillas de cada artefacto (landing, guiones, paper, whitepaper, MPI, posts) se desarrollan en la primera instancia (FAC-EL) y se registran aquí por ID + versión al graduarse. Estado inicial: vacío — se puebla con el kit piloto.

---

## 6. Modelo QA del dominio

Extiende el QA estructural del MetaFactoryBuilder con checks de dominio:

| CHECK_ID | Categoría | Regla | Resultado |
|----------|-----------|-------|-----------|
| KD-S-01 | Estructura | Kit declara los 8 componentes y su estado | PASS / FAIL |
| KD-S-02 | Estructura | Todo artefacto con naming canónico + tripleta | PASS / FAIL |
| KD-I-00 | Inteligencia | Market research (MOD-07) con scorecard y decisión Advance | PASS / FAIL |
| KD-O-01 | Oferta | Offer Canvas existe y gates G1–G5 en PASS | PASS / FAIL |
| KD-O-02 | Oferta | Ningún componente producido antes del PASS de KD-O-01 | PASS / FAIL |
| KD-N-01 | Narrativa | Todos los componentes derivan de la narrativa maestra (sin copys huérfanos) | PASS / FAIL |
| KD-N-02 | Narrativa | Mapeo pain→pleasure respetado por componente | PASS / FAIL |
| KD-M-01 | MPI | Paquete MPI completo: contenido + prompt modalidad + Q&A + tag map | PASS / FAIL |
| KD-I-01 | Integración | Mapa de tags definido y probado contra el CRM | PASS / FAIL |
| KD-H-01 | Híbrido | Modalidad (B2C/B2O/B2B) declarada y configuración aplicada | PASS / FAIL |

Cualquier FAIL bloquea la promoción del kit. Sin overrides. Un gate que siempre da PASS no es un gate.

**Promoción:** Draft → QA_Pass → Hardened → Canonical. La promoción la ratifica el humano de la tripleta.

---

## 7. Hooks al Control Plane

Cada kit y cada instancia de factoría se registran:

- **Registry de la MetaFactoría:** MetaFactory ID (MF-BMF-DemandGenPack), versión, status, owner, QA status, dependencias upstream (FM Oferta, módulos MOD-01..06).
- **Registry de kits (por instancia):** Kit ID, producto, modalidad, estado por componente (K1–K8), estación actual, gates pasados, fechas. Este registry es la fuente de datos del **LoopX de Producción** (MOD-06).
- **ChangeLog:** todo cambio registra razón, alcance, impacto y versión.
- **Idea Bank:** las innovaciones detectadas durante producción de kits entran vía ANA- al CP-EL-IdeaBank.

---

## 8. Contratos de delegación (a Factory Builder)

L2 declara qué debe existir; L1/instancia define cómo se instancia.

| Contrato | Estación | El Factory Builder debe definir |
|----------|----------|--------------------------------|
| DEL-01 | EST-01 | Fuentes y herramientas de research; proceso de ensamblaje BrainX local |
| DEL-02 | EST-02 | Operador de la FM Oferta (humano+Sherpa); cadencia de revisión de gates |
| DEL-03 | EST-04/05 | Plantillas por componente; sub-delegación a factorías de contenido existentes (editorial/video) |
| DEL-04 | EST-06 | CRM concreto, credenciales MCP, taxonomía de tags local |
| DEL-05 | EST-07 | Roster de QA; ratificador por kit |

**Primera instancia:** FAC-EL-DemandGenPack-v01 (Factoría de Kits de EmpowerLabs) — kit piloto: **EmpowerScan · "Eliminando Costos Ocultos en la Era de la IA"** (modalidad B2O).

---

## 9. Fronteras y fuera de alcance

- ❌ Procedimientos paso a paso, prompts y tácticas — viven en módulos, plantillas y runbooks de instancia.
- ❌ Operación diaria de campañas, cadencia, manejo de defectos — capa Ops.
- ❌ El sistema de demanda completo (journey, conversion ladder, evidence engine) — dominio de MF-BMF-HybridDemand.
- ❌ Gestión orbital de prospectos — dominio del BrainX Loop.
- ❌ Decisiones de pricing final y de inversión — escalan al Owner siempre.

---

## CHANGELOG

| Versión | Fecha | Razón / alcance / impacto |
|---------|-------|---------------------------|
| v01.1 | 2026-06-11 | Se registra MOD-07 (FM-EL-MarketResearch) y se endurece EST-01: scorecard /50 como gate de salida + check KD-I-00. Origen: crítica de Victor al análisis de mercado del primer dossier |
| v01 | 2026-06-10 | Creación. Blueprint Type D (L2) de la MetaFactoría de DemandGenPack conforme a MePB-BMF-MetaFactoryBuilder-v01: definición canónica del Kit (8 componentes), 7 arquetipos de estación, registros de artefactos/módulos/plantillas, QA de dominio (9 checks), hooks al Control Plane y 5 contratos de delegación. Posicionada como par e interfaz de HybridDemand y GTM (no derivada). Draft — pendiente ratificación Victor |