---
type: MPB — Playbook operativo
asset_id: MPB-EL-DEMANDGEN-VCM-Playbook-v01
version: v01
status: 🟡 Borrador para ratificación L3 de Victor — incluye auditoría del modelo de medición y rúbrica corregida IPV v1.1
owner: Victor Heredia
sherpa_owner: Jay (Fable 5 · Room Puesta en Marcha GTM — cerebro estratégico de la VCM)
ratificador: Victor Heredia (L3)
fecha_creacion: 2026-07-21
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-DEMANDGEN-EmpowerLabs
proposito: >
  Playbook operativo de la Viral Content Machine (VCM): valida y corrige el modelo de medición
  (IPV), fija la rúbrica IPV v1.1 con anclas de puntuación, define el protocolo de calibración
  con datos reales de producción y gobierna el versionado del modelo. Es el documento que el
  room de producción VCM carga como contexto 7 (por diseño del TP v02) y que el Room GTM
  actualiza con cada ciclo de calibración.
referencias_canonicas:
  - TP-EL-DEMANDGEN-ViralContentMachine-Arranque-v02 (el room que este playbook gobierna)
  - DC-EL-DEMANDGEN-BancoFrames-v01 (V1-V9 + los 8 posts de referencia — fuente de las anclas)
  - DC-EL-DEMANDGEN-SistemaFramesFormatos-v01 (F1-F11 · máquina semanal · regla de medición Walker)
  - DC-EL-DEMANDGEN-NarrativaMadre-Inteligencia-v01 (dossier [A]/[B] · reglas editoriales §9)
  - DC-EL-DEMANDGEN-B2BViralFormula-Fuente-v01 (hookpoints · mirror test · iteration engine)
  - PLAN-EL-DEMANDGEN-Campana25Posts-ArranqueFase1-v02 (series y slots donde aterrizan las ideas)
tags: [MPB, playbook, VCM, IPV, medicion, calibracion, demandgen, ideacion]
---

# Playbook VCM v01 — El modelo de medición, validado
## Auditoría del IPV v01 · rúbrica IPV v1.1 · protocolo de calibración con producción

> **En una línea:** el IPV no es una verdad — es una **hipótesis de medición** que se calibra con datos reales del room de producción. Este playbook corrige lo que la auditoría encontró, ancla la puntuación para que dos corridas den el mismo score, y monta el loop que compara IPV predicho contra señal real cada domingo. Doctrina Walker aplicada al propio instrumento: *primero se valida el sistema de medición, luego se escala la táctica.*

---

## §1 · Auditoría del modelo IPV v01 (hallazgos)

### H1 · Bug aritmético en la normalización — CRÍTICO, corregido en §2

Los pesos de la rúbrica v01 suman **9.5** (2+2+2+1.5+1+1), por lo que el máximo ponderado real es **47.5 puntos** — no los 42.5 que declara la tabla. Consecuencias de la fórmula v01 (`/42.5 → ×2.35`): una idea fuerte puede dar **IPV 111/100**, y el umbral de fast-track se alcanza ~12 puntos antes de lo diseñado (inflación sistemática de scores: una idea "sin evidencia pero perfecta en lo demás" da 99.9 cuando su valor real es 89.5). **Corrección: IPV = (total ponderado / 47.5) × 100.** Los umbrales (≥70 / 50-69 / <50) no cambian — con la fórmula corregida vuelven a significar lo que se diseñó.

### H2 · El score compensa la falta de evidencia — se agrega segundo gate

Con la v01, una idea con **evidencia 0** puede llegar a IPV 89 y entrar al fast-track. Eso contradice la regla editorial #1 de la narrativa (cero cifras sin fuente) en el peor momento: el lote que va directo a producción. **Corrección (§2): el fast-track exige evidencia ≥3 o marca ⏳-BLOQUEADA** — la idea conserva su score y su lugar en el banco, pero no puede enviarse a factoría hasta que el dato se verifique contra el dossier. El gate de ICP (fit <3 = descarte) se mantiene intacto: sigue siendo el único descarte automático.

### H3 · El criterio "Evidencia" castiga a las ideas que no necesitan cifras

Una historia personal (V6, F7) o un detrás de cámaras (F4) no requieren dossier — con la v01 pierden hasta 5 puntos ponderados por un criterio que no les aplica. **Corrección: el criterio se re-define como "evidencia disponible *relativa a la necesidad*"** — una idea que no requiere cifras y no las usa puntúa 5; la que las requiere puntúa según el tier disponible (ancla en §2).

### H4 · Falta la dimensión temporal — se agrega campo, no criterio

El PLAN (regla 0.4.2) da a la actualidad "derecho de paso", pero el banco se ordena solo por IPV: una idea ligada a una noticia caliente puede morir esperando su turno detrás de evergreens con mejor score. **Corrección: campo `Caducidad` obligatorio en la ficha** (evergreen / fecha límite) + regla de banco: en la revisión dominical, las ideas con caducidad próxima se evalúan primero aunque su IPV sea menor. No se agrega como 7º criterio para no diluir la rúbrica — es una regla de ordenamiento, no de calidad.

