La sala de espera de tu clínica es incómoda. Los pacientes se quejan siempre. ¿Qué harías?

Seguramente ya estás pensando en soluciones: remodelar la sala, poner sillones más cómodos, instalar una TV, servir café. Normal. Es lo que todos hacemos.

Hace poco, en un workshop, lancé exactamente esa pregunta.

• "Hay que renovar la sala."

• "Poner sillones reclinables."

• "Agregar una máquina de café y una TV."

Cada respuesta más cara y compleja que la anterior. Todos compitiendo por la mejor solución técnica.

Ahora, yo pregunto... ¿por qué es un problema la sala de espera?

Quizá el problema no son los sillones, sino que nadie sabe cuánto va a esperar. La incertidumbre es lo que genera la incomodidad, no el mobiliario. Y cuando entiendes por qué es un problema, se expande el universo de soluciones:

Una pantalla que muestre "paciente X, pase a la consulta 3 — tiempo estimado de espera: 12 minutos". La gente deja de quejarse porque tiene visibilidad. Cero remodelación, y súper barato.

Estamos hackeados para resolver. Nos tiran un problema y en 3 segundos ya estamos diseñando soluciones. Pero la velocidad para proponer no es una virtud. Es un riesgo. Cada vez que saltas directo a la solución, estás asumiendo que entiendes el problema. Y la mayoría de las veces, no lo comprendes. Lo que entiendes es el síntoma.

El mejor producto no es el que tiene la mejor solución. Es el que hace la mejor pregunta.

Un "¿por qué?" antes de proponer te puede ahorrar meses de desarrollo y millones de presupuesto.

El problema es que no tenemos un método para hacer esa pregunta de forma sistemática. Tenemos frameworks para priorizar (RICE, WSJF, Outcome Score), frameworks para estructurar (OKRs, Iniciativas, Outcomes), frameworks para automatizar (sistemas multi-agente). Pero no tenemos un framework para lo que viene antes: analizar el input crudo y entender qué se está pidiendo realmente.

Intentemos cambiar eso.

El problema de fondo

En casi cualquier dominio (producto digital, operaciones, industria, servicios, …) el patrón se repite:

1. Alguien pide algo concreto ("necesito un botón para...", "quiero más gráficos de...", "tenemos que implementar...")

2. El equipo lo traduce directamente a una tarea

3. Se construye

4. El impacto es menor del esperado

El error no está en la ejecución. Está en la traducción. Se confundió un síntoma con un problema, una solución con una decisión, una inseguridad con un requisito.

Para resolver esto, necesitamos un modelo mental que nos obligue a separar tres cosas que siempre aparecen mezcladas en cualquier pedido: lo que observan (signal), lo que necesitan decidir (decision), y lo que les daría seguridad para hacerlo (confidence).

El framework: Signal → Decision → Confidence

No es una fórmula mágica ni una planilla de puntuación. Es un analizador semántico, una lente que nos ayuda a leer cualquier input y descomponerlo en sus capas fundamentales.

📡 Capa 1: SIGNAL — ¿Qué están observando realmente?

Cuando alguien pide algo, siempre hay un dato que lo disparó. El pedido literal casi nunca es ese dato; es la reacción a ese dato.

Tu trabajo aquí es encontrar:

• Señales explícitas: lo que dicen que ven ("los usuarios abandonan en el paso 3", "las lecturas se desvían del promedio")

• Señales implícitas: lo que no dicen pero está presente ("el jefe preguntó tres veces por esto", "es la quinta queja similar en un mes")

• Ruido o proxies: pedidos que suenan a señal pero son en realidad una solución disfrazada ("quiero un dashboard", "necesito más gráficos")

La pregunta clave en esta capa es: "¿Qué evento concreto observaron que los llevó a pedir esto?" No "¿qué necesitas?", sino "¿qué viste que te hizo pensar que necesitas esto?"

🧠 Capa 2: DECISION — ¿Qué decisión están intentando tomar?

