# Premisas de Diseño — Protocolo IA-Socrático v2.0

**Instrumento formal de nivel 2 — fuente de verdad del diseño v2.0**  
**Fecha inicio:** 2026-05-16  
**Estado:** Cerrado — 39 decisiones consolidadas (2026-05-16)  
**Versión del documento:** 1.1

> **Cambios v1.0 → v1.1** (refactor de notación — IP, 2026-06-16):
> - Las 39 decisiones de diseño pasan de `D1`–`D39` a `DD_N` (`DD_1`–`DD_39`) para eliminar la colisión con las dimensiones `D1`–`D4` de la Rúbrica. *DD* = Decisión de Diseño. Las premisas `P1`–`P9` y el diseño v2.0 no cambian: es solo notación. Ver `doc_inv_Glosario_Conceptual` §"Convención de notación".
> - **Errata 2026-06-16 (IP):** en las notas de implementación de DD_18 y DD_38, las referencias a la pantalla del estudiante "Etapa 3" se renombran a `etapa_ui_est 3` para no colisionar con la columna BD `etapa` (`claseN:momento`); la referencia al flujo estudiante-plataforma se actualiza de v1.0 a v1.1. Sin cambio de diseño. Ver `doc_pro_Flujo_Estudiante_Plataforma_v1.1.md` §1.1.

---

## Premisas confirmadas por el IP

### P1 — Una sola IA, un solo sistema

Profesor y alumno usan el MISMO sistema/plataforma de IA (diseñado por Ángel Royo), pero con agentes diferentes (system prompts distintos por rol y por clase). No hay herramientas externas de IA (ni ChatGPT, ni Copilot, ni ninguna otra). Todo pasa por un único canal controlado con BD centralizada (PostgreSQL).

**Consecuencia:** La variable independiente del estudio es una sola. Las métricas vienen de un solo sistema. No hay confounding por múltiples herramientas. Los agentes diferentes permiten funcionalidades distintas (alumno: chatbot socrático/BUILD; profesor: dashboard + consultas a BD) sin perder centralización de datos.

### P2 — El sistema es propiedad del IP

El chatbot es "made in Angel Royo." Es un sistema propio, no una herramienta de terceros. Esto permite:
- Control total sobre los prompts
- Logging de todas las interacciones (métricas)
- Adaptabilidad por clase y por profesor (escalabilidad futura)

### P3 — Coexistencia, no prohibición

El protocolo NO prohíbe la IA. Enseña a COEXISTIR con ella. La clase ES sobre cómo usar IA de forma estructurada. El alumno aprende a usar IA mientras aprende el contenido técnico.

**Doble objetivo:** contenido técnico (máquinas/instrumentación) + competencia de uso de IA (saber pensar antes, saber preguntar, saber evaluar respuestas).

### P4 — Infraestructura de aula

- Máximo ~20 alumnos
- Un PC potente por alumno
- Pizarra + plumones + proyector (notebook del docente)
- Curso: Laboratorio de Máquinas y Equipos Industriales (14362-0-L-1)
- Sesiones de 80 minutos (08:15–09:35, viernes)

### P5 — Primero cerebro, después herramienta

La secuencia es inviolable: papel/pensamiento propio → chatbot socrático → implementación. La IA nunca llega antes que el pensamiento propio. Esto aplica tanto al alumno como al profesor.

### P6 — Trabajo individual

El piloto mide trayectoria individual. No hay trabajo grupal estructurado (por decisión del IP: "en grupo trabaja la mitad").

### P7 — El chatbot muta por clase

System prompts distintos por clase (agentes diferentes dentro de la misma plataforma):
- Clase 1: Socrático básico (línea base, solo Modelo A)
- Clase 2: PLAN socrático de diagnóstico + BUILD genera informe con errores obvios
- Clase 3: PLAN socrático de monitoreo + BUILD genera reporte con errores sutiles
- Clase 4: PLAN adversarial de control + BUILD genera protocolo con errores profesionales
- Clase 5: NEUTRO (no socrático, no presiona) — mide transferencia autónoma de metodología

BUILD defiende sus errores cuando el alumno los señala (DD_27). El alumno NO sabe que hay errores deliberados (DD_28).