### H5 · Sin anclas, el scorer comprime — se anclan los 6 criterios

Un calificador (humano o IA) sin anclas tiende a puntuar todo entre 3 y 4, y la rúbrica pierde poder de discriminación justo donde decide (fast-track vs banco). **Corrección: anclas 0/3/5 por criterio (§2), tomadas de los 8 posts de referencia del Banco de Frames** — ejemplos reales, ya analizados, con números.

### H6 · El modelo predice pero no aprende — se monta el loop de calibración

La v01 califica ideas y ahí termina: nada compara el IPV predicho con la señal real cuando la pieza se publica. Es el único punto donde la VCM contradecía la doctrina dominante del board (Walker: el sistema de medición se valida con datos, no con opinión) y el iteration engine del libro de Victor (cap. 6: velocidad de feedback > volumen). **Corrección: protocolo de calibración (§3)** — el loop que convierte cada publicación en un dato de entrenamiento del modelo.

### Lo que la auditoría VALIDÓ (no se toca)

El diseño de fondo es sólido: **el gate de ICP como descarte automático** es Walker puro y es la diferencia entre una máquina de demanda y una de vanidad; **propiedad ×1.5 + regla de desempate propietario** implementa bien el mandato Priestley de Victor (el contenedor es la marca) sin sobre-castigar ideas sueltas buenas; **la estructura 6 criterios / 3 bandas** es operable en volumen; y **el test de propiedad como filtro previo al score** evita gastar scoring en re-empaques. Los pesos relativos (viralidad 42% · demanda 37% · factibilidad 21%) son una hipótesis razonable para arrancar — se recalibran con datos en §3, no con debate.

## §2 · Rúbrica IPV v1.1 (vigente al ratificarse este playbook)

**Fórmula: IPV = (Σ puntos×peso / 47.5) × 100, redondeado.** Bandas: **≥70 fast-track** (raw ≥33.25) · **50-69 banco** (raw ≥23.75) · **<50 descartar o reformular**. Gates: **fit <3 = descarte automático** · **fast-track con evidencia <3 = ⏳-BLOQUEADA hasta verificar**.

| Criterio | Peso | Ancla 0 | Ancla 3 | Ancla 5 |
|---|---|---|---|---|
| **Hook** (patrón de interrupción) | ×2 | Abre con contexto/credenciales ("Hoy quiero hablar de…") — el caso Roldán: contenido correcto, 51 reacciones | Promesa clara sin ruptura de patrón ("Cómo medir tu brecha de IA") | Ruptura + especificidad al estilo Hills/Arosa pero anti-VOX: el dato radical real hace el trabajo de la hipérbole ("275 interrupciones/día") |
| **Psicología de compartido** | ×2 | Institucional: se comparte por compromiso, no por identidad | Utilidad pura: se guarda, se comparte poco (checklist sin voz) | Le da voz al lector frente a su jefe/red (V1-V3) o lo hace ver inteligente al compartir (cápsula por capas — 55 reposts con 290 reacciones) |
| **Fit ICP/escalera** ⚠️ GATE | ×2 | Audiencia de creators/growth-hacking — el nicho de Arosa, no el nuestro | Directivos sí, pero conexión débil con IBX→EScan→WORX o el espejo personal | Directivo/comprador + aterriza natural en un peldaño de la escalera o en una serie viva (🩻🧠🎙). **<3 = descarte, el score no lo salva** |
| **Propiedad/branding** | ×1.5 | Re-empaque con maquillaje — falla el test de propiedad | Capa de valor propia (dato del dossier, lente de inteligencia org.) sin contenedor propietario | Alimenta un contenedor propietario vivo (Radiografía, Tarjetas, Colección, Antología, serie firma) Y solo EL pudo publicarla |
| **Evidencia disponible** (relativa a la necesidad) | ×1 | Requiere cifras que no existen en el dossier ni son verificables | Requiere cifras: hay [B], o [A] parcial; ó no requiere cifras pero gana mucho con una que hay que buscar (⏳ máx 3) | El dato está en el dossier [A] — o la idea **no requiere cifras** (V6/F7 historia, F4 dogfooding) |
| **Costo de producción** | ×1 | Requiere construir capacidad nueva (video producido, herramienta web compleja) | Factoría existente con esfuerzo extra o dependencia de terceros | Lo produce una factoría existente esta semana (carousel→Producción, infografía→ux-diseno, texto→directo) |

**Campos nuevos obligatorios en la ficha (se suman al formato §4 del TP):** `Modelo: IPV v1.1` · `Caducidad: [evergreen | límite AAAA-MM-DD + por qué]`. **Desempates** (scores iguales, en orden): 1º propietario le gana a suelto (regla 5 del TP) · 2º caducidad próxima le gana a evergreen · 3º menor costo de producción.

## §3 · Protocolo de calibración (el loop que valida el modelo con datos)

**Fase A · Set de calibración (primeras ~20 fichas del room de producción).** Con el primer lote completo, el Room GTM revisa la **distribución**: si >40% cae en fast-track, los umbrales o las anclas están blandos; si <10% pasa de banco, están duros; si un criterio puntúa casi igual en todas las fichas, no discrimina y es candidato a re-anclarse o re-ponderarse. Este chequeo es sobre la RÚBRICA, no sobre las ideas.