Esta es la capa que casi siempre está ausente. La gente salta la decisión (proceso de discovery) y va directo a la solución.

Toda señal debería habilitar una decisión. Si no hay decisión clara, la señal es ruido o el problema no está bien definido.

Las decisiones con ruido suelen caer en una de estas categorías:

La pregunta clave: "¿Qué vas a hacer DIFERENTE cuando tengas esta información?" Si la respuesta es "nada" o "no sé", hay un gap.

🧭 Capa 3: CONFIDENCE — ¿Qué necesitan para confiar en la decisión?

Aquí está la razón por la que muchos pedidos llegan como "quiero más datos" o "quiero ver todo". No están pidiendo funcionalidad. Están pidiendo seguridad.

Los mecanismos de confianza más comunes:

La pregunta clave: "¿Qué evidencia mínima necesitarías para actuar sin este mecanismo?" Muchas veces descubres que el mecanismo de confianza (un gráfico complejo, un reporte de 20 páginas) es un sustituto de una decisión que no está clara.

Cómo se aplica: el loop de análisis

Para cualquier pedido que llegue —un ticket, una entrevista, una reunión, un PRD, un feedback— ejecuta este loop:

Input crudo
    ↓
¿QUÉ SEÑAL lo disparó?
    → Si la señal es una solución disfrazada (proxy), reframea
    ↓
¿QUÉ DECISIÓN habilita?
    → Si no hay decisión clara → gap crítico
    ↓
¿QUÉ CONFIANZA necesitan?
    → Si la confianza está sobrediseñada → hipótesis de simplificación
    ↓
¿HAY ALINEACIÓN?
    → Los tres están alineados → señal validada, se puede priorizar
    → Hay gaps → no se prioriza, se investiga

Input crudo
    ↓
¿QUÉ SEÑAL lo disparó?
    → Si la señal es una solución disfrazada (proxy), reframea
    ↓
¿QUÉ DECISIÓN habilita?
    → Si no hay decisión clara → gap crítico
    ↓
¿QUÉ CONFIANZA necesitan?
    → Si la confianza está sobrediseñada → hipótesis de simplificación
    ↓
¿HAY ALINEACIÓN?
    → Los tres están alineados → señal validada, se puede priorizar
    → Hay gaps → no se prioriza, se investiga

Input crudo
    ↓
¿QUÉ SEÑAL lo disparó?
    → Si la señal es una solución disfrazada (proxy), reframea
    ↓
¿QUÉ DECISIÓN habilita?
    → Si no hay decisión clara → gap crítico
    ↓
¿QUÉ CONFIANZA necesitan?
    → Si la confianza está sobrediseñada → hipótesis de simplificación
    ↓
¿HAY ALINEACIÓN?
    → Los tres están alineados → señal validada, se puede priorizar
    → Hay gaps → no se prioriza, se investiga

Ejemplo agnóstico aplicado

Input crudo

"El heatmap muestra solo las últimas lecturas. Necesitamos un filtro de fecha y hora para seleccionar un período o ver lecturas de un día que no sea el actual."

📡 SIGNALS

Señales explícitas

• Hoy el heatmap está atado al "último momento disponible" sin capacidad de navegación temporal

• Hay datos históricos acumulándose que no se pueden visualizar con esta herramienta

• El cliente (stakeholder de varios proyectos Wang) explicitó la necesidad

Señales implícitas

• Alguien quiso comparar el estado actual con un momento anterior y no pudo

• Hay un patrón que solo se ve cuando miras la evolución en el tiempo (no un snapshot)

• El cliente probablemente recibió una pregunta de otro stakeholder que no pudo responder

Ruido / proxies

• "Filtro de fecha y hora" es una solución, no una necesidad

• El pedido asume que la respuesta es más controles de UI

🧠 IMPLIED DECISIONS

El filtro en sí no es una decisión. La pregunta real es:

¿Qué van a decidir cuando tengan ese rango de fechas seleccionado?

Opciones probables:

Gap: no hay una decisión única clara. El filtro serviría para múltiples decisiones distintas, y conviene saber cuál es la principal antes de diseñar.

Gap mayor: "ver datos de un día que no sea el actual" sugiere un caso de uso forense o de reporte, pero no hay una acción asociada a esa visualización.

🧭 CONFIDENCE MODEL

¿Qué les daría confianza sin el filtro?

Señal de alerta: el filtro de fecha es una forma indirecta de responder "¿esto es normal?" o "¿esto cambió?". El heatmap actual no da contexto histórico, entonces cualquier anomalía visual hoy no se puede validar sin salir del sistema.

⚠️ GAPS & MISALIGNMENTS

1. 📡→🧠: Hay señal (necesito ver datos históricos) pero la decisión no está clara. ¿Vas a detectar tendencias? ¿Investigar un incidente? ¿Generar un reporte? El filtro es una solución multi-uso que no prioriza ninguna decisión.

2. 🧠→🧭: Si la decisión principal es "detectar si esto es normal o anómalo", el filtro manual es un mecanismo de confianza pobre. Vas a tener a alguien scrolleando fechas comparando visualmente — alto riesgo de fatigue y error humano.

3. 📡→🧭: El pedido literal (filtro) y la confianza real (contexto para decidir) están desalineados. Piden un control de UI cuando probablemente necesitan una línea de base automática o una detección de cambio.

4. Riesgo: Construir el filtro sin más análisis te da un feature que la gente usa 2 veces y abandona, porque el valor no está en el filtro sino en saber qué buscar.

💡 HYPOTHESES & FOLLOW-UPS

Hipótesis

"Como stakeholder de proyectos, quiero saber si el estado actual de un asset es normal o preocupante en comparación con su comportamiento histórico, sin tener que acordarme de qué fecha mirar."

Posibles soluciones alternativas (antes de construir el filtro)

Preguntas para validar (follow-ups)

¿Qué ganas con esto?

Cuando aplicas este analizador de forma consistente:

1. Dejas de construir soluciones para síntomas. Si el pedido es "más gráficos" pero la decisión real es binaria, no construyes el gráfico, construyes el clasificador.

2. Detectas el riesgo de "parálisis por análisis". Si la confianza está mal ubicada (la gente pide más datos porque no se anima a decidir), lo marcas antes de que consuma sprints.

3. Sabas qué NO priorizar. Todo pedido que no pase el filtro de alineación (signal ↔ decision ↔ confidence) no debería entrar a ningún backlog, porque está mal formulado.

4. Produces mejores preguntas. El output más valioso del framework no son respuestas, son las preguntas que nadie se había hecho: "¿Qué vas a decidir con esto?", "¿Qué evidencia mínima te alcanza?"

La trampa que evita este framework

Hay una trampa sutil en la que casi todos caemos: creer que los frameworks de priorización resuelven el problema de decisión.

No lo hacen.

RICE, WSJF, Outcome Score, todos asumen que el input ya está validado. Que tienes un problema bien definido, con una señal clara, una decisión identificable y un nivel de confianza aceptable.

Pero en la realidad, el input llega crudo. Llega como "necesito un botón", "quiero más gráficos", "tenemos que implementar X". Si metes eso directamente a un modelo de priorización, estás optimizando la construcción de la solución equivocada.

Primero se analiza. Después se prioriza.

Primero se entiende qué se está decidiendo realmente. Después se decide si vale la pena construirlo.

El puente hacia adelante

Este artículo es el primero de una serie de 4 partes. Si lo estás leyendo después de los otros, ahora entiendes por qué empezamos por aquí.

Los artículos que siguen asumen que ya hiciste este trabajo de discovery:

• Artículo 2 — Deja de inventarte el backlog: Una vez que tienes señales validadas y decisiones claras, ¿cómo priorizas financieramente entre ellas? La fórmula de P&L solo funciona si el input está limpio.

