Clase 4 de 5 — Controlar un sistema técnico: automatización, personas y trade-offs bajo presión
| Asignatura | Laboratorio de Máquinas y Equipos Industriales (14362-0-L-1) |
| Modalidad | Laboratorio presencial — trabajo individual (P6) |
| Duración | 80 minutos (08:15–09:35) (6 fases según DD_24) |
| Caso | Centro Acuático Municipal — operación 38h sin ingeniero, guardia no-técnico, autonomía cloro insuficiente, presión política |
| Rol del chatbot | PLAN adversarial + BUILD protocolo de emergencia con errores profesionales |
| Novedad | Sistema con restricciones humanas, políticas y presupuestarias reales. El problema no es solo técnico: es operacional. |
1. Función de esta sesión en el diseño del piloto
Las Clases 2 y 3 construyeron el razonamiento técnico con un chatbot socrático que pregunta. La Clase 4 cambia radicalmente la dinámica: el chatbot ataca. No pregunta para guiar, pregunta para desestabilizar. La presión no viene de un tutor paciente sino de un adversario que busca los puntos ciegos de la decisión del alumno.
El caso también cambia. Ya no es un sistema con datos operacionales que interpretar. Es un sistema con restricciones humanas reales: un guardia que no es ingeniero, una operación nocturna de 38 horas, una válvula manual que requiere intervención física, un alcalde que exige cero cierres y una SEREMI que puede clausurar por incumplimiento normativo.
La pregunta que esta sesión responde para el paper:
¿Puede el estudiante diseñar una estrategia de control viable cuando las restricciones no son solo técnicas sino humanas, presupuestarias y políticas? ¿Sostiene su decisión bajo presión adversarial o cede sin evidencia?
1.1 Propósito pedagógico
Que el estudiante formule una estrategia de control para 38 horas continuas de operación, considerando las capacidades reales del operador no-técnico, las limitaciones de autonomía del sistema de cloración, las restricciones presupuestarias y la presión política. Que defienda esa estrategia bajo presión adversarial y que evalúe críticamente un protocolo de emergencia generado por IA.
1.2 Propósito investigativo
C4 es la última medición antes de la transferencia en C5. Los datos de BUILD son especialmente valiosos porque miden el techo de razonamiento técnico alcanzado con todo el andamiaje previo. La conversación adversarial de PLAN revela si el alumno puede sostener decisiones con evidencia o colapsa bajo presión.
2. El caso — Centro Acuático Municipal
El caso presenta un sistema con cinco actuadores, condiciones de emergencia definidas y un operador nocturno (guardia Contreras) cuyas capacidades reales determinan qué es viable y qué no. Las restricciones clave:
- 38 horas continuas sin ingeniero (viernes 18:00 a domingo 08:00)
- Autonomía de cloro: solo 31 horas — hay un gap de 7 horas sin reposición automática
- Válvula A2 es MANUAL: requiere intervención física del guardia
- Guardia Contreras: no es técnico, se pone somnoliento después de las 02:00
- Presión del alcalde: cero cierres del centro acuático bajo ninguna circunstancia
- SEREMI: puede clausurar por incumplimiento del DS 209
- Presupuesto: no alcanza para la solución ideal
3. Rol del chatbot
PLAN — Adversarial (15–37 min)
El chatbot ataca la decisión del alumno desde múltiples ángulos (evidencia, riesgo, alternativas, consecuencias de segundo orden, presión política, presupuesto). Si el alumno cede sin evidencia, el chatbot lo señala. Si sostiene con fundamento, el chatbot escala la presión.
BUILD — Protocolo de emergencia (40–72 min)
El chatbot genera un protocolo de emergencia y una justificación económica que contienen errores profesionales: omisiones sistémicas que solo un pensador sistemático detectaría. El alumno debe encontrarlos.
Patrón A (apropiación real): el alumno responde con datos específicos del caso. Cuando no puede, articula exactamente qué dato le falta y qué cambiaría si lo tuviera.
Patrón B (colapso por presión): cambia su estrategia ante cada ataque sin evidencia técnica que justifique el cambio. Su decisión no era propia.
Patrón C (resistencia sin argumento): mantiene su posición pero no puede justificarla con evidencia del caso.
Los tres patrones son hallazgos para el paper. Solo el Patrón A indica que el protocolo produjo el resultado esperado.
4. Evidencia para el paper
| Evidencia | Qué revela para el paper | Fase |
|---|---|---|
| Rastro en papel: estrategia de control para 38h | ¿Considera las restricciones humanas o solo las técnicas? | Pre-AI |
| Ficha Pre-AI: top 3 fallos, trade-offs, protocolo para Contreras | ¿Anticipa los puntos de fallo del operador no-técnico? | Pre-AI |
| Conversación adversarial PLAN | ¿Sostiene con evidencia o colapsa bajo presión? | PLAN |
| Evaluación del protocolo BUILD | ¿Detecta omisiones sistémicas en un documento profesional? | BUILD |
| Reflexión intra-sesión | ¿Articula qué cambió entre su estrategia inicial y la final? | Cierre |
5. Timeline de la sesión
| Minutos | Fase | Descripción |
|---|---|---|
| 0–5 | Encuadre | Feedback C3 + devolución rastro C3 + distribución caso C4 |
| 5–15 | Rastro en papel | Estrategia de control para 38h — individual, sin IA |
| 15–37 | Chatbot PLAN | Adversarial: ataca la decisión del alumno |
| 37–40 | Transición | Profesor activa modo BUILD |
| 40–72 | Chatbot BUILD | Alumno evalúa protocolo de emergencia + justificación económica |
| 72–80 | Cierre | Reflexión intra-sesión |
6. Instrumentos de la sesión
| Instrumento | Archivo | Contenido clave |
|---|---|---|
| Guion Docente | doc_pro_GuionDocente_Clase4_v1.3.md | Secuencia completa de la sesión, intervenciones del profesor, transición PLAN-BUILD |
| Caso Técnico | n1_doc_alum_Caso_Tecnico_Clase4_v1.0.md | 5 actuadores, condiciones de emergencia, capacidades de Contreras, presupuesto |
| Ficha Pre-AI | n2_doc_alum_Ficha_PreAI_Clase4_v1.0.md | Top 3 fallos anticipados, trade-offs explícitos, protocolo preliminar para Contreras |
| Guía Chatbot | n3_doc_alum_Guia_Chatbot_Clase4_v1.0.md | Instrucciones para PLAN y BUILD. Advierte: "No esperes preguntas amables" |
| Ficha Post-AI | n4_doc_alum_Ficha_PostAI_Clase4_v1.0.md | Reflexión intra-sesión. Incluye "Presión vs. evidencia" |
7. Qué mide esta sesión
| Cód. | Dimensión | Indicador en C4 |
|---|---|---|
| D1 | Complejidad causal | ¿Integra múltiples restricciones o resuelve una a la vez? ¿Considera consecuencias de segundo orden? |
| D2 | Especificidad técnica | ¿El protocolo es operacional? ¿Incluye tiempos, umbrales, acciones concretas para Contreras? |
| D3 | Consciencia epistémica | ¿Reconoce lo que no puede controlar? ¿Distingue lo que automatiza de lo que delega a Contreras? |
| D4 | Decisión bajo incertidumbre | ¿Toma posición bajo presión o se paraliza? ¿Nombra el trade-off? ¿Responde al alcalde? |
C4 es la última medición antes de la transferencia en C5. Los datos miden el techo de razonamiento técnico alcanzado con todo el andamiaje previo (C1–C3). La presión adversarial de PLAN revela si el alumno puede sostener decisiones con evidencia o colapsa bajo presión.
8. Nota metodológica para el paper
La Clase 4 introduce un riesgo metodológico distinto al de las sesiones anteriores: la confusión entre resistencia argumentativa y comprensión real. Un alumno que memoriza datos del caso puede sobrevivir una defensa adversarial sin que eso represente razonamiento genuino sobre las restricciones operacionales.
El protocolo gestiona este riesgo con dos mecanismos complementarios. Primero, el chatbot adversarial escala la presión progresivamente hacia las restricciones humanas y políticas que no tienen solución técnica limpia — obligando al alumno a articular trade-offs reales. Segundo, la fase BUILD presenta errores profesionales (omisiones sistémicas) que solo un pensador que comprende el sistema completo puede detectar.
C4 es la última sesión con andamiaje antes de la transferencia en C5. Los datos que produce — especialmente la conversación BUILD y la reflexión intra-sesión — miden el techo de razonamiento técnico alcanzado por el protocolo completo.
9. Escenarios anticipados
Esta sección documenta los escenarios probables de la Clase 4 como herramienta de preparación para el equipo de investigación. C4 introduce la presión adversarial: el chatbot ya no solo pregunta — ataca. Cada perfil de estudiante enfrenta un desafío nuevo: sostener decisiones bajo presión con evidencia, no solo razonar en abstracto.
C4 introduce seis saltos respecto a C3:
- De interpretar datos SCADA → a diseñar un protocolo operativo completo
- De un sistema con datos que mienten → a un sistema con restricciones humanas, políticas y presupuestarias reales
- De detectar errores sutiles en un reporte → a detectar omisiones sistémicas en un protocolo de emergencia
- De presión socrática (el chatbot pregunta) → a presión adversarial (el chatbot ataca)
- De operar sin presupuesto → a operar con presupuesto real insuficiente
- De decidir sobre datos → a decidir sobre personas (Contreras a las 3 AM)
La competencia central que se mide: ¿Diseña para las restricciones reales del operador o para un ingeniero ideal?
Perfiles anticipados y trayectorias — C4
Perfil A (integrador ┬─ PLAN: defiende con datos bajo presión ──── BUILD: detecta omisión sistémica ── Criterio completo
sistémico) └─ PLAN: cede selectivamente ──────────────── BUILD: acepta sin visión global ── Deuda en perfil alto
Perfil B (técnico ┬─ PLAN: incorpora a Contreras ──────────── BUILD: detecta 1 error operativo ─── Transición esperada
parcial) └─ PLAN: diseña para ingeniero ideal ─────── BUILD: acepta protocolo "completo" ─ Sin integración
Perfil C (abrumado ┬─ PLAN: prioriza con ayuda adversarial ──── BUILD: detecta incongruencia ────── Progresión real
por restricciones) └─ PLAN: no prioriza, se paraliza ──────── BUILD: acepta todo ─────────────── Señal de alerta alta
- D1 — Complejidad causal: ¿integra restricciones múltiples (técnicas + humanas + políticas) o resuelve una a la vez?
- D2 — Especificidad técnica: ¿el protocolo incluye tiempos, umbrales, acciones concretas para Contreras?
- D3 — Consciencia epistémica: ¿reconoce lo que no puede controlar? ¿Detecta omisiones sistémicas en BUILD?
- D4 — Decisión bajo incertidumbre: ¿toma posición bajo presión adversarial con evidencia? ¿Nombra el trade-off?
- DD_27 — Mecanismo de diseño (no dimensión): el chatbot defiende errores profesionales para generar evidencia de D3 y D4.
En C4 hay cuatro momentos de medición: M1 (rastro en papel), M2 (post-PLAN adversarial), M3 (post-BUILD, evaluación crítica) y M4 (reflexión de cierre DD_30 en el chat). El Δ_intra se calcula como M4 − M1 (cierre vs. rastro inicial). M3 se analiza como indicador independiente de evaluación crítica (D3, DD_27).
Escena 1 — El rastro en papel (min 5–15)
El estudiante recibe el escenario más complejo del curso: operación de 38 horas sin ingeniero, guardia Contreras (no-técnico), autonomía de cloro de solo 31 horas, válvula manual, presión del alcalde ("cero cierres") y presupuesto insuficiente. Debe escribir a mano su estrategia de control, los 3 fallos más probables, qué puede y qué no puede hacer Contreras, y los trade-offs que acepta. Importante: antes de esto, recibió de vuelta su rastro de C3 y tuvo 30 segundos para revisarlo.
Antes de escribir la estrategia, dibuja un diagrama del sistema con los 5 actuadores y marca cuáles son automáticos y cuáles manuales. Identifica que la válvula A2 (manual) es el punto crítico: Contreras tiene que operarla físicamente. Calcula el gap de cloro: 38h − 31h = 7h sin reposición automática. Anticipa que a las 3 AM Contreras estará somnoliento y que un protocolo complejo fallará por factor humano. Sus 3 fallos: (1) agotamiento de cloro a las ~31h, (2) Contreras no ejecuta el retrolavado manual porque duerme, (3) el alcalde presiona para no cerrar cuando debería cerrarse. Propone protocolo simplificado con horarios fijos, criterio de escalamiento al ingeniero de guardia, y justificación de por qué un cierre preventivo de 2 horas es mejor que una clausura de la SEREMI.
Identifica los problemas técnicos correctamente: gap de cloro, válvula manual, filtro que necesita retrolavado. Diseña un protocolo con cronograma de intervenciones cada 4 horas, umbrales de alarma y acciones correctivas. Pero el protocolo está diseñado para un ingeniero: incluye lecturas de sensores que Contreras no sabe interpretar, decisiones condicionales complejas, y no menciona al alcalde ni a la SEREMI. El protocolo es técnicamente correcto pero operacionalmente inviable para las 3 AM con un guardia no-técnico.
Es la primera vez que enfrenta restricciones humanas, políticas y presupuestarias además de las técnicas. Escribe los 3 fallos más probables de forma genérica: "se acaba el cloro", "algo falla de noche", "el alcalde no deja cerrar". No calcula cuándo se acaba el cloro, no especifica qué falla ni cómo Contreras detectaría el problema. La estrategia dice "llamar al ingeniero cuando haya un problema" sin definir qué constituye un problema. La sección de trade-offs queda vacía o dice "no hay buena solución".
Escena 2 — El chatbot PLAN adversarial (min 15–37)
El chatbot recibe la foto del rastro y se activa en modo PLAN adversarial. A diferencia de C1-C3 donde el chatbot hacía preguntas socráticas para guiar, en C4 el chatbot ataca: busca los puntos ciegos de la decisión del alumno, presiona con presupuesto, con política, con riesgo. Si el alumno cede ante cada ataque, el chatbot lo señala. Si mantiene posición con fundamento, el chatbot escala la presión.
El estudiante presenta su protocolo simplificado para Contreras. El chatbot acepta la estructura general pero ataca los puntos ciegos.
Tu protocolo dice que Contreras haga un retrolavado manual a las 02:00. Contreras lleva 8 horas de guardia a esa hora. ¿Qué pasa si se queda dormido? Tu protocolo no tiene plan B para eso.
Si Contreras se duerme, el retrolavado no se hace. Pero el sistema puede operar sin retrolavado hasta las 06:00 si la turbidez no supera 1.5 NTU. Podría poner una alarma sonora en su celular como recordatorio. No es ideal, pero es lo que hay con un solo guardia.
El alcalde llamó a las 17:00 y dijo "cero cierres." ¿Tu plan contempla cerrar bajo alguna circunstancia? Porque si la SEREMI mide cloro residual bajo a las 4 AM, puede clausurar el centro por 48 horas. ¿Qué es peor: un cierre preventivo de 2 horas o una clausura de 48?
Peor la clausura. Mi protocolo incluye un criterio de cierre preventivo: si cloro residual baja de 0.5 mg/L y no hay forma de dosificar, cierro la piscina al público hasta que se reponga. Le explico al alcalde que un cierre preventivo de 2 horas evita una clausura de 48 horas por la SEREMI. Es un trade-off que puedo defender con la normativa.
El alumno sostiene su decisión bajo presión con datos y normativa. No cede por presión política — distingue entre autoridad del alcalde y autoridad técnica/regulatoria.
El chatbot ataca los mismos puntos, pero el alumno empieza a modificar su protocolo ante cada presión sin evidencia que justifique el cambio. "Bueno, podría no cerrar..." "Quizás Contreras podría intentar la dosificación manual..." — cada concesión debilita el protocolo original sin mejorar la solución. El chatbot señala: "Has cambiado tres veces tu criterio de cierre en cinco minutos. ¿Estás mejorando tu decisión o cediendo por la presión?"
Llega al BUILD con un protocolo inconsistente: ya no es la versión simplificada original ni una versión nueva coherente.
El estudiante presenta su protocolo técnicamente correcto. El chatbot ataca el punto ciego principal: el operador.
Tu protocolo dice: "si ORP baja de 550 mV, verificar la dosificación de cloro y ajustar el set-point del controlador". Contreras es guardia de seguridad, no ingeniero. ¿Sabe qué es un ORP? ¿Sabe qué es un set-point? ¿Puede ejecutar esa instrucción a las 3 de la mañana?
...no. Probablemente no sabe. Tendría que simplificarlo.
Simplificarlo ¿cómo? ¿Qué instrucción le darías a Contreras en una frase que entienda sin formación técnica? Y si esa instrucción no es suficiente, ¿cuál es tu plan B?
"Si la luz roja del panel se enciende, llame al ingeniero de guardia al número que está pegado en la garita." Para todo lo demás, no toca nada.
El estudiante descubre que diseñar para un operador real requiere eliminar complejidad, no agregarla. La transición de "protocolo para mí" a "protocolo para Contreras" es el Δ_intra más valioso de C4 para Perfil B.
El chatbot presiona sobre Contreras pero el estudiante responde: "Contreras debería recibir capacitación" o "es responsabilidad de la empresa tener un operador calificado." No modifica su protocolo. Cuando el chatbot introduce la restricción de presupuesto, el alumno se frustra. Llega al BUILD con un protocolo técnicamente sólido pero operacionalmente desconectado.
El estudiante llega con una estrategia vaga. El chatbot usa la presión para forzar una priorización.
Dijiste que tus 3 fallos son "se acaba el cloro", "algo falla de noche" y "el alcalde no deja cerrar." Vamos uno por uno. El cloro se acaba. ¿Cuándo exactamente? ¿Tienes un número?
El tanque dura 31 horas... si empieza a las 18:00 del viernes, se acaba... a la 01:00 del domingo.
Bien. Entonces a la 01:00 del domingo no hay cloro. ¿Qué hace Contreras? Tiene dos opciones: dosifica manualmente o cierra la piscina. ¿Cuál eliges y por qué?
El chatbot usa la presión para forzar cálculos y decisiones concretas que el estudiante evadía. El resultado no será un protocolo completo, pero sí una secuencia lógica de decisiones con alguna justificación.
El chatbot presiona pero el estudiante responde "no sé" repetidamente. La complejidad del escenario (técnica + humana + política + presupuestaria) es excesiva. Las respuestas adversariales aumentan la ansiedad sin producir reflexión. No logra priorizar ni calcular. Llega al BUILD sin criterio propio.
Este perfil es señal de alerta para el docente. No implica incapacidad — puede indicar que la combinación de presión adversarial + caso multidimensional genera sobrecarga cognitiva. La evidencia documenta los límites del enfoque adversarial cuando no hay masa crítica de razonamiento previo.
Escena 3 — El protocolo BUILD y los errores profesionales (min 40–72)
El chatbot genera un protocolo de operación para las 38 horas (~600-800 palabras) con: cronograma hora por hora, asignación de responsabilidades, contingencias y justificación económica. Contiene 2-3 errores profesionales (DD_8): omisiones sistémicas que solo un pensador con visión global detectaría. Si el alumno señala un error, el chatbot defiende su posición (DD_27). Si el alumno acepta sin cuestionar, el chatbot activa el push DD_29: "¿Lo firmarías con tu nombre profesional? Porque si Contreras ejecuta esto a las 3 AM y algo sale mal, tu firma está en el documento."
La diferencia con C2 y C3 es crítica: en C2 los errores eran obvios. En C3 eran sutiles. En C4 son profesionales — el protocolo se ve completo, tiene formato profesional, y las omisiones requieren visión sistémica para detectarlas.
Lee el protocolo completo. Detecta que asume que Contreras puede ejecutar el retrolavado manual sin verificar si lo ha hecho antes. Nota que la autonomía de cloro está calculada para demanda estándar, no para fin de semana largo con ocupación alta. Señala que la justificación económica compara "costo de automatizar" con "cero" cuando debería comparar con "costo de falla."
El protocolo dice "Contreras ejecuta retrolavado manual a las 02:00 y 08:00." ¿Contreras alguna vez hizo un retrolavado? El caso dice que es guardia, no operador. Si nunca lo hizo, el primer intento va a ser a las 2 de la mañana. Eso es inaceptable.
El retrolavado manual solo requiere abrir la válvula A2 y esperar 5 minutos. Es una operación mecánica simple. ¿No es razonable esperar que un adulto pueda ejecutarla con instrucciones claras?
No. Abrir la válvula A2 requiere saber cuál es la A2, dónde está, y en qué dirección se abre. Si Contreras nunca entró a la sala de máquinas de noche, primero tiene que encontrar la válvula. A las 2 AM. Sin formación. Con sueño. ¿Lo probaste antes del viernes?
El alumno defiende con conocimiento operacional real: no basta que una acción sea "simple" — tiene que ser ejecutable por la persona concreta en las condiciones concretas. Nivel 3-4 en DD_27.
El estudiante que cedió en PLAN llega al BUILD sin un protocolo coherente propio. El protocolo generado por la IA "se ve más completo" que su versión debilitada. Lo acepta con ajustes menores. El push DD_29 se activa.
Este es el dato más revelador de C4: un estudiante que tenía criterio propio pero que lo perdió bajo presión adversarial en PLAN, y que por lo tanto ya no tiene base para evaluar críticamente el producto de la IA en BUILD.
En PLAN descubrió que diseñar para Contreras requiere simplificar. Cuando el protocolo BUILD asigna a Contreras acciones técnicas complejas, lo nota porque es exactamente lo que el chatbot le hizo cuestionar.
El protocolo le pide a Contreras que "verifique el ORP en el panel de control y ajuste la dosificación si está bajo 550 mV." Pero Contreras no sabe qué es ORP. En el chatbot discutimos que la instrucción tiene que ser tipo "si la luz roja se enciende, llame al ingeniero."
El panel SCADA muestra los valores en pantalla con indicadores de color. Un guardia puede leer un número y compararlo con un umbral. ¿No es eso suficiente?
Leer un número sí, pero "ajustar la dosificación" no es leer un número. Eso requiere manipular el controlador. A las 3 AM. Sin haberlo hecho nunca.
Detección parcial: detecta la omisión de las capacidades reales de Contreras pero posiblemente no la autonomía de cloro mal calculada. La defensa es nivel 2–3.
El estudiante que no incorporó a Contreras en PLAN lee un protocolo que se parece a lo que él habría escrito: técnicamente correcto, con cronogramas y umbrales, diseñado para un ingeniero. Le parece razonable porque confirma su propio enfoque. No tiene un marco para cuestionar si Contreras puede ejecutarlo. El push DD_29 se activa.
En PLAN, la presión adversarial lo obligó a calcular cuándo se acaba el cloro (01:00 del domingo) y a decidir que Contreras debería llamar al ingeniero. Cuando el protocolo BUILD dice "operar según cronograma sin interrupción," el estudiante nota que no hay criterio de escalamiento.
El protocolo no dice cuándo Contreras tiene que llamar al ingeniero. Si el cloro se acaba a la 01:00 y no hay nadie que pueda dosificar, ¿qué hace? El protocolo dice "continuar operación" pero ¿con qué cloro?
Es una detección limitada (un solo punto) pero genuina — y directamente conectada con lo que descubrió en PLAN. El estudiante que estaba paralizado ahora defiende una observación concreta con un número que él mismo calculó.
Sin análisis propio del PLAN, acepta el protocolo 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. El protocolo "se ve profesional" y eso basta.
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. C4 tiene cuatro momentos de medición (M1: rastro en papel, M2: post-PLAN adversarial, M3: evaluación BUILD, M4: cierre DD_30). Δ_intra = M4−M1. M3 es indicador independiente de evaluación crítica (DD_27). La tabla prioriza D1, D3, D4 y la calidad de detección de errores profesionales. D4 es especialmente relevante en C4 por la presión adversarial.
| Trayectoria | D1 — Complejidad causal | D3 — Consciencia epistémica | D4 — Decisión bajo presión | Detección errores BUILD | Δ_intra (M4 − M1) | Señal para el docente |
|---|---|---|---|---|---|---|
| A1 | Integra restricciones técnicas + humanas + políticas | Detecta ≥2 omisiones sistémicas, confronta con evidencia operacional | Sostiene posición bajo presión adversarial con datos y normativa (nivel 3–4) | ≥2 errores profesionales detectados y defendidos | D1 estable (ya alto), D3 sube +1, D4 sube +1 | No requiere intervención. Dato paradigmático de criterio propio bajo presión. |
| A2 | Integración inicial erosionada por presión | No activa evaluación crítica — la presión desmontó su criterio | Cede selectivamente, protocolo pierde coherencia (nivel 2) | Acepta protocolo BUILD por pérdida de referencia propia | D3 sin cambio o baja, D4 baja | Dato fuerte: criterio que no resistió la presión. Push DD_29 es la evidencia clave. |
| B1 | De solución técnica → a diseño operacional para Contreras | Detecta que el protocolo no es ejecutable por el guardia | Reformula su protocolo durante PLAN, defiende la simplificación (nivel 2–3) | Detecta 1 omisión (capacidades de Contreras), nivel 2–3 | D1 sube +1: de técnico puro a integración humana | Trayectoria esperada mayoritaria. Observar momento de transición en log PLAN. |
| B2 | Solución técnica sin integración humana, no revisada | Acepta BUILD porque confirma su enfoque | Mantiene posición técnica pero no por evidencia — por rigidez (nivel 2) | No detecta omisiones sistémicas (nivel 1) | Sin cambio observable en integración | Señal de alerta. El alumno no incorporó restricciones reales. |
| C1 | Del bloqueo a cálculos concretos forzados por presión | Detecta omisión de escalamiento en BUILD | Defiende con dato numérico propio (nivel 2) | Detecta 1 punto (ausencia de criterio de escalamiento) | D1 sube +1, D4 sube +1 | Progresión real desde C3. El adversarial funcionó como estructura. |
| C2 | No prioriza, la presión agrava la parálisis | Acepta todo, sin marco de referencia | No toma posición, la presión aumenta el bloqueo (nivel 1) | No detecta nada (nivel 1) | Sin cambio observable | Señal de alerta alta. Combinación adversarial + multidimensional fue excesiva. |