**Fase B · Predicho vs. observado (cada domingo, dentro de la revisión GTM).** Para cada idea de la VCM ya publicada, se registra en el banco junto a su IPV: **comentarios sustantivos · guardados · DMs recibidos · reposts · menciones en "¿cómo supiste de nosotros?"** (las señales HIRO del sistema — no likes, no impresiones). Regla de lectura por terciles: si las ideas de IPV alto no superan consistentemente a las de IPV medio en señal real tras **≥6 publicaciones**, el modelo tiene un criterio mal ponderado — se identifica cuál (viendo qué criterio separa a las que sí funcionaron) y se propone el ajuste.

**Fase C · Versionado del modelo.** Los ajustes de pesos/anclas/umbrales se acumulan y se liberan como **IPV v1.2, v1.3…** en una actualización de ESTE playbook (nunca editando el TP del room ni la rúbrica en caliente — regla inviolable 7 del TP v02). Al liberarse una versión: el room de producción **re-scorea solo banco y fast-track no enviados** (lo enviado a producción no se toca), marca la versión en cada ficha y lo anota en el changelog del banco. Cambiar **una variable a la vez** (iteration engine, cap. 6): un release ajusta pesos O anclas O umbrales — no todo junto, o no se sabrá qué movió la aguja.

**Fase D · Insumo del room gemelo.** La sección `## Feedback al modelo (para Room GTM)` del banco (protocolo §8 del TP v02) se lee ANTES de cada release: la fricción operativa reportada por producción es evidencia de primera mano sobre la rúbrica. Nada de ese feedback se aplica directo — se formaliza aquí.

## §4 · El proceso de la máquina (sin cambios de fondo — referencia)

El proceso de 6 pasos (INGESTA → ANÁLISIS con vocabulario del Banco de Frames → IDEACIÓN 2-5 derivadas con test de propiedad → SCORE → FICHA → BANCO) y las 8 reglas inviolables viven en el **TP v02** y no se duplican aquí. Este playbook solo modifica: la fórmula y anclas del score (§2), los 2 campos nuevos de la ficha (§2) y el ciclo de calibración (§3). Jerarquía documental: el TP arranca el room; este playbook gobierna el MODELO; el banco registra la operación.

## §5 · Gobernanza del modelo

| Decisión | Quién | Nivel |
|---|---|---|
| Ajustar pesos, anclas, umbrales, gates del IPV | Room GTM propone (con datos de §3) | Victor ratifica (L3) |
| Re-scorear el banco tras un release | Room de producción VCM | L0 (mecánico, con la versión nueva) |
| Descartar una idea por gate de ICP | Room de producción VCM | L0 (automático por diseño) |
| Publicar/producir una idea ⏳-BLOQUEADA | Nadie — se desbloquea solo verificando el dato | — |
| Retirar o agregar un criterio a la rúbrica | Room GTM + Victor | L3 |

## §6 · NEXTs

- [ ] **Victor (L3):** ratificar este playbook — en particular la fórmula corregida (§2), el gate de evidencia para fast-track (H2) y el protocolo de calibración (§3).
- [ ] **Room de producción VCM:** al ratificarse, cargar este playbook como contexto 7 (el TP v02 ya lo busca por `*VCM-Playbook*`), adoptar IPV v1.1 y re-scorear las fichas que existan en banco con la fórmula corregida.
- [ ] **Jay:** primer chequeo de calibración (Fase A) cuando el banco llegue a ~20 fichas; primer predicho-vs-observado el domingo siguiente a las primeras publicaciones de ideas VCM.
- [ ] **Jay:** registrar en el Banco de Frames los frames nuevos que la VCM descubra y sobrevivan calibración (regla del banco: entra con evidencia).

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-21 | Creación (Room GTM, gemelo cerebro de la VCM). **Auditoría del IPV v01 con 6 hallazgos:** H1 bug aritmético en la normalización (pesos suman 9.5 → máx real 47.5, no 42.5; la fórmula ×2.35 permitía IPV 111/100 e inflaba ~12 pts el fast-track — verificado programáticamente), H2 fast-track alcanzable sin evidencia → gate ⏳-BLOQUEADA, H3 evidencia castigaba ideas que no requieren cifras → criterio relativo a la necesidad, H4 sin dimensión temporal → campo Caducidad + regla de ordenamiento, H5 sin anclas el scorer comprime → anclas 0/3/5 desde los 8 posts de referencia, H6 el modelo no aprendía → protocolo de calibración en 4 fases (set de ~20, predicho-vs-observado dominical con señales HIRO, versionado una-variable-a-la-vez, insumo del feedback del room gemelo). Validado lo que se queda: gate ICP, propiedad ×1.5 + desempate propietario, estructura 6 criterios/3 bandas, pesos iniciales como hipótesis. **Rúbrica IPV v1.1** con fórmula /47.5 y tabla de gobernanza del modelo. | Jay (Fable 5) |