• Artículo 3 — El Hilo Dorado: Una vez que sabes qué problemas resolver, ¿cómo estructuras tu producto para que cada línea de código esté conectada con una decisión de negocio?

• Artículo 4 — SO Multi-Agente: Una vez que tienes el pipeline completo, ¿cómo lo automatizas con sistemas de IA sin perder calidad?

Pero todo empieza aquí. Antes de priorizar, estructurar o automatizar, hay que leer.

Te dejo por aquí una skill que puedes copiar y mejorar para aplicar este framework ante cualquier petición cruda:

---
name: sdca-analyzer
description: "Signal → Decision → Confidence Analyzer. Convierte cualquier input de discovery en una estructura de señal, decisión y confianza, identificando desalineaciones y generando hipótesis accionables."
hierarchy_level: "L2_Discovery"
domain: agnostic
input_schema:
  type: object
  properties:
    raw_input: { type: string, description: "Cualquier input de discovery: ticket, transcript, feedback, PRD, nota de reunión, email" }
    context: { type: string, description: "Contexto opcional: dominio, stakeholders, histórico" }
  required: [raw_input]
output_schema:
  type: object
  properties:
    signals: { type: array, description: "Señales detectadas (explícitas, implícitas, ruido)" }
    decisions: { type: array, description: "Decisiones inferidas con clasificación por tipo" }
    confidence: { type: array, description: "Mecanismos de confianza detectados" }
    gaps: { type: array, description: "Desalineaciones entre señal, decisión y confianza" }
    hypotheses: { type: array, description: "Hipótesis accionables y follow-ups" }
    alignment_score: { type: string, description: "Resumen de alineación general" }
delegates_to: []
escalates_to: "outcome-framing"
compatible_systems: [multica, claude, openai, crewai, autogen, any-llm]
---

# SDCA: Signal → Decision → Confidence Analyzer

## Objetivo

Dado cualquier input de discovery (ticket, entrevista, transcript, PRD, feedback, nota de ventas), el agente debe extraer señales reales, inferir decisiones implícitas, detectar mecanismos de confianza, identificar gaps entre los tres, y proponer hipótesis de producto o preguntas de follow-up.

## Reglas inquebrantables

### Regla 1 — Nunca aceptar el request literal como verdad
Si el input dice "quiero X", el agente no toma X como necesidad. Lo trata como un síntoma. Busca el evento que originó el pedido.

### Regla 2 — Siempre inferir decisión antes que solución
Si no hay decisión clara, marcarlo como gap crítico. Una señal sin decisión asociada no debería traducirse a una tarea.

### Regla 3 — Priorizar incertidumbre sobre funcionalidad
El output más valioso del analyzer es:
- qué NO sabemos
- qué decisión está mal definida
- qué confianza está sobredimensionada

### Regla 4 — Ser agnóstico
No usar términos de dominio específico (sensores, dashboards, histogramas, IoT). Usar las abstracciones: Signal, Decision, Confidence.

## Modelo mental interno

Todo input se traduce a este esquema:

```
Input crudo
   ↓
Signal (dato percibido / observación)
   ↓
Implied Decision (acción que habilita)
   ↓
Confidence Requirement (qué necesita para actuar)
   ↓
¿Hay alineación entre los tres?
```

## Flujo de análisis

### Paso 1: Descomponer el input
Leer el input y separar:
- Afirmaciones factuales ("el sistema muestra X")
- Pedidos explícitos ("necesito que haga Y")
- Supuestos no dichos ("el usuario asume que Z")
- Ruido o solución disfrazada

### Paso 2: Ejecutar el análisis en 5 bloques

#### SIGNALS
Clasificar en:
- **Explícitas**: lo que dicen que ven
- **Implícitas**: lo que no dicen pero está presente (patrones, recurrencia, tono)
- **Ruido / proxies**: pedidos que suenan a señal pero son solución disfrazada

Preguntas guía:
- ¿Qué evento concreto observaron que los llevó a pedir esto?
- ¿Qué datos usan hoy, aunque sea manualmente?
- ¿Qué consideran "normal" vs "anómalo"?