### P8 — Escalabilidad a otros profesores

El sistema está diseñado para que OTROS profesores de la facultad puedan usarlo cambiando el prompt según su asignatura. El piloto con Máquinas y Equipos Industriales es la primera implementación, no la única posible.

---

### P9 — La clase NO es de contenido. Es un laboratorio de criterio.

El contenido técnico (sensores, SCADA, control) es el VEHÍCULO, no el objetivo. El alumno puede aprender contenido en YouTube + IA por su cuenta. Lo que NO puede obtener solo:

- Experiencia profesional real del docente (20 años como Gerente en Pyme chilena)
- Participación activa bajo presión social y temporal
- Confrontación en tiempo real ("¿y si falla a las 3 AM y tú eres el responsable?")
- Criterio profesional: distinguir cuándo la IA tiene razón y cuándo no

**El aporte del profesor:** no es el qué (contenido), es el cómo se piensa bajo presión real. El chatbot amplifica la presión cognitiva individualizada. El profesor aporta la experiencia que ninguna IA tiene.

**Consecuencia para el diseño:** minimizar entrega de contenido (eso va en material pre-clase o en el chatbot). Maximizar participación, defensa, decisión y confrontación en los 80 min presenciales.

---

## Preguntas abiertas (pendientes de resolución)

### Q1 — RESUELTA
~~Experiencia de programación de los alumnos~~
→ Tercer año de carrera de ~4.5 años. Programación básica (algunos). Tienen conceptos lógicos sólidos. NO son especialistas en instrumentación/control. Consecuencia para el diseño: todo material debe ser autocontenido (siglas explicadas entre paréntesis, conceptos nuevos con contexto). El chatbot puede asumir capacidad lógica pero no dominio técnico específico.

### Q2 — RESUELTA (parcialmente)
~~Fase digital: ¿dentro o fuera de los 80 min?~~
→ La clase tiene dos mitades: Modelo A (alumno produce, IA pregunta) + Modelo B (IA produce, alumno evalúa). No es "fase digital" sino "fase de evaluación de output de IA."

### Q3 — RESUELTA
~~Clase 5: ¿se mantiene congelada?~~
→ C5 NO es sin IA. El alumno SÍ tiene acceso al chatbot pero sin instrucción de cómo usarlo (ni Modelo A ni B explícito). Problema nuevo (torre de enfriamiento u otro). Se mide si reproduce autónomamente el protocolo aprendido: pensar primero, preguntar bien, evaluar críticamente. + Encuesta final de autopercepción. Coherente con P3 (coexistencia). Comparación C1 vs C5 válida: misma herramienta disponible, distinto nivel de competencia de uso. Ver DD_17.

### Q4 — RESUELTA
~~¿Qué hace el chatbot en la fase digital?~~
→ El chatbot tiene dos modos: PLAN (socrático, no genera) y BUILD (genera entregable con errores deliberados para que el alumno evalúe).

### Q5 — RESUELTA
~~¿El profesor también usa el chatbot en clase?~~
→ Sí, pero con agente diferente (DD_14). Mismo sistema/plataforma/BD, distinto system prompt. El agente del profesor es un lector de datos en tiempo real (dashboard + chat bajo demanda con ~5 preguntas sugeridas). No genera contenido proactivamente — da visibilidad para que el profesor decida intervenciones en persona.

### Q6 — RESUELTA
~~Plataforma del chatbot~~
→ Astro en Cloudflare (frontend) + n8n como orquestador (AI Agent, webhooks, schedulers) + PostgreSQL (BD centralizada). LLM pendiente de prueba empírica (DeepSeek, Sonnet u otro — criterio: costo + calidad socrática). Identificación por email USACH. Ver DD_15.

### Q7 — RESUELTA
~~¿Qué entregable produce el chatbot en modo BUILD?~~
→ Depende de la clase (DD_13): C2 informe de diagnóstico, C3 reporte de tendencias/alarmas, C4 protocolo de emergencia + justificación económica. Escalación doble en sutileza y complejidad documental.

