¿Cuándo dos actividades son la misma?
El plan.
Tres objetivos, cada uno con su pregunta, su método, su entregable, su calendario y su criterio de «listo».
Un plan
El método algorítmico de equivalencia entre una actividad en Protobject y su versión en micro:bit está implementado, ejecutado y verificado sobre las 17 actividades. Este documento define el trabajo de investigación en tres líneas paralelas.
El trabajo se organiza en tres objetivos. Cada objetivo se describe con la misma plantilla: pregunta, entregable, método, cuándo, listo cuando. Cada uno tiene su propia página con el protocolo detallado, las preguntas abiertas y los puntos de partida en la literatura. Cada decisión pendiente se marca como pregunta abierta, con una propuesta.
Para hacer sesiones con participantes, el punto de entrada es el Objetivo 1 y su página. Para trabajar con la pipeline, el Objetivo 2 y la página de constantes y unidades. Para la revisión de literatura sobre la experiencia, el Objetivo 3. El marco y las reglas de trabajo son lectura común.
Los hechos sobre los que se apoya el plan
| Qué | Hecho | Consecuencia para el plan |
|---|---|---|
| Pipeline algorítmica | ejecutada Extracción determinística desde .ptj/.hex → abstracción con LLM (AST → ontología canónica común → PDG) → cálculo determinístico (isomorfismo VF2 + GED). | El método existe como código en reporte/scripts/. El runbook para re-ejecutarlo es prompt.md. |
| Resultado sobre las 17 | 17/17 isomorfas, GED 0 (19-09-2026, con las reglas simplificadas): en cada actividad, las dos versiones tienen los mismos nodos y las mismas aristas. Antes, el 17-08-2026, también 17/17, con las reglas anteriores. | Todo el corpus vigente es equivalente según la pipeline. Validarla exige pares que la pipeline juzgue no equivalentes. Ese es el Objetivo 2. |
| Reglas de la pipeline | simplificadas (19-09-2026) Cuentan el tipo de nodo, el operador, el eje del sensor y las dependencias entre bloques. No cuentan el color (A), el nombre del dispositivo (B), las constantes (D; pero redondear ≠ redondear al alza) ni el orden entre instrucciones independientes (E). Se quitaron tres reglas que ya no hacen falta: «ejes x/y indiferentes», «Hz y nota = misma altura» y «sonido por intención», que era la regla C. La regla C dice ahora solo que todo sonido es un tono (tocar y detener), y su altura es una constante más (regla D). La ontología, curada a mano, pasó de 39 a 29 nodos, todos usados. | Es la especificación (reglas A–E) que recibe el panel del Objetivo 2. El detalle está en prompt.md. |
| Regla del decodificador | permanente Una diferencia que parece de operador se verifica en la fuente (main.ts, XML de Blockly), porque la etiqueta extraída puede tener un error del decodificador. | Vale también para el ground truth: los expertos juzgan la fuente. |
| Alineación del autor | 17/17 revisadas El 18 y 19 de septiembre de 2026 el autor revisó una por una las 17 parejas Protobject ↔ micro:bit y las dejó, según su criterio, «percibidas y algorítmicamente equivalentes»; las diferencias que quedan están en la fila siguiente. Su principio: mismos bloques, en el mismo orden y con los mismos operadores en las dos plataformas; las diferencias entre plataformas van solo en los números (constantes o valores de variables). Por eso rechazó dos cambios de estructura en un solo lado: agregar bloques «retraso de 400» (16.5) y cambiar un operador (16.7). Todo sonido es ahora un tono en las dos plataformas: ya no quedan clips grabados ni golpes de batería. La app de Protobject cambió el signo del eje x para que coincida con el del micro:bit, y el micro:bit se monta igual que el celular. | El principio es el de la regla D: cuenta el operador, no la constante. Las constantes de calibración (unidades de la inclinación, los 400 ms de «mostrar LEDs») están en la página de constantes y unidades. Las versiones anteriores a la alineación quedan en el historial de git, de donde el Objetivo 2 toma sus candidatas a no equivalentes. |
| Auditoría de diferencias percibidas | quedan diferencias (18-09-2026) Una revisión automática de solo lectura, hecha con varios agentes LLM, comparó los dos programas de cada actividad según lo que hace de verdad cada bloque (verificado en el código de la app de Protobject y en pxt-microbit). De 75 diferencias candidatas, un verificador escéptico confirmó 70 y rechazó 5; el autor quitó otras 5 porque dependen del montaje (gestos, ejes, sentido). El autor revisó las demás una por una y alineó la mayoría. Quedan: el timbre; la detección del ruido; los umbrales, que el autor fija de forma empírica; los 400 ms del primer «mostrar LEDs» cuando no hay una pausa previa donde absorberlos; el paso de los bucles (20 contra 33 ms); la latencia de red y el muestreo de los sensores en Protobject; y el sonido de Protobject, que no funciona en iPhone. | La pipeline no ve estas diferencias: son las candidatas para el instrumento del Objetivo 3. La última toca también las sesiones del Objetivo 1: el sonido de Protobject necesita un celular Android o un computador. |
| Crítica externa a la pipeline | abierta Tres modelos de lenguaje criticaron la pipeline. Dos críticas tienen respuesta: el tratamiento de las constantes (una constante de calibración deja el algoritmo intacto) y la equivalencia Hz ≡ nota MIDI (significativa, resuelta en el diseño: donde el tono se calcula, en los xilófonos, las dos plataformas tocan en hercios; desde el 19-09-2026 una nota fija es una constante más, regla D). El registro de esas conversaciones se archiva en la carpeta del proyecto. | Ambas tienen su página propia. La segunda fija lo que la pipeline debe reportar. |
| Marco de dimensiones | definido Marco de seis dimensiones: algorítmica, interactiva, material, sensoriomotriz, estética y configuración social. | El Objetivo 3 trabaja sobre las dimensiones interactiva, material, sensoriomotriz y estética. |
Seis dimensiones, un perfil
La equivalencia es un perfil. Dos actividades se comparan dimensión por dimensión. En cada una la pregunta es la misma: ¿una niña o un niño viviría las dos versiones como la misma actividad? Cinco dimensiones viven en el artefacto; la sexta se iguala al desplegar la actividad en la sala. El conjunto está abierto.
| Dimensión | La pregunta | Cómo se aborda | Estado |
|---|---|---|---|
| Algorítmica | ¿Los dos programas computan lo mismo, con la misma estructura de control y de datos? | Pipeline (ontología → PDG → VF2/GED), módulo plumbing de plataforma. | método listo validación = O2 |
| Interactiva | ¿Corren el mismo ciclo sentir–actuar: los mismos tipos de entrada captada y de salida producida, con el mismo tipo de mapeo? | Ideas de partida: tabla sentir–actuar por actividad; firma de entrada/salida emitida por la pipeline; registro del comportamiento de las dos versiones ante el mismo gesto. Es la única dimensión que puede fallar sin remedio: un celular carece de motores. | implícita en la ontología explicitarla = O3 |
| Material | ¿Los dos artefactos comparten la misma materialidad como objetos: el mismo material, trabajado igual, por la misma mano? | Ideas de partida: el mismo cartón en las dos versiones; un bloque impreso en 3D del tamaño y el peso de un celular, con alojamiento para la micro:bit; una lista de inspección antes del uso. | controlable residuo: masa |
| Sensoriomotriz | ¿Le piden lo mismo al cuerpo y le devuelven lo mismo a los sentidos? | Ideas de partida: ítems comparativos puntuados por quienes hacen la actividad; medidas instrumentadas (rango de inclinación, latencia, nivel sonoro); prueba de discriminación (¿cuál de tres es distinto?). | por construir O3 |
| Estética | ¿Se perciben como comparables en forma y terminación? | Ideas de partida: escala corta de estética percibida, dentro de cada persona; tarjetas de reacción; preferencia por pares. | por construir O3 |
| Configuración social 6.ª condición | ¿Cuántos artefactos por grupo y cuántas manos pueden actuar a la vez? | Se iguala en el despliegue. | control de diseño |
Criterio de entrada al perfil. Una propiedad entra en el perfil si puede diferir entre las dos versiones a causa del aparato y, al diferir, confundiría la comparación. Colaboración, integración con la tarea y accesibilidad son controles del estudio: las fijan el guion de la actividad, el grupo y la sala, idénticos en las dos versiones. Material y sensoriomotriz son separables, porque se disocian en ambos sentidos: dos carcasas del mismo cartón pueden exigir inclinaciones muy distintas, y el mismo gesto puede darse con materiales distintos. Las dos se filtran una en otra en la masa y el tamaño. Un celular (≈ 170 g) pesa entre cuatro veces (micro:bit con su portapilas, ≈ 40 g) y veinte veces (la placa sola, ≈ 9 g) lo que la placa, y la carcasa hereda esa diferencia. Para igualar la masa, la versión micro:bit usa exactamente el mismo cartón que la versión celular y, dentro, un bloque impreso en 3D del tamaño y el peso de un celular, con un alojamiento para la micro:bit. Así la placa queda tan grande y pesada como el celular y entra en la misma carcasa. El residuo se mide en balanza, artefacto completo.
El fundamento teórico de la dimensión algorítmica —por qué el AST es insuficiente, qué es una representación intermedia, qué es un grafo de dependencias, cómo se comparan— está en la Parte I del ensayo.
Tres objetivos, una misma plantilla
Mejorar las actividades antes de que lleguen a la escuela
¿Qué hay que cambiar en cada actividad —texto, código, plan de lección, modelo de cartón— para que llegue a niñas y niños de 12–13 años ya optimizada?
- Entregable
- Para cada actividad probada, una lista de áreas de mejora con evidencia (la nota del participante, la diapositiva, la duda), priorizada por severidad y frecuencia. Las mejoras implementadas en
.md,.ptj/.hex, presentación y plan de lección, con registro de cambios. Un corpus v2 estable E1 y E2 («Enciende un corazón», «El corazón parpadeante») incluidas. - Método
- Evaluación formativa: sesiones individuales con estudiantes universitarios que siguen la presentación, hacen la actividad y anotan todo lo que no les queda claro; cinco minutos de conversación sobre las notas; síntesis; decisión; implementación; nueva prueba de lo cambiado. Dos pistas: mixta (informática y otras disciplinas) para las actividades de entrada; solo informática para las avanzadas.
- Cuándo
- Hasta el 25 de septiembre: protocolo y reclutamiento. Fines de septiembre y octubre: ronda 1 (mixta primero, informática después). Noviembre: mejoras y ronda 2. Diciembre: corpus v2.
- Listo cuando
- Toda actividad del corpus, E1 y E2 incluidas, fue hecha por cuatro a cinco personas en sesión formativa; las áreas de severidad alta están implementadas y re-probadas; todo cambio de código pasó de nuevo por la pipeline con veredicto equivalente; el registro de cambios se entiende sin haber estado en las sesiones.
Página del Objetivo 1 → protocolo de sesión, pistas de participantes, matriz de cobertura, taxonomía de incidentes, preguntas abiertas, puntos de partida.
Un ground truth humano para la equivalencia algorítmica
Dados los mismos criterios de equivalencia —la especificación que usa la pipeline—, ¿coincide el veredicto de expertos humanos con el de la pipeline? ¿Dónde divergen, y qué dice eso de la especificación?
- Entregable
- (1) Un corpus etiquetado: pares de programas con veredicto experto, justificación y regla aplicada, mitad equivalentes y mitad no. (2) Las medidas de acuerdo: entre expertos, y entre expertos y pipeline (y entre expertos y un LLM que juzga directamente), con matriz de confusión y análisis de los desacuerdos regla por regla. (3) El recuento de cuánto aporta el grafo de dependencias frente a una comparación línea a línea sobre el mismo vocabulario canónico. (4) Un manuscrito: el método de equivalencia algorítmica validado contra el juicio de expertos que aplican la misma especificación.
- Método
- Construir el corpus con los 17 pares vigentes (equivalentes) y con revisiones del historial de git de las actividades (candidatas a no equivalentes), más variantes controladas; cada par con una etiqueta esperada fijada antes del panel. Panel de expertos calibrado con la misma especificación escrita (reglas A–E). Juicio ciego e independiente; resolución de desacuerdos; etiqueta de oro sellada antes de las corridas. Pipeline y LLM-juez corren sobre los mismos pares con la misma especificación; se comparan.
- Cuándo
- Septiembre–octubre: especificación y corpus. Octubre: juicios; inicios de noviembre: resolución de desacuerdos. Noviembre: corridas y análisis. Diciembre: borrador.
- Listo cuando
- ≥ 40 pares de ≥ 12 actividades distintas, etiquetados por ≥ 4 expertos, con acuerdo entre ellos reportado (con el mínimo de 30 pares y 3 expertos el entregable se enmarca como estudio piloto); criterio de éxito escrito y fechado antes de la primera corrida; pipeline y LLM-juez corridos ≥ 3 veces sobre todos los pares; acuerdo humano–pipeline con intervalo de confianza; cada desacuerdo con una explicación de una línea que apunta a una regla.
Página del Objetivo 2 → diseño del corpus, la especificación, el protocolo del panel, las condiciones LLM, las métricas, las amenazas, preguntas abiertas, puntos de partida.
Un instrumento para las dimensiones interactiva, material, sensoriomotriz y estética
¿Con qué metodología se decide si dos versiones de una actividad son la misma en las dimensiones interactiva, material, sensoriomotriz y estética, y cómo se sabe que el instrumento mide lo que dice medir?
- Entregable
- (1) Una revisión de literatura orientada: por cada dimensión, al menos dos métodos candidatos —las ideas de partida y los que aparezcan en la búsqueda—, con fuente y una razón escrita a favor o en contra. (2) Un protocolo v1 armado con los métodos elegidos. (3) Un piloto sobre 3–5 pares con tres o más evaluadores y pares de control, incluido un control nulo. (4) El borrador de la segunda contribución.
- Método
- Explorar las ideas de partida, buscar alternativas en la literatura, probar las candidatas en pequeño, elegir con una razón escrita, armar el protocolo y pilotearlo con controles.
- Cuándo
- Septiembre–octubre: búsqueda y prueba de alternativas. Noviembre: protocolo v1 y piloto sobre el corpus v2 congelado. Diciembre: descripción del piloto y borrador.
- Listo cuando
- Cada dimensión tiene al menos dos métodos candidatos con fuente y uno elegido con su razón; un evaluador nuevo aplica el protocolo v1 sin ayuda; el piloto muestra que los ítems se entienden y discriminan, que el procedimiento cabe en el tiempo previsto, que los controles se detectan y que el control nulo queda sin diferencias.
Página del Objetivo 3 → las dimensiones una por una, ideas de partida y alternativas, dónde buscar, el piloto, preguntas abiertas, puntos de partida.
Tres objetivos que se alimentan
- O1 produce el corpus que O2 y O3 necesitan. Cada mejora de código cambia un par. El par mejorado vuelve a pasar por la pipeline, y la revisión que lo precede queda en git como candidata a «no equivalente». Las mejoras se implementan en noviembre, así que esas revisiones forman una segunda ola del corpus, juzgada en noviembre–diciembre o reservada para una réplica. Las sesiones de O1 son también el semillero de evaluadores para el piloto de O3, que se hace en sesión aparte sobre el corpus v2 congelado.
- O2 valida lo que la pipeline afirma. O2 contrasta el resultado «17/17 equivalentes» con un ground truth humano. El contraste dice si la pipeline reproduce el juicio de expertos que aplican la misma especificación. La validez de la especificación misma es una pregunta aparte; por eso el protocolo pide un juicio previo sin reglas. Es la primera contribución publicable.
- O3 cubre las dimensiones interactiva, material, sensoriomotriz y estética. La pipeline decide solo la dimensión algorítmica. Las otras cuatro necesitan un instrumento propio, porque hay diferencias que la pipeline borra correctamente (una constante de calibración) y que cambian lo que el niño ve u oye. La página de constantes y unidades reúne esos casos.
- Las dos críticas a la pipeline atraviesan O2 y O3. Las constantes y las unidades del sonido son el tipo de regla que el panel de expertos de O2 pone a prueba, y el tipo de divergencia que el instrumento de O3 debe detectar.
Segundo semestre 2026, en paralelo
Quincenas desde el 14 de septiembre. Las tres líneas avanzan a la vez. Los puntos de sincronización son las mejoras de código (O1 → pipeline → O2) y el piloto de O3 sobre las sesiones de O1.
| 14–25 sep | 28 sep–9 oct | 12–23 oct | 26 oct–6 nov | 9–20 nov | 23 nov–4 dic | 7–18 dic | |
|---|---|---|---|---|---|---|---|
| O1 · mejorar | protocolo, materiales, reclutar | sesiones ronda 1 (mixtas, primeras actividades) | sesiones ronda 1 (informática, avanzadas) | síntesis de incidentes · implementar mejoras · pipeline | sesiones ronda 2 (actividades cambiadas) | cierre de cambios · pipeline | corpus v2 + registro |
| O2 · ground truth | especificación escrita · corpus desde git | variantes controladas · material para expertos · reclutar panel | calibración · juicios independientes | resolución de desacuerdos · etiqueta de oro · corridas pipeline | corridas LLM-juez · acuerdo | análisis de desacuerdos por regla | borrador manuscrito 1 |
| O3 · experiencial | búsqueda de ideas y alternativas por dimensión | búsqueda de ideas y alternativas por dimensión | prueba de alternativas en pequeño | protocolo v1 | ajustes · reclutar evaluadores | piloto (sesión aparte, corpus v2 congelado) · revisión | borrador manuscrito 2 |
| Sincronización | O2 toma de git las versiones vigentes y las históricas | O1 fija cuántas actividades por sesión se hacen también en micro:bit, antes del 26 oct | se regeneran los derivados y se re-ejecuta la pipeline; las revisiones de git que preceden a las mejoras de O1 van a la segunda ola de O2 | O3 recluta entre los participantes de O1; corpus v2 congelado (commit) | revisión conjunta |
Las reglas comunes
- Las actividades se modifican solo en la fuente. Se editan
.ptj,.hex, los.mdy los planes de lección. Los derivados de extracción (textos extraídos, XML, bloques,.ts) se regeneran con los cuatro comandos de extracción (gen-text-json.js,decode_ptj.py,decode_blocks.py,decode_hex.py). Los PDG y las métricas se regeneran re-ejecutando la pipeline según el runbookprompt.md. Un derivado no regenerado no se cita. - La presentación es la clave del material. Cada actividad se hace siguiendo la presentación que genera el sitio de Protobject («Presenta»). Con esa presentación se prueba la actividad en Protobject. La versión micro:bit es la misma presentación, con las variaciones mínimas para hacerla compatible. Toda mejora de texto se aplica en la fuente de la presentación y pasa así a las dos versiones.
- Toda modificación de código se hace en las dos plataformas, y toda modificación de material en las dos presentaciones. Las dos versiones usan los mismos bloques, en el mismo orden y con los mismos operadores; lo que cada plataforma exige distinto va solo en los números (principio del autor, septiembre de 2026). El código vuelve a pasar por la pipeline. Una mejora que rompe la equivalencia se discute antes de aplicarse.
- Las diferencias se verifican en la fuente. Una divergencia que parece de operador o de constante se confirma en
microbit/decoded/<slug>.tsy enprotobject/raw/<code>.xml. - Ninguna actividad menciona a otra. La progresión está en el orden. El vocabulario es el del español de Chile: celular, computador, ampolleta.
- Las decisiones se escriben. Cada regla de la especificación, cada umbral, cada mejora aceptada o rechazada, con fecha y razón. La respuesta a «¿por qué X mapea a Y?» está en un archivo.
- Verificación adversarial por defecto. Un hallazgo (un incidente, una divergencia, un desacuerdo) se reporta con la prueba textual y se intenta refutar antes de aceptarlo. Entra solo si sobrevive.
- Toda publicación requiere aprobación ética. Toda sesión cuyos datos puedan entrar en un manuscrito (el piloto de O3 siempre; O1 si se cita) se somete al Comité Ético Científico antes de empezar, también con participantes adultos, con consentimiento informado en la plantilla del comité. Con menores se suma el consentimiento de apoderados; el piloto en colegio se planifica aparte. La unidad de ética de la facultad confirma el procedimiento en septiembre.
Dónde está cada cosa
Mejorar las actividades
Evaluación formativa con estudiantes universitarios: protocolo, notas de los participantes, pistas mixta e informática, incidentes, severidad, ciclo de mejora.
Ground truth de equivalencia algorítmica
Corpus con positivos y negativos, especificación, panel de expertos, acuerdo humano–pipeline y humano–LLM.
Equivalencia experiencial
Las dimensiones una por una, ideas de partida y alternativas, dónde buscar, el piloto.
Constantes y unidades del sonido
Una constante de calibración deja el algoritmo intacto; Hz ≡ nota MIDI es significativo; qué debe reportar la pipeline.
El ensayo
AST, representación intermedia, PDG, isomorfismo y GED: la base conceptual de la pipeline.
Dashboard de equivalencia
Las 17 actividades con extracción, AST, ontología común, PDG y métricas. El runbook está en prompt.md.
Plan de acción de equivalencia — Protobject ↔ micro:bit · septiembre 2026 · actualizado el 19-09-2026
Tipografías: Fraunces · Newsreader · JetBrains Mono