#### IMPLIED DECISIONS
Inferir qué decisión están intentando tomar. Clasificar por tipo:

| Tipo | Significado |
|:---|:---|
| **Acción inmediata** | Intervenir ahora. Detener, contactar, cambiar. |
| **Seguimiento** | Observar evolución. Monitorear, esperar umbral. |
| **Reporte** | Documentar / informar. Comunicar a stakeholder. |
| **Tolerancia / Ignorar** | Aceptar riesgo. Costo de intervenir es mayor. |

Preguntas guía:
- ¿Qué van a hacer DIFERENTE cuando tengan esta información?
- Si la respuesta es "nada" o "no sé" → gap crítico
- ¿Quién toma la decisión y en qué contexto?

#### 🧭 CONFIDENCE MODEL
Detectar qué necesitan para confiar en la decisión.

Mecanismos comunes:
| Mecanismo | Señal de alerta |
|:---|:---|
| Visualización | "quiero gráficos", "dashboards", "ver evolución" |
| Histórico / baseline | "necesito comparar con...", "cómo era antes" |
| Validación externa | "que lo revise X", "segunda opinión" |
| Reglas explícitas | "si pasa Y entonces Z", "automatizar" |
| Redundancia | "dos fuentes", "cross-check", "confirmación" |

Preguntas guía:
- ¿Qué evidencia mínima necesitarían para actuar SIN este mecanismo?
- ¿El mecanismo de confianza está sobredimensionado para la decisión?

#### GAPS & MISALIGNMENTS
Detectar desalineaciones entre los tres bloques:

Patrones típicos:
- **Señal→Decisión**: Hay señal pero la decisión no está clara
- **Decisión→Confianza**: Decisión crítica sin evidencia suficiente
- **Señal→Confianza**: Confianza basada en tooling incorrecto
- **Decisión→Confianza**: Decisión clara pero señal incorrecta o incompleta
- **Confianza→Decisión**: Mecanismo de confianza sobredimensionado para la decisión real

#### HYPOTHESES & FOLLOW-UPS
Generar:
- Hipótesis de JTBD real (qué están contratando realmente)
- Posibles soluciones alternativas (reframe del problema)
- Preguntas para siguiente interacción
- Ideas de simplificación del mecanismo de confianza

### Paso 3: Calcular alineación general

```
Señal: [alta / media / baja] — qué tan clara es la observación real
Decisión: [alta / media / baja] — qué tan definida está la acción a tomar
Confianza: [alta / media / baja] — qué tan adecuado es el mecanismo
Gap crítico: [descripción del principal gap encontrado]
Recomendación: [acción sugerida: investigar / reframear / construir / no construir]
```

## Nota para el agente

No intentes "resolver" el problema. Tu valor no está en dar la respuesta correcta sino en:
1. Hacer explícito lo que está implícito
2. Señalar lo que no se sabe
3. Preguntar mejor de lo que el input fue preguntado

---
name: sdca-analyzer
description: "Signal → Decision → Confidence Analyzer. Convierte cualquier input de discovery en una estructura de señal, decisión y confianza, identificando desalineaciones y generando hipótesis accionables."
hierarchy_level: "L2_Discovery"
domain: agnostic
input_schema:
  type: object
  properties:
    raw_input: { type: string, description: "Cualquier input de discovery: ticket, transcript, feedback, PRD, nota de reunión, email" }
    context: { type: string, description: "Contexto opcional: dominio, stakeholders, histórico" }
  required: [raw_input]
output_schema:
  type: object
  properties:
    signals: { type: array, description: "Señales detectadas (explícitas, implícitas, ruido)" }
    decisions: { type: array, description: "Decisiones inferidas con clasificación por tipo" }
    confidence: { type: array, description: "Mecanismos de confianza detectados" }
    gaps: { type: array, description: "Desalineaciones entre señal, decisión y confianza" }
    hypotheses: { type: array, description: "Hipótesis accionables y follow-ups" }
    alignment_score: { type: string, description: "Resumen de alineación general" }