### Q8 — RESUELTA
~~¿El feedback por WhatsApp lo genera la AGENT_ANALISTA_SFL automáticamente o el profesor lo revisa antes de enviar?~~
→ Automático, sin revisión. AGENT_SESION genera y envía dos feedbacks separados (invocando a AGENT_ANALISTA_SFL como motor SFL): al alumno (proceso) y al profesor (informe analítico). El profesor no revisa ni aprueba — recibe y usa como insumo para sus decisiones. Ver DD_16.

---

## Decisiones tomadas

> **Nota de nomenclatura:** Las decisiones `DD_1`–`DD_39` de este documento son **decisiones de arquitectura del protocolo** (qué se diseña y por qué; *DD* = Decisión de Diseño). No confundir con `D1`–`D4` de `doc_pro_Rubrica_Longitudinal`, que son **dimensiones de análisis del razonamiento** (complejidad causal, especificidad técnica, consciencia epistémica, decisión bajo incertidumbre). Desde 2026-06-16 las dos notaciones son distintas (`DD_N` para decisiones, `D1`–`D4` para dimensiones) para eliminar la colisión que existía cuando ambas usaban `D` + número.

| # | Decisión | Fecha | Motivo |
|---|----------|-------|--------|
| DD_1 | Una sola IA (chatbot socrático del IP) | 2026-05-16 | Limpieza metodológica + visión de producto propio |
| DD_2 | Trabajo individual | 2026-05-16 | Medición de trayectoria individual; grupos son ineficientes |
| DD_3 | El contenido técnico escala a nivel universitario (instrumentación, SCADA, control) | 2026-05-16 | v1.0 era nivel de colegio según el IP |
| DD_4 | Misma plataforma/BD, agentes diferentes (alumno y profesor) | 2026-05-16 | Un sistema centralizado (PostgreSQL), múltiples agentes con system prompts distintos por rol y por clase. Datos unificados para análisis. |
| DD_5 | Estructura de clase C2-C4: Modelo A (1ª mitad) + Modelo B (2ª mitad) | 2026-05-16 | A: alumno produce, IA pregunta. B: IA produce, alumno evalúa como ingeniero. |
| DD_6 | Modelo B usa Opción 1 (output personalizado por alumno) | 2026-05-16 | Cada alumno recibe output distinto según su instrucción. No se puede copiar. Previene deuda cognitiva de salida. |
| DD_7 | El chatbot tiene modos PLAN y BUILD | 2026-05-16 | PLAN: socrático, no genera. BUILD: genera según el plan del alumno (con imperfecciones deliberadas para evaluar). |
| DD_8 | Los errores del chatbot en BUILD escalan por clase | 2026-05-16 | C2: obvios. C3: sutiles. C4: profesionales (solo los ve quien tiene experiencia). |
| DD_9 | Todo se guarda en base de datos (con consentimiento) | 2026-05-16 | AGENT_ANALISTA_SFL puede codificar trayectorias, aplicar rúbrica, detectar patrones. |
| DD_10 | Feedback personalizado por WhatsApp después de cada clase | 2026-05-16 | Sobre PROCESO, nunca sobre resultado. "Tu razonamiento fue profundo en X pero vago en Y." |
| DD_11 | El feedback habla de proceso, no de correcto/incorrecto | 2026-05-16 | Evita que el alumno busque "la respuesta correcta"; incentiva razonar mejor, no adivinar mejor. |
| DD_12 | Intervención completa para el paper: chatbot socrático + feedback inter-sesión por IA | 2026-05-16 | Protocolo replicable y documentable como intervención única. |
| DD_13 | El entregable BUILD escala en tipo de documento por clase | 2026-05-16 | C2: informe de diagnóstico de falla. C3: reporte de análisis de tendencias/alarmas. C4: protocolo de respuesta ante emergencia + justificación económica. Escalación doble: sutileza del error + complejidad documental. |
| DD_14 | Agente del profesor = lector de BD en tiempo real (no generador proactivo) | 2026-05-16 | Dos modos: (1) dashboard pasivo con estado de cada alumno en vivo, (2) chat bajo demanda que consulta PostgreSQL. Interfaz incluye ~5 preguntas sugeridas para bajar barrera de entrada (P8). El profesor decide cuándo/cómo intervenir — el agente da visibilidad, no reemplaza juicio docente. |
| DD_15 | Arquitectura MVP: Astro (Cloudflare) + n8n (orquestador) + PostgreSQL | 2026-05-16 | Frontend: dos interfaces de chat (alumno/profesor), estructura base similar, funcionalidades distintas. Backend: n8n con AI Agent nodes, webhooks, schedulers para WhatsApp. Integraciones: PDF, Drive, audio. LLM no decidido (criterio: costo + calidad socrática sin filtración). Identificación: nombre + email USACH. |
| DD_16 | Feedback automático sin revisión humana — dos destinatarios, dos orientaciones | 2026-05-16 | **Al alumno: proceso cognitivo SFL, nunca dimensional.** Describe hábitos observados (cómo conectó variables, cómo revisó hipótesis bajo contradicción) sin revelar niveles D1-D4 ni las dimensiones medidas. Protege validez interna: si el alumno supiera qué se mide, adaptaría su discurso a la métrica (características de demanda), inflando artificialmente Δ_inter. **Al profesor:** informe analítico del grupo + individuos (patrones, progresión, estancamientos, sugerencias para próxima clase). Objetivo: potenciar la experiencia del profesor como analista, no agregarle carga de revisión. Ver Marco Metodológico v1.8 §5.1 para tabla de ejemplos SÍ/NO. |
| DD_17 | Clase 5 CON IA pero sin instrucción — transferencia de metodología | 2026-05-16 | Problema nuevo + chatbot disponible + sin Modelo A/B explícito. Mide si el alumno reproduce autónomamente el protocolo aprendido. + Encuesta final de autopercepción. Alineado con P3 (coexistencia). Comparación C1 vs C5: misma herramienta, distinta competencia de uso. |
| DD_18 | Fase "pensar primero" es en PAPEL — digitalización automática vía interfaz + n8n + AI Vision | 2026-05-16 | Alumno escribe a mano (fuerza cognición profunda), sube foto con botón en la interfaz del chat → webhook n8n → AI Agent analiza imagen → resultado en PostgreSQL + contexto para chatbot PLAN. Almacenamiento en Drive por detrás. Cero carga para el profesor. (Actualizada por DD_38). |
| | **Nota de implementación (2026-06-15):** La implementación actual en C1 usa una **etapa pre-chat separada** (`etapa_ui_est 3` del flujo estudiante-plataforma) donde el alumno sube las **3 páginas de la Ficha 1** de forma secuencial. Cada página se procesa con Gemini Vision OCR y se almacena en `usach_mensajes_chat` con etapa `clase1:M1_p1/p2/p3`. El alumno confirma cada página individualmente. Solo después de confirmar las 3 páginas puede acceder al chat. El contexto OCR se inyecta en cada turno del chat como evidencia del rastro inicial. Ver `doc_pro_Flujo_Estudiante_Plataforma_v1.1.md` §2.3 y `doc_pro_Plataforma_Implementacion_v1.6.md` §5.6.1. |
| DD_19 | Transición PLAN→BUILD la controla el profesor para toda la clase | 2026-05-16 | El profesor activa el modo BUILD desde su interfaz simultáneamente para todos. Permite intervenciones grupales antes de la transición y mantiene control del ritmo del aula. |
| DD_20 | Chatbot en C5 es NEUTRO (no socrático) | 2026-05-16 | Responde sin presionar. La transferencia se mide porque el alumno ELIGE pensar profundo sin que la IA lo fuerce. Si reproduce el protocolo con IA neutra = internalizó el método. Si vuelve a ser superficial = el protocolo solo funcionó con andamiaje. Mide reducción real de deuda cognitiva. |
| DD_21 | C1 se mantiene limpia (solo Modelo A) — onboarding pre-curso vía WhatsApp | 2026-05-16 | C1 = 80 min completos de línea base (papel + socrático básico, sin BUILD). Onboarding de plataforma + consentimiento informado se envían ANTES de C1 por WhatsApp (scheduler n8n). Alumno llega sabiendo usar la interfaz. |
| DD_22 | C5 usa torre de enfriamiento industrial como caso de transferencia | 2026-05-16 | Sistema distinto (aire/agua vs. filtración), estructura análoga (diagnosticar→instrumentar→monitorear→controlar), relevante para industria chilena. Mide si el alumno transfiere la metodología a un problema nuevo que nunca vio en C1-C4. |
| DD_23 | Encuesta final C5 es mixta (Likert + preguntas abiertas) | 2026-05-16 | 4 ejes: (1) cambio percibido en forma de estudiar, (2) relación con la IA antes/después, (3) capacidad de evaluar respuestas de IA, (4) hábito de pensar antes de preguntar. Likert para datos cuantitativos del paper + abiertas para matices cualitativos en discusión. |
| DD_24 | Timeline C2-C4: 80 min distribuidos en 6 fases | 2026-05-21 | [0-5] Encuadre + feedback clase anterior. [5-15] Papel (escribe a mano, sube foto). [15-37] Chatbot PLAN (socrático presiona). [37-40] Transición (profesor activa BUILD + intervención grupal). [40-72] Chatbot BUILD (alumno evalúa entregable con errores). [72-80] Cierre (reflexión Δ_intra). Actualización 2026-05-21: horario real USACH = 08:15–09:35 (80 min). Redistribución aprobada por IP. |
| DD_25 | Evaluación del entregable BUILD es formato LIBRE | 2026-05-16 | El alumno escribe lo que quiera sobre el documento recibido (sin ficha ni checklist). La AGENT_ANALISTA_SFL aplica D1-D4 sobre el texto libre. Formato libre mide criterio real: quién detecta el error crítico sin que le digan dónde mirar. Una checklist mediría obediencia, no juicio ingenieril. |
| DD_26 | La evaluación BUILD se hace EN EL CHAT (no campo separado) | 2026-05-16 | La interacción es la evaluación: alumno señala errores, chatbot defiende sus errores ("¿seguro? justifica"), alumno argumenta con fundamento técnico. El proceso completo va a PostgreSQL automáticamente. La AGENT_ANALISTA_SFL extrae calidad evaluativa de la conversación. Menos complejidad de interfaz. |
| DD_27 | Chatbot BUILD DEFIENDE sus errores (no acepta pasivamente) | 2026-05-16 | Cuando el alumno señala un error, el chatbot contraargumenta técnicamente. El alumno debe sostener su posición con fundamento. Mide D4 (decisión bajo presión). La conversación completa queda en BD y la AGENT_ANALISTA_SFL es experta en evaluar calidad argumentativa de texto. Máximo provecho del formato chat. |
| DD_28 | El alumno NO sabe que BUILD tiene errores deliberados | 2026-05-16 | Se le presenta como "documento basado en tu plan, revísalo antes de firmarlo." Mide si el alumno confía ciegamente (deuda cognitiva) o verifica por defecto (criterio profesional). Realismo: en la vida real nadie avisa que un documento tiene errores. |
| DD_29 | Si el alumno acepta sin verificar, el chatbot empuja UNA vez ("¿lo firmarías con tu nombre profesional?") | 2026-05-16 | No revela errores, simula pregunta de supervisor real. Si después del push sigue aceptando = dato fuerte de deuda cognitiva. Si recapacita = protocolo funcionando. Automático (no depende del profesor). El dashboard igualmente muestra el evento al profesor (DD_14). |
| DD_30 | Reflexión de cierre: en el chat, disparada por el profesor | 2026-05-16 | El profesor activa "cierre" desde su interfaz (mismo patrón que DD_19). El chatbot pregunta al alumno qué cambiaría de su escrito inicial y por qué. Queda en PostgreSQL. AGENT_SESION invoca a AGENT_ANALISTA_SFL para comparar inicio (foto analizada) vs. cierre (texto chat) y calcular Δ_intra. |
| DD_31 | Sin límite de turnos en el chat — la cantidad es dato, no restricción | 2026-05-16 | El chatbot socrático no filtra respuestas sin importar cuántos turnos → no hay incentivo para spamear. La cantidad y calidad de interacciones es dato orgánico para la AGENT_ANALISTA_SFL. Un límite artificial contaminaría la medición (no distinguiría criterio propio de racionamiento forzado). |
| DD_32 | Interfaz profesor MVP: 7 controles | 2026-05-16 | (1) Selector de clase (carga prompts/config), (2) Dashboard en vivo, (3) Chat bajo demanda + 5 preguntas sugeridas, (4) Pausa (congela todos los chats para intervención grupal), (5) Activar BUILD, (6) Activar cierre/reflexión, (7) Cerrar sesión (dispara pipeline: AGENT_SESION → feedback alumno + informe profesor → WhatsApp vía n8n scheduler). |
| DD_33 | Pausa muestra mensaje visible al alumno: "El profesor ha pausado la sesión. Pon atención al frente." | 2026-05-16 | Chat bloqueado + mensaje explícito. Sin ambigüedad. |
| DD_34 | El alumno puede ver su historial de clases anteriores (lectura) | 2026-05-16 | Acceso a conversaciones pasadas. Útil en devolución de inicio (min 0-5) y refuerza consciencia epistémica (D3): el alumno ve su propia evolución. |
| DD_35 | Mensaje pre-clase (día anterior) vía WhatsApp: vocabulario, no contenido | 2026-05-16 | Qué tema verán (1 línea) + 4-5 términos clave con definición breve. Cero análisis, cero opinión. Objetivo: cargar vocabulario para que los 80 min sean de pensamiento, no de descifrar siglas. No viola P9 (vocabulario ≠ criterio). n8n scheduler automatiza el envío. |
| DD_36 | Ausencias se registran como dato, no se excluyen ni recuperan | 2026-05-16 | El hueco es dato analizable ("alumno que faltó a C3 muestra X en C4"). Core cuantitativo usa asistencia completa; casos con huecos van a discusión como hallazgos exploratorios. No se pierde muestra. Realismo: en la universidad se falta. |
| DD_37 | Consentimiento informado: ambos (firma física + confirmación digital) | 2026-05-16 | Papel firmado para el comité de ética (conservador). Confirmación digital en la plataforma con timestamp para trazabilidad en BD. El alumno lee dos veces = mayor consciencia. Firma física pre-C1; confirmación digital en primer acceso a la plataforma. |
| DD_38 | El chatbot PLAN lee el papel del alumno antes de iniciar | 2026-05-16 | Interfaz tiene botón "Subir imagen". Foto va a webhook n8n → agente de análisis de imagen → resultado como contexto del chatbot PLAN. Presión cognitiva personalizada: ataca debilidades específicas del razonamiento de ese alumno. Almacenamiento en Drive/BD por detrás (n8n). Actualiza DD_18: la subida es por interfaz, no por Drive directamente. |
| | **Nota de implementación (2026-06-15):** En C1, la "foto" son en realidad **3 páginas de la Ficha 1** subidas en la `etapa_ui_est 3` (pre-chat). El workflow `usach_evidencia_formulario` procesa cada página con Gemini Vision OCR y almacena el resultado. El nodo `Buscar evidencias M1` en el workflow del chat inyecta las 3 descripciones OCR en cada turno como bloque `--- RASTRO INICIAL DEL ESTUDIANTE ---`. El chatbot PLAN tiene acceso al rastro completo en toda la conversación, no solo al inicio. Para C2-C5, la foto del rastro se sube inline en el chat (flujo original). Ver `doc_pro_Flujo_Estudiante_Plataforma_v1.1.md` §2.3-2.4. |
| DD_39 | Escenarios C2-C4: mismo Centro Acuático, historia acumulativa, nivel profesional | 2026-05-16 | C2: diagnóstico con 6 variables numéricas + hipótesis competidoras + intervención previa del operador + decisión no binaria (abrir/cerrar/restricciones). C3: datos ambiguos + sensor sin calibrar + bias térmico + bomba sobredimensionada + sesgo de confirmación del operador. C4: automatización 38h con autonomía de cloro insuficiente (31h) + válvula manual + guardia no-técnico + presión política del alcalde + presupuesto que fuerza trade-offs. Coherencia narrativa: los problemas se acumulan entre clases. |