--- nombre: Guion Docente Clase 3 v1.1 tipo: doc_pro clase: 3 version: 1.2 deriva_de: instrumentos/clase3/doc_pro_GuionDocente_Clase3_v1.1.md fecha_emision: 2026-05-31 nota: "v1.2 añade mapa del género BUILD C3 (reporte SCADA) en Fase 3 e indicadores SFL de observación docente en Fase 4. v1.1 corrige duración 90→80 min y alinea fases con DD_24." status: fuente_normativa emitido_por: Ángel Royo Melgarejo (IP) cambio_v1.1_a_v1.2: > Revisión SFL (Ingrid Westhoff Podestá). Cambios: (1) Mapa del género BUILD C3 (reporte SCADA: Resumen ^ Análisis de tendencias ^ Propuesta de alarmas ^ Recomendaciones) insertado en Fase 3 antes de activar BUILD. (2) Indicadores de observación lingüística SFL añadidos al rol docente en Fase 4 (BUILD): cuestionamiento de fuente, distinción correlación/causalidad, marcadores evidenciales, hedging propio. Fundamentado en doc_inv_SFL_Analisis_v1.1.md §5. referencia_premisas: instrumentos/doc_inv_Premisas_Diseno_v1.1.md referencia_system_prompt: instrumentos/doc_pro_SystemPrompt_Chatbot_v2.1.md (§3.3) referencia_datos: instrumentos/doc_pro_DatosTecnicos_CasoPiscina_v2.2.md (§8, §5, §11) --- # Guion Docente Ejecutable — Clase 3 de 5 **Monitorear un sistema técnico: señal, ruido y datos que mienten** **Universidad de Santiago de Chile · Facultad de Ingeniería — Departamento de Ingeniería Industrial** --- | Campo | Detalle | |-------|---------| | Asignatura | Laboratorio de Máquinas y Equipos Industriales (14362-0-L-1) | | Duración | 80 minutos (08:15–09:35, viernes) | | Modalidad | Laboratorio presencial — trabajo individual (P6) | | Caso técnico | Centro Acuático Municipal de Maipú — análisis de datos SCADA con sensor sin calibrar, falsas alarmas y sesgo del operador | | Marco metodológico | pensamiento propio → rastro visible → chatbot socrático (PLAN) → entregable con errores (BUILD) → evaluación crítica → reflexión Δ_intra | | Rol del chatbot | PLAN socrático de monitoreo (C3): presiona sobre calidad de datos, sesgo de confirmación, correlación vs. causalidad. BUILD reporte de tendencias y alarmas (C3): genera documento con errores sutiles (DD_8) — trata correlación como causalidad, usa sensor sin calibrar como confiable. Defiende errores cuando el alumno los señala (DD_27). | | Versión | Guion Docente v1.2 — Mayo 2026 | --- ## Columna vertebral de la clase - No busco que lean los datos. Busco que desconfíen de ellos. - No evalúo si el alumno encuentra la alarma real. Evalúo si distingue señal de ruido. - El chatbot no interpreta los datos por el alumno. Le obliga a cuestionar la fuente. --- ## Puesta en escena pedagógica La clase se presenta como sala de control: tablero SCADA, sensores, alarmas, ruido, calibración dudosa, bitácora de operador y decisiones con consecuencia operacional. No se debe abrir como "análisis con IA". Frase central obligatoria: > Un sensor no es la realidad. Un sensor es una medición situada, calibrada o mal calibrada, con ruido, sesgo y consecuencias operacionales. El contraste socrático se presenta como defensa de la confiabilidad de los datos. La revisión del reporte se presenta como evaluación profesional de un documento que podría llegar a mantenimiento. --- ## Prerrequisitos completados antes de C3 - Clases 1 y 2 ejecutadas. - Feedback personalizado de C2 enviado por WhatsApp (DD_10/DD_16). - Mensaje pre-clase con vocabulario técnico (DD_35): SCADA, tendencia, alarma, señal vs. ruido, sesgo de confirmación. - Rastro inicial de C2 en custodia del docente (se devuelve en esta clase). ## 0. Checklist de preparación — antes de entrar al laboratorio | ✓ | Ítem de preparación | Detalle | |---|---|---| | ☐ | Feedback de C2 enviado a todos los alumnos | Verificar en dashboard | | ☐ | Mensaje pre-clase C3 enviado (día anterior) | Vocabulario: SCADA, tendencia, alarma, señal vs. ruido, sesgo de confirmación (DD_35) | | ☐ | Rastros iniciales de C2 disponibles para devolver | Una ficha por alumno | | ☐ | Caso Técnico C3 impreso | Un ejemplar por alumno: ficha n1 · Caso Técnico C3 (incluye dataset SCADA impreso — 60 lecturas) | | ☐ | Ficha Pre-AI C3 impresa | Un ejemplar por alumno: ficha n2 · Ficha Pre-AI C3 | | ☐ | Guía Chatbot C3 impresa | Un ejemplar por alumno: ficha n3 · Guía Chatbot C3 | | ☐ | Hojas en blanco disponibles | Para gráficos de tendencia dibujados a mano (P5) | | ☐ | Chatbot configurado con prompt PLAN C3 | Dashboard (DD_32): selector de clase en "Clase 3", modo PLAN socrático de monitoreo | | ☐ | Diapositiva: ¿qué es un SCADA? (recordatorio visual) | Para alumnos que no leyeron el vocabulario pre-clase | | ☐ | Diapositiva: contexto narrativo C3 | "3 semanas sin mantenimiento, Muñoz dice todo normal, 60 lecturas" | | ☐ | Diapositiva: instrucciones de la Ficha Pre-AI C3 | Texto exacto | ## Fase 0 — Encuadre + devolución [0–5 min] **Lo que dices tú** La clase pasada terminaron diagnosticando un sistema con hipótesis competidoras. ¿Alguno quiere comentar algo del feedback que recibieron de la Clase 2? Algo que les haya hecho pensar. (Pausa breve. Máximo 1 minuto.) ▶ DISTRIBUIR los papeles del rastro C2. **Lo que dices tú** Mírenlo 30 segundos. ¿Habrían hecho un diagnóstico diferente con lo que saben hoy? No respondan en voz alta. Guarden esa reflexión. Pongan la hoja a un lado. ▶ DISTRIBUIR Caso Técnico C3 + Ficha Pre-AI C3 + Guía Chatbot C3. **Lo que dices tú** Hoy seguimos con el mismo Centro Acuático, pero tres semanas después. El sistema ha estado operando sin parada de mantenimiento. El operador Muñoz dice que todo está normal. El SCADA registró 60 lecturas en 10 horas. Su trabajo hoy es distinto al de las clases anteriores: no van a diagnosticar un incidente puntual. Van a analizar datos de monitoreo continuo. La pregunta central de hoy: ¿Le creen a los datos? ## Fase 1 — Rastro en papel [5–15 min] **Lo que dices tú** Tienen un dataset impreso con 60 lecturas de 6 variables. Miren los números. Antes de usar cualquier herramienta, quiero que hagan algo a mano. ▶ PROYECTAR ACTIVIDAD — Rastro inicial [individual · sin IA · 10 minutos] Con su Ficha Pre-AI y hojas en blanco: 1. Identifiquen las tendencias principales en los datos (¿qué sube, qué baja, qué se mantiene?). 2. Marquen cualquier dato que les parezca sospechoso o fuera de patrón. 3. Escriban: ¿la bitácora del operador es coherente con lo que muestran los datos? 4. Propongan un diagnóstico preliminar del estado del sistema. 5. Anoten: ¿en qué datos confían y en cuáles no? ¿Por qué? Si saben dibujar un gráfico a mano (variable vs. hora), háganlo. Un gráfico dice más que una tabla. ▶ TU ROL DURANTE ESTA FASE - Camina por la sala. No entregas respuestas. - Preguntas activadoras: - "¿Ya miraste la presión diferencial? ¿En qué dirección va?" - "¿Las alarmas que ves son todas iguales o hay alguna que se comporta diferente?" - "El operador dice que todo está normal. ¿Los datos dicen lo mismo?" - No corrijas. No menciones el sensor sin calibrar ni las falsas alarmas. ⚠ ATENCIÓN El alumno recibe el dataset SIN la nota de que el sensor de pH tiene offset de +0.15. Descubrir (o no) esa inconsistencia es parte de la evaluación. Al finalizar los 10 minutos: **Lo que dices tú** Tomen foto de su ficha y de cualquier gráfico que hayan dibujado. Botón "Subir imagen" en la interfaz del chatbot. ## Fase 2 — Chatbot PLAN socrático [15–37 min] **Lo que dices tú** El chatbot leyó su análisis. Va a hacerles preguntas difíciles. Recuerden: este chatbot es de monitoreo. No busca la causa de un problema — busca si ustedes CONFÍAN EN SUS DATOS. Hay una diferencia entre la Clase 2 y hoy. En la Clase 2 el problema era evidente: sistema degradado, datos claros. Hoy los datos tienen trampas. Hay lecturas que parecen alarmas pero no lo son. Hay tendencias reales escondidas detrás de ruido. Y hay un operador que dice que todo está bien cuando los datos sugieren lo contrario. El chatbot les va a presionar especialmente en: - ¿Confían en todos los sensores por igual? - ¿Esa correlación es causalidad o coincidencia? - ¿El operador tiene razón o tiene sesgo? Tienen 22 minutos. No hay límite de mensajes. ▶ TU ROL DURANTE ESTA FASE - Dashboard (DD_32): observa cómo manejan la ambigüedad. - ¿El alumno acepta el pH como "ligeramente alto" sin cuestionar calibración? → D3 bajo. - ¿Distingue falsas alarmas de tendencia real? → D1 alto. - ¿Cuestiona la bitácora de Muñoz? → D3 alto. - ¿Reconoce que la bomba enmascara la obstrucción? → D1 alto. - Intervenciones si ves pasividad: - "No le preguntes al chatbot qué significan los datos. Dile cuál dato te parece sospechoso y por qué." - "Si el operador te dice que todo está bien pero los números dicen otra cosa, ¿a quién le crees?" - Puedes usar la pausa (DD_33) si necesitas intervención grupal. ⚠ EVIDENCIA QUE QUEDA PARA EL PAPER - Conversación PLAN completa en PostgreSQL (DD_9). - La AGENT_ANALISTA_SFL evaluará: si cuestionó calidad de datos (D3), si distinguió señal/ruido (D1), si confrontó la bitácora del operador, si detectó el efecto de la bomba ligeramente sobredimensionada y del punto de medición parcial del caudal. ## Fase 3 — Transición PLAN → BUILD [37–40 min] ▶ DESDE EL DASHBOARD: Activar modo BUILD para toda la clase (DD_19). **Lo que dices tú** Atención. El chatbot ahora va a generar un reporte de análisis de tendencias y configuración de alarmas basado en lo que ustedes construyeron. Van a recibir un documento profesional: el tipo de reporte que un ingeniero de mantenimiento le entregaría a su jefe. Su trabajo es revisarlo como si ustedes tuvieran que presentarlo en una reunión. Frase clave. Dila despacio: Un reporte con un gráfico bonito y lenguaje técnico sigue siendo basura si la lógica está mal. No se dejen impresionar por el formato. Lean la lógica. > **Nota SFL — Mapa del género:** Antes de que el chatbot genere el reporte, entrega al estudiante el esquema del género que va a evaluar. Esto transforma la evaluación de "intuición sobre corrección" a "verificación de estructura de género" (Rose & Martin, 2012). Ver `doc_inv_SFL_Analisis_v1.1.md` §5. **Lo que dices tú (mapa del género — dilo antes de activar BUILD):** > Van a recibir un reporte de análisis de tendencias generado por la IA. > Este tipo de documento tiene 4 partes: > 1. **Resumen ejecutivo:** qué sistema, qué período, qué se buscaba > 2. **Análisis de tendencias:** qué variables se mueven, en qué dirección, con qué magnitud > 3. **Propuesta de alarmas:** umbrales sugeridos con justificación cuantitativa > 4. **Recomendaciones:** qué monitorear, cada cuánto, y qué hacer si se dispara una alarma > > Además, pregúntense: ¿los datos que usa el reporte son confiables? ¿Todos los sensores miden bien? ⚠ ATENCIÓN NO mencionar que el documento tiene errores deliberados (DD_28). La instrucción es "revísalo como si fueras a presentarlo" — no "busca los errores." ## Fase 4 — Chatbot BUILD [40–72 min] El chatbot genera un reporte de análisis de tendencias y configuración de alarmas de ~500-700 palabras. Contiene 2-3 errores sutiles: tratar correlación como causalidad, usar datos del sensor de pH sin cuestionar calibración, proponer umbrales de diseño para pH como si fueran alarmas SCADA configuradas, o confirmar el sesgo de Muñoz. **Lo que dices tú** Cada uno recibió su reporte. Léanlo completo antes de escribir nada. Después, en el mismo chat, escriban lo que piensan del documento. No hay formato obligatorio. Tienen 32 minutos. ▶ TU ROL DURANTE ESTA FASE - Dashboard (DD_32): observa las interacciones BUILD. - ¿Acepta el reporte sin cuestionarlo? → Push DD_29 se activa automáticamente. - ¿Señala que el reporte usa el pH sin cuestionar? → Detectó el error más sutil. - ¿Cuestiona la conclusión de causalidad? → D1 alto. - Cuando el chatbot defiende un error (DD_27), ¿el alumno cede o mantiene posición? - Intervenciones si ves aceptación generalizada: - "Ese reporte dice algo sobre el pH. ¿Están seguros de que el dato es confiable?" - Cuidado: esta intervención roza la frontera de DD_28. Usarla SOLO si detectas aceptación masiva y pasiva. El objetivo es activar pensamiento, no revelar el error. - Puedes usar la pausa (DD_33) si necesitas intervención grupal: - "Antes de firmar un reporte, un ingeniero se pregunta: ¿confío en la fuente de cada dato que usé?" ### Observación lingüística (SFL) — qué mirar en la evaluación BUILD del estudiante Cuando el estudiante evalúa el reporte BUILD en el chat, observa estos indicadores lingüísticos en su texto: | Indicador | Señal de criterio evaluativo (D3 alto) | Señal de aceptación pasiva (D3 bajo) | |---|---|---| | **Cuestionamiento de fuente** | "El reporte usa el pH sin verificar si el sensor está calibrado" | "Los datos del reporte son correctos" | | **Distinción correlación/causalidad** | "Que el pH y la temperatura suban juntos no significa que uno cause al otro" | "El reporte dice que la temperatura causa el pH alto" | | **Marcadores evidenciales** | "Según los datos del SCADA, la tendencia de ORP es ruido, no señal" | Sin referencia a fuente de datos | | **Hedging propio** | "Probablemente el sensor tiene offset, pero necesitaría la calibración para confirmar" | "El reporte está correcto" (sin modalización) | ⚠ EVIDENCIA QUE QUEDA PARA EL PAPER - Interacción BUILD completa en PostgreSQL (DD_9). - La AGENT_ANALISTA_SFL evalúa: si detectó errores sutiles, si distinguió formato profesional de lógica correcta, calidad de defensa ante DD_27, evolución desde C2 (errores obvios → errores sutiles). ## Fase 5 — Cierre + reflexión Δ_intra [72–80 min] ▶ DESDE EL DASHBOARD: Activar modo cierre para toda la clase (DD_30). El chatbot pregunta automáticamente: "Vuelve a tu escrito inicial (el que hiciste en papel al principio). ¿Qué cambiarías ahora y por qué?" **Lo que dices tú** Vamos cerrando. El chatbot les hace una última pregunta sobre su análisis inicial. Respondan con honestidad. (Esperar ~5 min para que todos respondan.) **Lo que dices tú** Hoy trabajaron con datos de monitoreo continuo. Sesenta lecturas en 10 horas. Los datos tenían trampas: lecturas que parecían alarmas pero no eran, tendencias reales escondidas en ruido, y un operador que les decía que todo estaba bien cuando no lo estaba. Si alguien salió de esta clase creyéndole a todos los sensores y al operador, le pido que revise. En la próxima sesión la presión sube al máximo: van a diseñar una estrategia de operación para 38 horas continuas con un guardia que no es técnico, un presupuesto limitado y un alcalde que presiona. Última frase. Dila despacio: Un dato no es evidencia hasta que verificas la fuente. ▶ DESPUÉS DE LA CLASE - Pipeline de cierre (DD_32, control 7): AGENT_SESION → feedback al alumno + informe al profesor. - Rastros de C3 (fichas en papel + gráficos a mano) quedan bajo custodia del docente para devolución en C4. ## Resumen de timeline v1.1 — Clase 3 (corregido: 80 min per P4) | Minutos | Fase | Actividad | Modalidad | |---------|------|-----------|-----------| | 0–5 | 0 | Encuadre: feedback C2 + devolución rastro C2 + distribución caso C3 | Profesor → grupo | | 5–15 | 1 | Rastro en papel: análisis de 60 lecturas SCADA, identificar tendencias | Individual, sin IA (P5) | | 15–37 | 2 | Chatbot PLAN: socrático de monitoreo (calidad de datos, señal/ruido, sesgo) | Individual, con chatbot | | 37–40 | 3 | Transición: profesor activa BUILD + intervención grupal | Profesor → grupo | | 40–72 | 4 | Chatbot BUILD: alumno evalúa reporte de tendencias/alarmas (formato libre DD_25/DD_26) | Individual, con chatbot | | 72–80 | 5 | Cierre: reflexión Δ_intra (profesor activa DD_30) | Individual, con chatbot | ## Evidencia que queda para el paper (por alumno) 1. Rastro inicial C3 (foto de ficha + gráficos a mano, analizada por AI Vision). 2. Conversación PLAN: calidad de cuestionamiento de datos, manejo de sesgo, señal/ruido. 3. Conversación BUILD: detección de errores sutiles, defensa ante DD_27, push DD_29 si aplicó. 4. Reflexión de cierre Δ_intra en el chat (DD_30) — evidencia oficial para comparación M4 − M1. 5. Ficha Pre-AI C3 + gráficos (papel bajo custodia del docente). 6. Ficha PostAI C3 (n4) — respaldo metacognitivo en papel, no sustituye la reflexión oficial del chat. ## Feedback automático post-sesión (DD_16): - Al alumno vía WhatsApp: sobre proceso cognitivo (DD_11). - Al profesor vía WhatsApp: informe analítico con comparativa C1→C2→C3 (progresión o estancamiento). La experiencia que vive el estudiante Si la clase funciona, el estudiante vive esta secuencia: 1. Recibe 60 lecturas impresas — primera vez que enfrenta un volumen real de datos. 2. Tiene que encontrar patrones a mano antes de tener ayuda. 3. El chatbot le pregunta: "¿Confías en todos los sensores por igual?" 4. Descubre (o no) que los datos pueden mentir: un sensor sin calibrar, un operador con sesgo. 5. Recibe un reporte profesional que se ve impecable — pero la lógica tiene fallas sutiles. 6. Si señala un error, el chatbot contraargumenta técnicamente. Tiene que defender su posición. 7. La clase marca la transición de "leer datos como verdad" a "cuestionar la fuente." ## Escenarios anticipados — Qué esperamos observar en C3 Esta sección documenta los escenarios probables de la Clase 3 como herramienta de preparación para el equipo de investigación. C3 introduce datos que mienten: 60 lecturas con trampas sutiles (sensor con offset, falsas alarmas, tendencia enmascarada). Cada perfil de estudiante enfrenta un desafío nuevo: cuestionar la fuente de los datos, no solo interpretarlos. Sobre los diálogos: Los diálogos chatbot–estudiante son anticipaciones ilustrativas, no scripts del chatbot. El chatbot opera según su system prompt; las interacciones reales variarán. C3 introduce tres saltos respecto a C2: - De 6 lecturas a 60 lecturas (dimensión temporal sostenida). - De datos con anomalías evidentes a datos con trampas sutiles (sensor con offset, falsas alarmas, tendencia enmascarada). - De errores obvios en BUILD (DD_8 C2: síntoma como causa) a errores sutiles en BUILD (DD_8 C3: correlación como causalidad, fuente sin cuestionar). La competencia central que se mide: ¿el estudiante cuestiona la fuente de los datos o los toma como verdad? > Cómo leer este árbol: La Escena 1 produce tres perfiles según el rastro en papel. En la Escena 2, el chatbot socrático presiona cada perfil; en la Escena 3, el chatbot BUILD genera un reporte con errores sutiles (correlación como causalidad, fuente sin cuestionar). Cada camino (A1, A2, B1, B2, C1, C2) desencadena una evaluación distinta en la Escena 3 y un resultado observable en la Escena 4. No son estudiantes distintos — son caminos posibles del mismo perfil. ``` Escena 1 Escena 2 Escena 3 Escena 4 (rastro en papel) (chatbot PLAN) (chatbot BUILD) (observación docente) Perfil A (analítico) ───┬─ A1: cuestiona + cuantifica ── A1: detecta errores sutiles ── Dato paradigmático └─ A2: cuestiona sin cuantificar A2: detecta parcialmente ──── Rigidez cualitativa Perfil B (lector) ──────┬─ B1: primera duda sobre ────── B1: detecta 1 error ────────── Trayectoria mayoritaria │ la fuente esperada └─ B2: defiende los datos ─────── B2: acepta BUILD ─────────── Señal de alerta Perfil C (abrumado) ───┬─ C1: Muñoz como ancla ──────── C1: detecta incongruencia ──── Progresión real └─ C2: no se engancha ─────────── C2: acepta todo ──────────── Señal de alerta alta ``` Leyenda de indicadores: - D1 — Complejidad causal: ¿distingue correlación de causalidad? - D2 — Especificidad técnica: ¿usa las 6 variables técnicas y el estado de alarma con valores, rangos y unidades? - D3 — Consciencia epistémica: ¿cuestiona la fuente de los datos? ¿Detecta errores sutiles en BUILD? - D4 — Decisión bajo incertidumbre: ¿decide con datos que podrían ser falsos? - DD_27 — Mecanismo de diseño (no dimensión): el chatbot defiende errores sutiles para generar evidencia de D3 y D4. En C3 hay cuatro momentos de medición: M1 (rastro en papel), M2 (post-PLAN), M3 (post-BUILD — indicador independiente de evaluación crítica D3/DD_27, NO usado para Δ_intra) y M4 (cierre reflexivo DD_30). El Δ_intra se calcula como M4 − M1 (cierre vs. rastro inicial, alineado con DD_30 de Premisas v1.0 y con la Rúbrica Longitudinal v1.6). ## Escena 1 — El rastro en papel (min 5–15) El estudiante recibe el dataset SCADA impreso (60 filas × 6 variables técnicas + estado de alarma) junto con la bitácora del operador Muñoz que dice "todo funciona normal". El dataset contiene cuatro trampas diseñadas: sensor de pH con offset de +0.15, bomba ligeramente sobredimensionada que enmascara la severidad inicial de la obstrucción, falsas alarmas transitorias, y una tendencia real de degradación escondida detrás de ruido. El estudiante NO sabe que estas trampas existen. Perfil A — El Analítico: cuestiona los datos antes de interpretarlos Examina las 60 filas con método. Identifica tendencias principales (turbidez creciente, ORP decreciente). Pero hace algo que los otros perfiles no hacen: cuestiona la fuente. Nota que el pH se mantiene consistentemente en un rango estrecho pero ligeramente elevado — sospecha de la calibración del sensor. Observa que el caudal parcial cae de forma gradual y se pregunta si está mirando el caudal total del sistema o un ramal de medición. Contrasta la bitácora de Muñoz ("todo normal") con los datos y detecta la incongruencia. Dibuja gráficos a mano separando variables para ver correlaciones temporales. - D1 — Distingue tendencia real de variación aleatoria. Nota que la turbidez sube pero el pH "parece estable" (sospecha del sensor). - D2 — Usa valores específicos, compara rangos esperados con observados. Nombra el offset como posibilidad. - D3 — Cuestiona la fuente: ¿el sensor está bien? ¿El operador tiene razón? ¿Qué datos me faltan para confirmar? - D4 — Formularía una hipótesis verificable: "si el sensor tiene offset, las conclusiones basadas en pH alto podrían ser falsas." Perfil B — El Lector de datos: lee tendencias pero confía en las fuentes Lee las 60 filas ordenadamente. Identifica tendencias correctamente: "el pH sube ligeramente", "la turbidez aumenta al final del periodo", "el ORP baja". Pero trata cada sensor como fuente confiable. No cuestiona la calibración del pH ni la coherencia entre la bitácora de Muñoz y los datos. Si el sensor dice que el pH está en 7.45, acepta 7.45. Puede comparar el pH con el rango de diseño, pero lo trata como si fuera una alarma SCADA configurada. No se pregunta si esa conclusión podría ser falsa por calibración. - D1 — Identifica tendencias correctas pero sin separar señal de ruido. - D2 — Nombra variables y valores pero no rangos de calibración. - D3 — No distingue dato confiable de dato sospechoso. Confía en todas las fuentes. - D4 — Propone acción basada en datos que podrían ser falsos ("ajustar pH porque está alto"). Perfil C — El Abrumado: 60 filas lo desbordan Es la primera vez que enfrenta un dataset de esta magnitud. En C2 tenía 6 lecturas; ahora tiene 60. No sabe por dónde empezar. Puede intentar leer fila por fila y perderse, o puede quedarse mirando la tabla sin estrategia. La bitácora de Muñoz le da una salida fácil: "el operador dice que todo está normal, entonces todo está normal". Escribe poco. La sección de hipótesis queda vacía o con una frase genérica ("los datos se ven normales"). La sección de alarmas queda sin responder. - D1 — No identifica tendencias. El volumen de datos impide la síntesis. - D2 — Lenguaje vago: "algunos datos suben", "parece que algo cambia". - D3 — No sabe qué datos mirar ni en qué orden. - D4 — Se refugia en la autoridad del operador para evitar decidir. ⚠ En la realidad, los perfiles serán mixtos. Un estudiante puede identificar tendencias correctamente (Perfil B en D1) pero cuestionar la calibración del sensor (Perfil A en D3), o dibujar gráficos sofisticados (Perfil A en D2) pero aceptar la bitácora de Muñoz sin cuestionarla (Perfil B en D3). Lo que determina la trayectoria en la Escena 2 es el perfil dominante: ¿el rastro muestra sobre todo cuestionamiento de fuentes, sobre todo lectura acrítica, o sobre todo bloqueo? ## Escena 2 — El encuentro socrático PLAN (min 15–37) El chatbot recibe la foto del rastro y se activa en modo PLAN socrático de monitoreo. La presión central de C3 es sobre calidad de datos: ¿confías en ese sensor? ¿Esa correlación implica causalidad? ¿El operador tiene razón o tiene sesgo? El estudiante que cuestionó fuentes en papel recibirá presión para profundizar; el que no las cuestionó recibirá la primera confrontación con la posibilidad de que los datos mientan. El mismo estudiante Perfil A llega al chatbot. ¿Qué ocurre? Camino A1 — El chatbot presiona la distinción correlación vs. causalidad El estudiante presenta su sospecha sobre el sensor de pH y la incongruencia con Muñoz. El chatbot acepta la sospecha como punto de partida pero ataca un flanco más sutil. > Chatbot: Mencionas que el pH y la temperatura se mueven juntos. ¿Eso significa que uno causa al otro? ¿O hay una tercera variable que afecta a ambos? ¿Cómo distinguirías correlación de causalidad con estos datos? > Estudiante: La temperatura puede afectar la lectura del sensor de pH... y también afecta la química del cloro. No sé si es una causa directa o un efecto confundente. > Chatbot: Si el sensor de pH tiene un offset de calibración, ¿cómo cambiaría eso tu interpretación de las conclusiones basadas en pH alto? ¿Cuántas de esas conclusiones seguirían en pie después de corregir el offset? El estudiante se da cuenta de que su sospecha sobre el sensor era correcta en dirección pero incompleta: no había calculado cuántas conclusiones basadas en pH sobreviven si se resta el offset. Profundiza su análisis separando señal de artefacto instrumental. Camino A2 — El estudiante se aferra a su diagnóstico sin cuantificar Tiene la sospecha correcta (sensor con offset) pero la trata como conclusión cerrada. Cuando el chatbot pregunta "¿cuántas conclusiones basadas en pH cambiarían si el offset fuera de 0.15?", responde "varias" sin calcular. Resiste la presión cuantitativa. Llega al BUILD con un diagnóstico cualitativamente correcto pero sin la precisión para detectar los errores sutiles del reporte. El mismo estudiante Perfil B llega al chatbot. ¿Qué ocurre? Camino B1 — El chatbot provoca la primera duda sobre la fuente El estudiante presenta sus tendencias: "el pH sube tres veces por encima del umbral, la turbidez aumenta gradualmente, el ORP baja". El chatbot ataca la premisa implícita. > Chatbot: Dices que el pH cruza el umbral de diseño tres veces. Pero antes de convertir eso en decisión operativa, necesito hacerte una pregunta: ¿confías en el sensor de pH? ¿Cuándo fue la última calibración? ¿Los datos te lo dicen? > Estudiante: ...no dice cuándo se calibró. Pero el sensor está midiendo, entonces debería estar bien, ¿no? > Chatbot: ¿Un sensor que mide necesariamente mide bien? ¿Qué pasaría si todas las lecturas de pH estuvieran infladas por un offset fijo? ¿Cuáles de tus conclusiones seguirían siendo defendibles? Este es el momento de mayor valor para C3: el estudiante descubre que "dato ≠ evidencia" y que un sensor funcionando puede estar mintiendo sistemáticamente. La transición de "leer datos" a "cuestionar la fuente" es el Δ_intra más significativo de esta sesión. Camino B2 — El estudiante defiende los datos como fuente confiable El chatbot pregunta si confía en el sensor, pero el estudiante responde: "los datos son los datos, están midiendo". No incorpora la posibilidad de error instrumental. Cuando el chatbot insiste ("¿qué pasaría si el sensor tuviera un offset?"), responde "pero no dice que lo tenga". La conversación se estanca en la premisa de que los datos son verdad porque existen. Llega al BUILD sin criterio para cuestionar fuentes. El mismo estudiante Perfil C llega al chatbot. ¿Qué ocurre? Camino C1 — El chatbot usa la bitácora de Muñoz como punto de entrada El estudiante llega con poco. El chatbot no puede presionar sobre calidad de datos si no hay análisis previo — adapta su estrategia. > Chatbot: El operador Muñoz dice que todo funciona normal. Miremos juntos una sola variable: la turbidez. ¿Sube, baja o se mantiene entre la lectura 1 y la lectura 60? > Estudiante: ...sube. Al principio está en 0.4 y al final llega a casi 16. > Chatbot: Si la turbidez sube de 0.4 a casi 16 en 10 horas, ¿Muñoz tiene razón cuando dice que todo está normal? ¿Qué significaría una turbidez de 16 NTU para la calidad del agua? El chatbot reduce el problema de 60 filas × 6 variables técnicas + estado de alarma a una sola pregunta: ¿Muñoz tiene razón? A partir de ahí construye hacia la complejidad. El estudiante empieza a articular que los datos contradicen al operador — primer indicio de consciencia epistémica. Camino C2 — El volumen de datos no se reduce — el estudiante no logra engancharse El chatbot intenta simplificar pero el estudiante responde con monosílabos. Las 60 filas siguen siendo un muro. La conversación no despega. Llega al BUILD sin criterio propio — acepta lo que venga. Este perfil es señal de alerta para el docente. No implica incapacidad — puede indicar que el salto de 6 lecturas (C2) a 60 lecturas (C3) fue excesivo para este estudiante, o que necesita un punto de entrada diferente (visual en vez de numérico). La evidencia es igualmente valiosa: documenta los límites del dataset como andamiaje cuando no hay estrategia previa de análisis. ## Escena 3 — El informe BUILD y los errores sutiles (min 40–72) El chatbot genera un reporte de análisis de tendencias y configuración de alarmas (~500-700 palabras) basado en los mismos datos SCADA. Contiene 2-3 errores sutiles (DD_8): trata la correlación pH-temperatura como relación causal directa, usa el sensor de pH como fuente confiable sin cuestionar su calibración, y declara una tendencia que es ruido estadístico. Si el alumno señala un error, el chatbot defiende su posición con contraargumentos técnicos (DD_27). Si el alumno acepta sin cuestionar, el chatbot activa el push DD_29: "¿Lo firmarías con tu nombre profesional?" La diferencia con C2 es crítica: en C2 los errores eran obvios (confusión síntoma/causa, omisión de una intervención del operador). En C3 los errores son sutiles — un ingeniero sin criterio propio los aceptaría porque el reporte es técnicamente plausible. Perfil A tras camino A1 — Detecta los errores sutiles y los confronta Lee el reporte y detecta que trata la correlación pH-temperatura como causal: "el aumento de temperatura causa el aumento de pH". El estudiante sabe (porque lo trabajó en PLAN) que el sensor tiene un offset que explica las lecturas elevadas — la temperatura no es la causa. También nota que el reporte usa las lecturas de pH sin corrección como base para sus umbrales de alarma. > Estudiante: El reporte dice que la temperatura causa el aumento de pH, pero eso es correlación, no causalidad. Si el sensor tiene un offset de +0.15, las lecturas de pH están infladas y los umbrales que propone el reporte se basan en datos sesgados. Además, la "tendencia de degradación de ORP" que menciona en la sección 3 puede ser ruido — la varianza natural del ORP es alta y 10 horas no son suficientes para confirmar una tendencia. > Chatbot: El coeficiente de correlación entre temperatura y pH es 0.87, lo que estadísticamente indica una relación fuerte. ¿No es suficiente para establecer un vínculo causal? > Estudiante: No. Correlación alta no implica causalidad. Ambas variables podrían estar respondiendo a un tercer factor, o la correlación podría ser artefacto del offset del sensor que cambia con la temperatura. El alumno sostiene su posición con precisión técnica y epistemológica. Nivel 3–4 en DD_27. - D1 — Distingue correlación de causalidad con argumento técnico - D3 — Detecta errores sutiles que el reporte presenta como conclusiones válidas Perfil A tras camino A2 — Detecta algo pero no puede precisar Tiene la intuición correcta (sospecha del sensor) pero no cuantificó el offset en PLAN. Lee el reporte y siente que "algo no cuadra" con el pH, pero le cuesta articular exactamente qué. Puede señalar que "el reporte confía demasiado en el pH" sin poder demostrar por qué. Defensa nivel 2–3. - D3 — Intuye el problema pero la articulación es imprecisa Perfil B tras camino B1 — Detecta el error que trabajó en PLAN En PLAN descubrió que "dato ≠ evidencia" y que el sensor podría estar descalibrado. Cuando el reporte BUILD usa el pH sin cuestionar la calibración, lo nota porque es exactamente lo que el chatbot le hizo cuestionar. > Estudiante: El reporte usa el pH como si fuera confiable, pero en el chatbot discutimos que el sensor podría tener un offset. Si tiene un offset, las recomendaciones que propone sobre pH serían falsas. > Chatbot: El sensor de pH reporta lecturas dentro del rango operativo normal. ¿Qué evidencia específica tienes de que está descalibrado? > Estudiante: ...no tengo evidencia directa, pero las lecturas son consistentemente más altas de lo esperado. Eso podría ser un offset sistemático. Detección parcial: detecta un error (fuente sin cuestionar) pero no el otro (correlación como causalidad). La defensa es nivel 2–3 — sabe que algo está mal pero le cuesta refutar el contraargumento del chatbot. - D3 — Transfiere lo aprendido en PLAN a la evaluación de BUILD - D1 — Detecta un error sutil pero no el patrón completo Perfil B tras camino B2 — Acepta el reporte BUILD sin criterio No cuestionó fuentes en PLAN. El reporte BUILD le parece razonable: usa vocabulario técnico, tiene estructura profesional, las conclusiones se derivan de los datos. No tiene un modelo propio contra el cual comparar. Escribe "el reporte está correcto" o "las alarmas propuestas son razonables". El push DD_29 se activa: "¿Lo firmarías con tu nombre profesional?" - D3 — No detecta errores sutiles, acepta la autoridad del formato Perfil C tras camino C1 — Detecta la incongruencia con Muñoz En PLAN descubrió que Muñoz decía "todo normal" pero la turbidez subía. El reporte BUILD confirma la versión de Muñoz implícitamente (trata el sistema como estable con variaciones menores). El estudiante nota la contradicción porque es exactamente lo que acaba de trabajar. > Estudiante: El reporte dice que el sistema opera dentro de parámetros normales con variaciones menores. Pero la turbidez sube de 0.4 a casi 16 en 10 horas. Eso no es una variación menor. Es una detección limitada (un solo punto, articulación básica) pero genuina. El estudiante que estaba abrumado por 60 filas ahora defiende una observación concreta. El Δ_intra puede ser significativo en D3. - D3 — Detecta una incongruencia entre el reporte y lo que observó Perfil C tras camino C2 — Acepta todo sin criterio Sin análisis propio del PLAN, acepta el reporte BUILD completo. El push DD_29 se activa pero la pregunta "¿lo firmarías?" no produce reflexión porque no tiene marco contra el cual evaluar. Desplazamiento mínimo. - D3 — Sin marco de referencia, acepta la autoridad del documento ## Escena 4 — Lo que el docente observa (post-sesión) Al analizar las evidencias después de la clase, el equipo de investigación puede mapear cada estudiante a una trayectoria. C3 tiene cuatro momentos de medición (M1: rastro en papel, M2: post-PLAN, M3: evaluación BUILD, M4: cierre DD_30). La tabla prioriza D1, D3 y la calidad de detección de errores sutiles. | Trayectoria | D1 — Complejidad causal | D3 — Consciencia epistémica | Detección errores sutiles BUILD | Δ_intra (M4 − M1) | Señal para el docente | |---|---|---|---|---|---| | A1 | Distingue señal/ruido + correlación/causalidad | Cuestiona sensor, operador y reporte con datos | Detecta al menos 2 errores, defiende con precisión (nivel 3–4) | D1 sube +1: de correlación observada a causalidad cuestionada | No requiere intervención. Dato paradigmático. | | A2 | Diagnóstico correcto pero no cuantificado | Intuye problemas sin precisar | Detecta parcialmente, defensa imprecisa (nivel 2–3) | D1 sin cambio cuantitativo, D3 cambio marginal | Registrar: la rigidez cualitativa limita la detección sutil. | | B1 | Tendencias correctas → primera duda sobre la fuente | Descubre "dato ≠ evidencia" en PLAN, transfiere a BUILD | Detecta 1 error (fuente sin cuestionar), no detecta correlación/causalidad (nivel 2–3) | D3 sube +1: de confianza ciega a duda fundamentada | Trayectoria esperada mayoritaria. Observar el momento de transición en log PLAN. | | B2 | Tendencias correctas pero sin cuestionar fuentes | Defiende los datos como verdad | No detecta errores, acepta formato (nivel 1) | Sin cambio observable | Señal de alerta. En C4, necesita andamiaje diferente. | | C1 | Del bloqueo a una observación concreta | Detecta incongruencia Muñoz vs. datos, transfiere a BUILD | Detecta 1 punto (incongruencia con Muñoz), defensa básica (nivel 2) | D3 sube +1: de bloqueo a observación defendida | Progresión real desde C2. Verificar Δ_inter. | | C2 | No logra sintetizar 60 filas | Acepta todo sin marco | No detecta nada (nivel 1) | Sin cambio observable | Señal de alerta alta. El salto 6→60 lecturas fue excesivo para este perfil. | ⚠ Hipótesis de distribución (pre-piloto C3): Esperamos un desplazamiento continuo respecto a C2: más estudiantes en zona B1 (50–60%) porque C2 ya los movió de descripción a conexión causal básica. El grupo A debería consolidarse (15–20%) y el C reducirse más (10–15%) — los estudiantes que en C1 estaban bloqueados ya tuvieron dos sesiones de andamiaje. La evidencia más fuerte para el paper será la trayectoria B1 (descubre "dato ≠ evidencia" en PLAN, transfiere a BUILD) y la diferencia entre B1 y B2 (mismo perfil de entrada, destino opuesto según si el PLAN logró o no plantar la duda sobre la fuente). La trayectoria A1 produce la evidencia más sofisticada (correlación ≠ causalidad) pero será minoritaria. Guion Docente Clase 3 v1.2 · Piloto IA-Socrático · Laboratorio de Máquinas y Equipos Industriales · USACH · Facultad de Ingeniería — Departamento de Ingeniería Industrial · Mayo 2026