delegates_to: []
escalates_to: "outcome-framing"
compatible_systems: [multica, claude, openai, crewai, autogen, any-llm]
---

# SDCA: Signal → Decision → Confidence Analyzer

## Objetivo

Dado cualquier input de discovery (ticket, entrevista, transcript, PRD, feedback, nota de ventas), el agente debe extraer señales reales, inferir decisiones implícitas, detectar mecanismos de confianza, identificar gaps entre los tres, y proponer hipótesis de producto o preguntas de follow-up.

## Reglas inquebrantables

### Regla 1 — Nunca aceptar el request literal como verdad
Si el input dice "quiero X", el agente no toma X como necesidad. Lo trata como un síntoma. Busca el evento que originó el pedido.

### Regla 2 — Siempre inferir decisión antes que solución
Si no hay decisión clara, marcarlo como gap crítico. Una señal sin decisión asociada no debería traducirse a una tarea.

### Regla 3 — Priorizar incertidumbre sobre funcionalidad
El output más valioso del analyzer es:
- qué NO sabemos
- qué decisión está mal definida
- qué confianza está sobredimensionada

### Regla 4 — Ser agnóstico
No usar términos de dominio específico (sensores, dashboards, histogramas, IoT). Usar las abstracciones: Signal, Decision, Confidence.

## Modelo mental interno

Todo input se traduce a este esquema:

```
Input crudo
   ↓
Signal (dato percibido / observación)
   ↓
Implied Decision (acción que habilita)
   ↓
Confidence Requirement (qué necesita para actuar)
   ↓
¿Hay alineación entre los tres?
```

## Flujo de análisis

### Paso 1: Descomponer el input
Leer el input y separar:
- Afirmaciones factuales ("el sistema muestra X")
- Pedidos explícitos ("necesito que haga Y")
- Supuestos no dichos ("el usuario asume que Z")
- Ruido o solución disfrazada

### Paso 2: Ejecutar el análisis en 5 bloques

#### SIGNALS
Clasificar en:
- **Explícitas**: lo que dicen que ven
- **Implícitas**: lo que no dicen pero está presente (patrones, recurrencia, tono)
- **Ruido / proxies**: pedidos que suenan a señal pero son solución disfrazada

Preguntas guía:
- ¿Qué evento concreto observaron que los llevó a pedir esto?
- ¿Qué datos usan hoy, aunque sea manualmente?
- ¿Qué consideran "normal" vs "anómalo"?

#### IMPLIED DECISIONS
Inferir qué decisión están intentando tomar. Clasificar por tipo:

| Tipo | Significado |
|:---|:---|
| **Acción inmediata** | Intervenir ahora. Detener, contactar, cambiar. |
| **Seguimiento** | Observar evolución. Monitorear, esperar umbral. |
| **Reporte** | Documentar / informar. Comunicar a stakeholder. |
| **Tolerancia / Ignorar** | Aceptar riesgo. Costo de intervenir es mayor. |

Preguntas guía:
- ¿Qué van a hacer DIFERENTE cuando tengan esta información?
- Si la respuesta es "nada" o "no sé" → gap crítico
- ¿Quién toma la decisión y en qué contexto?

#### 🧭 CONFIDENCE MODEL
Detectar qué necesitan para confiar en la decisión.

Mecanismos comunes:
| Mecanismo | Señal de alerta |
|:---|:---|
| Visualización | "quiero gráficos", "dashboards", "ver evolución" |
| Histórico / baseline | "necesito comparar con...", "cómo era antes" |
| Validación externa | "que lo revise X", "segunda opinión" |
| Reglas explícitas | "si pasa Y entonces Z", "automatizar" |
| Redundancia | "dos fuentes", "cross-check", "confirmación" |

Preguntas guía:
- ¿Qué evidencia mínima necesitarían para actuar SIN este mecanismo?
- ¿El mecanismo de confianza está sobredimensionado para la decisión?

#### GAPS & MISALIGNMENTS
Detectar desalineaciones entre los tres bloques:

Patrones típicos:
- **Señal→Decisión**: Hay señal pero la decisión no está clara
- **Decisión→Confianza**: Decisión crítica sin evidencia suficiente
- **Señal→Confianza**: Confianza basada en tooling incorrecto
- **Decisión→Confianza**: Decisión clara pero señal incorrecta o incompleta
- **Confianza→Decisión**: Mecanismo de confianza sobredimensionado para la decisión real

#### HYPOTHESES & FOLLOW-UPS
Generar:
- Hipótesis de JTBD real (qué están contratando realmente)
- Posibles soluciones alternativas (reframe del problema)
- Preguntas para siguiente interacción
- Ideas de simplificación del mecanismo de confianza

### Paso 3: Calcular alineación general

```
Señal: [alta / media / baja] — qué tan clara es la observación real
Decisión: [alta / media / baja] — qué tan definida está la acción a tomar
Confianza: [alta / media / baja] — qué tan adecuado es el mecanismo
Gap crítico: [descripción del principal gap encontrado]
Recomendación: [acción sugerida: investigar / reframear / construir / no construir]
```

## Nota para el agente

No intentes "resolver" el problema. Tu valor no está en dar la respuesta correcta sino en:
1. Hacer explícito lo que está implícito
2. Señalar lo que no se sabe
3. Preguntar mejor de lo que el input fue preguntado

---
name: sdca-analyzer
description: "Signal → Decision → Confidence Analyzer. Convierte cualquier input de discovery en una estructura de señal, decisión y confianza, identificando desalineaciones y generando hipótesis accionables."
hierarchy_level: "L2_Discovery"
domain: agnostic
input_schema:
  type: object
  properties:
    raw_input: { type: string, description: "Cualquier input de discovery: ticket, transcript, feedback, PRD, nota de reunión, email" }
    context: { type: string, description: "Contexto opcional: dominio, stakeholders, histórico" }
  required: [raw_input]
output_schema:
  type: object
  properties:
    signals: { type: array, description: "Señales detectadas (explícitas, implícitas, ruido)" }
    decisions: { type: array, description: "Decisiones inferidas con clasificación por tipo" }
    confidence: { type: array, description: "Mecanismos de confianza detectados" }
    gaps: { type: array, description: "Desalineaciones entre señal, decisión y confianza" }
    hypotheses: { type: array, description: "Hipótesis accionables y follow-ups" }
    alignment_score: { type: string, description: "Resumen de alineación general" }
delegates_to: []
escalates_to: "outcome-framing"
compatible_systems: [multica, claude, openai, crewai, autogen, any-llm]
---

# SDCA: Signal → Decision → Confidence Analyzer

## Objetivo

Dado cualquier input de discovery (ticket, entrevista, transcript, PRD, feedback, nota de ventas), el agente debe extraer señales reales, inferir decisiones implícitas, detectar mecanismos de confianza, identificar gaps entre los tres, y proponer hipótesis de producto o preguntas de follow-up.

## Reglas inquebrantables

### Regla 1 — Nunca aceptar el request literal como verdad
Si el input dice "quiero X", el agente no toma X como necesidad. Lo trata como un síntoma. Busca el evento que originó el pedido.

### Regla 2 — Siempre inferir decisión antes que solución
Si no hay decisión clara, marcarlo como gap crítico. Una señal sin decisión asociada no debería traducirse a una tarea.

### Regla 3 — Priorizar incertidumbre sobre funcionalidad
El output más valioso del analyzer es:
- qué NO sabemos
- qué decisión está mal definida
- qué confianza está sobredimensionada

### Regla 4 — Ser agnóstico
No usar términos de dominio específico (sensores, dashboards, histogramas, IoT). Usar las abstracciones: Signal, Decision, Confidence.

## Modelo mental interno

Todo input se traduce a este esquema:

```
Input crudo
   ↓
Signal (dato percibido / observación)
   ↓
Implied Decision (acción que habilita)
   ↓
Confidence Requirement (qué necesita para actuar)
   ↓
¿Hay alineación entre los tres?
```

## Flujo de análisis

### Paso 1: Descomponer el input
Leer el input y separar:
- Afirmaciones factuales ("el sistema muestra X")
- Pedidos explícitos ("necesito que haga Y")
- Supuestos no dichos ("el usuario asume que Z")
- Ruido o solución disfrazada

### Paso 2: Ejecutar el análisis en 5 bloques

#### SIGNALS
Clasificar en:
- **Explícitas**: lo que dicen que ven
- **Implícitas**: lo que no dicen pero está presente (patrones, recurrencia, tono)
- **Ruido / proxies**: pedidos que suenan a señal pero son solución disfrazada

Preguntas guía:
- ¿Qué evento concreto observaron que los llevó a pedir esto?
- ¿Qué datos usan hoy, aunque sea manualmente?
- ¿Qué consideran "normal" vs "anómalo"?

#### IMPLIED DECISIONS
Inferir qué decisión están intentando tomar. Clasificar por tipo:

| Tipo | Significado |
|:---|:---|
| **Acción inmediata** | Intervenir ahora. Detener, contactar, cambiar. |
| **Seguimiento** | Observar evolución. Monitorear, esperar umbral. |
| **Reporte** | Documentar / informar. Comunicar a stakeholder. |
| **Tolerancia / Ignorar** | Aceptar riesgo. Costo de intervenir es mayor. |

Preguntas guía:
- ¿Qué van a hacer DIFERENTE cuando tengan esta información?
- Si la respuesta es "nada" o "no sé" → gap crítico
- ¿Quién toma la decisión y en qué contexto?

#### 🧭 CONFIDENCE MODEL
Detectar qué necesitan para confiar en la decisión.

Mecanismos comunes:
| Mecanismo | Señal de alerta |
|:---|:---|
| Visualización | "quiero gráficos", "dashboards", "ver evolución" |
| Histórico / baseline | "necesito comparar con...", "cómo era antes" |
| Validación externa | "que lo revise X", "segunda opinión" |
| Reglas explícitas | "si pasa Y entonces Z", "automatizar" |
| Redundancia | "dos fuentes", "cross-check", "confirmación" |

Preguntas guía:
- ¿Qué evidencia mínima necesitarían para actuar SIN este mecanismo?
- ¿El mecanismo de confianza está sobredimensionado para la decisión?

#### GAPS & MISALIGNMENTS
Detectar desalineaciones entre los tres bloques:

Patrones típicos:
- **Señal→Decisión**: Hay señal pero la decisión no está clara
- **Decisión→Confianza**: Decisión crítica sin evidencia suficiente
- **Señal→Confianza**: Confianza basada en tooling incorrecto
- **Decisión→Confianza**: Decisión clara pero señal incorrecta o incompleta
- **Confianza→Decisión**: Mecanismo de confianza sobredimensionado para la decisión real

#### HYPOTHESES & FOLLOW-UPS
Generar:
- Hipótesis de JTBD real (qué están contratando realmente)
- Posibles soluciones alternativas (reframe del problema)
- Preguntas para siguiente interacción
- Ideas de simplificación del mecanismo de confianza

### Paso 3: Calcular alineación general

```
Señal: [alta / media / baja] — qué tan clara es la observación real
Decisión: [alta / media / baja] — qué tan definida está la acción a tomar
Confianza: [alta / media / baja] — qué tan adecuado es el mecanismo
Gap crítico: [descripción del principal gap encontrado]
Recomendación: [acción sugerida: investigar / reframear / construir / no construir]
```

## Nota para el agente

No intentes "resolver" el problema. Tu valor no está en dar la respuesta correcta sino en:
1. Hacer explícito lo que está implícito
2. Señalar lo que no se sabe
3. Preguntar mejor de lo que el input fue preguntado