2 Documento técnico de la base ERCE 2025

2.1 Introducción

Este documento corresponde al entregable del Mes 1 de la consultoría asociada al análisis cuantitativo del estudio ESD/GCE ERCE 2025. Su propósito es presentar de manera clara, completa y defendible la metodología utilizada para consolidar y validar la base de datos que servirá como soporte de las etapas analíticas posteriores. En este sentido, la entrega M1 cumple una función fundacional dentro del proyecto: antes de interpretar resultados, comparar países o construir indicadores agregados, era necesario garantizar que el corpus estuviera ordenado, que las unidades de análisis fueran consistentes y que las reglas de procesamiento estuvieran explícitamente documentadas.

La relevancia de esta etapa deriva de una premisa básica del trabajo cuantitativo: los análisis sólo son tan confiables como la base sobre la cual descansan. Cuando los datos provienen de múltiples archivos, hojas, módulos y convenciones de codificación, la producción de una base consolidada deja de ser una tarea secundaria y pasa a ser una condición de posibilidad del análisis mismo. En ese contexto, el objetivo de esta entrega no fue generar conclusiones sustantivas sobre la presencia o distribución de contenidos ESD/GCE, sino construir la infraestructura metodológica que permitirá producirlas de manera válida en los meses siguientes.

En coherencia con los términos de referencia de la consultoría, esta entrega incluye cuatro componentes centrales: la metodología de consolidación de bases de datos, la documentación de decisiones de curatoría y procesamiento, el libro de códigos de la base final y un conjunto de descriptivos univariados que permiten caracterizar el resultado de la consolidación. El valor de este documento reside, por tanto, en explicar no sólo qué producto final existe, sino también por qué puede considerarse confiable, cómo fue construido y qué controles permiten sostener esa afirmación.

2.2 Antecedentes y problema a resolver

El punto de partida del trabajo fue un corpus compuesto por once módulos temáticos: DDHH, ECM, EDS, ESI, Género, HSE, HSE Respeto, PAZ, Pilares actitudinal, Pilares cognitivo y Salud. Estos módulos estaban asociados a distintos archivos fuente y, en algunos casos, a distintas hojas dentro de un mismo libro. El snapshot de referencia utilizado para el run full correspondió al corte 20260225_1928, lo que permitió trabajar sobre un universo estable de insumos y fijar un punto común para todo el proceso posterior.

La heterogeneidad del corpus no era un problema meramente estético o de formato. En la práctica, implicaba que columnas conceptualmente equivalentes podían aparecer con nombres distintos, que un mismo libro podía contener más de una hoja relevante, que algunas cabeceras estuvieran duplicadas o parcialmente vacías, y que ciertos vacíos obedecieran no a ausencia real de información, sino a la lógica visual de celdas combinadas en los archivos de origen. Además, algunos módulos compartían un mismo archivo fuente, mientras que otros requerían inferencias controladas para identificar adecuadamente la hoja o el segmento relevante.

En un nivel más concreto, el problema inicial puede describirse como un desajuste entre el modo en que la información estaba almacenada y el modo en que debía estar organizada para poder ser analizada. Los archivos de origen estaban pensados para contener información curricular y de codificación, pero no necesariamente para operar como una base consolidada de análisis cuantitativo. Esa diferencia es decisiva. Un archivo puede ser útil para lectura humana y, al mismo tiempo, ser riesgoso para el procesamiento si contiene ambigüedades estructurales, vacíos heredados del formato visual, duplicaciones no resueltas o registros cuya señal codificada no puede vincularse de forma confiable con una evidencia textual legible.

Desde el punto de vista analítico, mantener los insumos tal como estaban implicaba varios riesgos. El primero era el riesgo de sobreconteo o subconteo: si existían duplicados no resueltos o filas separadoras tratadas como observaciones reales, los descriptivos y frecuencias podían distorsionarse. El segundo era el riesgo de pérdida de trazabilidad: si no existía una llave operativa estable para seguir cada registro a través de las distintas transformaciones, se debilitaba la posibilidad de auditar el proceso completo. El tercero era el riesgo de comparación inválida: si los indicadores no compartían un dominio común o si columnas análogas estaban definidas de forma distinta entre módulos, cualquier intento de producir síntesis comparables podía volverse metodológicamente frágil. Finalmente, existía un riesgo de opacidad: incluso si el procesamiento lograba “funcionar”, sin documentación explícita de las decisiones sería difícil defender por qué determinadas reglas fueron aplicadas y otras descartadas.

Por estas razones, la primera necesidad del proyecto era ordenar el soporte empírico. Antes de responder preguntas sustantivas, había que resolver una pregunta más básica: cómo transformar un conjunto de insumos heterogéneos en una base única que preservara la información original, pero eliminara las ambigüedades estructurales que impedían su uso analítico directo.

2.3 Enfoque metodológico general

El principio rector del trabajo fue ordenar sin alterar el contenido sustantivo. Esto significa que la consolidación no fue entendida como una intervención destinada a modificar la información, sino como un proceso de estandarización, explicitación de reglas y validación de consistencia. En vez de producir nueva información, el pipeline fue diseñado para asegurar que la información existente quedara correctamente alineada, trazada y preservada en una estructura estable.

Este principio tuvo varias consecuencias metodológicas. En primer lugar, todas las decisiones de procesamiento debían ser explícitas y reproducibles. No bastaba con corregir; era necesario documentar qué problema se observó, qué alternativas se consideraron, qué regla se adoptó y en qué archivos o reportes quedaba trazada esa decisión. En segundo lugar, cada paso del pipeline debía dejar evidencia verificable. Por ello, junto con los archivos principales se generaron salidas de control de calidad, resúmenes de integridad y auditorías específicas por etapa. En tercer lugar, ante casos ambiguos, se privilegió la honestidad semántica por sobre la aparente completitud. Esto fue especialmente importante en la recodificación de indicadores y en el tratamiento de excepciones documentales: cuando un valor no podía interpretarse defensiblemente como 0 o 1, o cuando la evidencia textual asociada a un registro no era legible ni verificable, se prefirió conservar la ambigüedad como NA o mantener el caso en revisión antes que forzar una clasificación engañosa.

En términos simples, el enfoque metodológico puede resumirse así: había que dejar la misma información en una forma mejor estructurada para ser analizada, auditada y protegida frente a errores de procesamiento. Esa es la base sobre la cual una etapa posterior puede producir resultados sustantivos confiables.

2.4 Metodología de consolidación y validación paso a paso

La consolidación de la base se desarrolló mediante una secuencia de etapas encadenadas, cada una orientada a resolver un problema específico. El valor del pipeline no estuvo sólo en su orden técnico, sino en que cada paso respondió a una necesidad analítica concreta y dejó una huella verificable.

La primera operación consistió en trabajar sobre un conjunto congelado de insumos. En el run full, esta etapa operó a partir de un snapshot ya generado, correspondiente al corte 20260225_1928. Su función fue fijar una versión estable de los archivos de origen y evitar que el material cambiara a mitad del proceso. Metodológicamente, congelar los insumos es importante porque define un punto de referencia común: cualquier resultado posterior puede ser remitido al mismo universo de archivos de partida. Esta etapa permitió además inventariar los archivos disponibles y asociarlos con los módulos esperados, transformando un conjunto disperso de planillas en un corpus delimitado y auditable.

Una vez estabilizado el punto de partida, el siguiente problema fue la heterogeneidad estructural entre módulos. Para resolverlo se construyeron mappings específicos por módulo. Estos mappings definieron cómo traducir columnas raw a una estructura canónica común. Su función fue decisiva: sin ellos, integrar la información de módulos distintos habría implicado suponer equivalencias de manera implícita. El mapping, en cambio, obligó a declarar de forma explícita qué columna se consideraba equivalente a qué campo canónico, qué columnas eran indicadores, cuáles eran notas y cómo se trataban cabeceras especiales, vacías o duplicadas. La validación de mappings mostró coincidencia completa entre referencias esperadas y cabeceras resueltas para los once módulos, sin columnas huérfanas al cierre de esta etapa.

Definido el puente entre la estructura de origen y la estructura esperada, se construyó la tabla core por módulo. La tabla core puede entenderse como la capa base de cada módulo: reúne los campos esenciales que permiten identificar y describir cada registro en una forma homogénea. Su creación respondió a una necesidad analítica básica: antes de separar indicadores, notas o componentes específicos, había que asegurar que todas las observaciones compartieran un esqueleto común. Esta fase permitió detectar tempranamente vacíos en campos relevantes y grupos duplicados de row_id, lo que sirvió como diagnóstico para las correcciones posteriores. En el resumen QC previo al patch, por ejemplo, se observaban duplicados de row_id en varios módulos, incluyendo Salud, HSE, DDHH y EDS, y presencia de cita vacía en módulos como PAZ y HSE.

El siguiente problema apareció en relación con artefactos visuales heredados de los archivos de origen, especialmente celdas combinadas y filas sin contenido analítico. Cuando una planilla usa celdas combinadas, es habitual que la información aparezca explícitamente sólo en la primera fila del bloque y quede vacía en las siguientes. Para lectura humana eso no es un problema, porque el ojo interpreta la continuidad. Para el procesamiento automatizado, en cambio, esos vacíos pueden desestabilizar la normalización de campos como documento y, por extensión, la construcción de llaves. Por ello se aplicó un patch de fill-down restringido por país y ordenado por fila de origen. En paralelo, se excluyeron filas con cita vacía cuando éstas actuaban como separadores o ruido y no como observaciones analíticas. Al mismo tiempo, se creó row_uid como llave operativa interna, capaz de preservar la trayectoria exacta de cada fila incluso cuando row_id todavía no era único. Después de esta etapa, los vacíos en documento quedaron resueltos y los vacíos en cita fueron eliminados de la base operativa.

Una vez estabilizada la capa core, el pipeline separó tres componentes: variables núcleo, indicadores y notas. Esta división respondió a una necesidad metodológica clara. No toda la información cumple la misma función analítica, y mezclarla en una sola tabla complica tanto el control como la interpretación. Separar core, indicators y notes permitió, por un lado, recodificar y auditar indicadores sin alterar variables estructurales y, por otro, conservar el material textual en una base paralela pero alineada. La verificación central de esta fase fue que los tres componentes mantuvieran correspondencia perfecta por row_uid dentro de cada módulo.

La etapa de recodificación de indicadores resolvió un problema distinto: la falta de un dominio comparativo común. Si los módulos usan marcas distintas para expresar presencia, ausencia, etiquetas o codificaciones parciales, no es posible sumar, comparar o auditar indicadores entre sí. Por ello se recodificaron al dominio {0,1,NA}, aplicando reglas globales y, cuando fue necesario, overrides por columna para variables cuya lógica de codificación estaba basada en etiquetas no vacías más que en marcas binarias convencionales. Gracias a esta etapa, los indicadores quedaron listos para uso comparativo y el pipeline pudo auditar explícitamente la ausencia de valores inválidos fuera del dominio esperado. Del mismo modo, los residuos no binarios que no podían interpretarse de manera defendible como presencia o ausencia fueron preservados como NA.

La deduplicación trazable fue el paso siguiente. Aunque la corrección de vacíos y la separación por componentes habían ordenado la estructura, aún persistían grupos duplicados de row_id en algunos módulos. En vez de resolver esto de forma arbitraria, se adoptó una regla determinista: mantener como ganador el registro con menor source_row_number y filtrar los perdedores de manera consistente en core, indicators y notes mediante row_uid. Esta decisión fue clave porque permitió estabilizar el conteo sin sacrificar auditabilidad. En esta etapa, por ejemplo, Salud pasó de 969 a 909 registros, eliminando grupos duplicados que habrían afectado el conteo final.

2.4.1 Reducción de registros por módulo durante la consolidación

Un resultado importante del proceso de consolidación fue la reducción controlada de registros duplicados. Esta disminución no implicó pérdida arbitraria de información sustantiva, sino la eliminación trazable de observaciones que pertenecían a grupos duplicados de row_id y que, de mantenerse, habrían generado sobreconteo o ambigüedad analítica.

En términos operativos, cada módulo partió con un número inicial de registros (n_before) y terminó con un número final de registros válidos (n_after) luego de aplicar la regla de deduplicación determinista. La diferencia entre ambos valores corresponde a los registros eliminados en esta etapa. Los registros que quedaron fueron aquellos seleccionados como observación canónica dentro de cada grupo duplicado, siguiendo la regla de conservar el caso con menor source_row_number y filtrar consistentemente los restantes mediante row_uid.

2.4.2 Tabla 1. Registros antes y después de la deduplicación por módulo

Módulo	Registros antes (`n_before`)	Registros después (`n_after`)	Registros eliminados	Grupos duplicados antes
DDHH	670	658	12	12
ECM	447	442	5	5
EDS	1409	1399	10	8
ESI	259	259	0	0
Género	316	316	0	0
HSE	1542	1526	16	16
HSE Respeto	441	439	2	1
PAZ	254	253	1	1
Pilares actitudinal	1006	989	17	17
Pilares cognitivo	221	220	1	1
Salud	969	909	60	50
Total	7534	7410	124	111

La tabla muestra que la reducción total fue de 124 registros, pasando de 7.534 observaciones previas a la deduplicación a 7.410 observaciones en la base final. Esta disminución se explica por la resolución de 111 grupos duplicados de row_id, todos eliminados al cierre de la etapa.

Con las tablas ya estabilizadas y deduplicadas, se construyó el master final. Esta etapa consistió en unir uno a uno las tablas estructurales e indicadores por row_uid y concatenar luego los once módulos en un único conjunto consolidado. El resultado de esta operación fue la base erce_m1_full_master.csv, junto con su contraparte erce_m1_full_notes.csv. Metodológicamente, este fue el momento en que la información dejó de estar organizada por módulos aislados y pasó a constituir un universo único, comparable y trazable. Los chequeos de cardinalidad confirmaron que en todos los módulos el join fue 1:1 y que no se generaron duplicados posteriores a la unión.

En esta base final, cada fila representa una evidencia o cita curricular específica, ubicada en un documento, módulo y página determinados. Sobre esa unidad de análisis se organizan variables núcleo, variables de contexto, variables de trazabilidad e indicadores recodificados. Esta precisión es importante porque permite interpretar correctamente la estructura del conjunto: la base no resume documentos completos ni módulos enteros, sino evidencias puntuales, comparables y rastreables.

El pipeline cerró con una fase de control de calidad final, descriptivos univariados, elaboración de codebook y chequeo de entrega. Esta etapa tuvo una doble función. Por una parte, validó que el resultado final cumpliera condiciones mínimas de integridad: ausencia de duplicados globales, control de faltantes esenciales, dominio válido de indicadores y consistencia entre master y notes. Por otra, produjo salidas interpretables que permiten leer cómo quedó distribuida la base por módulo, país, grado, asignatura y densidad de indicadores. Finalmente, el proceso se integró en un reporte final y una verificación de entrega, asegurando que no sólo existiera una base consolidada, sino también un conjunto de documentos y evidencias que permiten comprenderla, revisarla y reproducirla.

2.5 Problemas detectados y soluciones adoptadas

El primer gran tipo de problema fue la heterogeneidad de cabeceras. Algunos módulos presentaban nombres de columnas distintos para funciones equivalentes; otros incluían columnas vacías, duplicadas o con etiquetas repetidas. El riesgo de este tipo de heterogeneidad es sencillo de entender: si dos columnas representan lo mismo pero no se reconocen como equivalentes, la información queda fragmentada; si una sola etiqueta aparece duplicada con contenidos distintos, la integración puede mezclar elementos no equivalentes. La solución adoptada fue el mapping explícito por módulo, apoyado en resolución de cabeceras y perfiles de columnas. La alternativa descartada fue una integración implícita por coincidencia parcial de nombres o una revisión exclusivamente manual sin reglas formalizadas.

El segundo problema fue la presencia de celdas combinadas y vacíos estructurales. Aquí el riesgo no era la falta real de información, sino la apariencia de falta. Cuando el nombre de un documento se muestra una sola vez en una planilla y queda visualmente extendido a las filas siguientes, el procesamiento automatizado lee vacíos donde el lector humano ve continuidad. Si esos vacíos se mantienen, se desestabiliza la construcción de llaves y se fragmenta artificialmente la unidad documental. La decisión adoptada fue aplicar fill-down de documento dentro de cada pais, conservando el orden de origen. Se descartó tanto dejar los vacíos intactos como aplicar un relleno global sin fronteras, porque ambas opciones introducían riesgos analíticos mayores.

El tercer problema fue la existencia de filas separadoras o sin contenido analítico, identificables por cita vacía. El riesgo aquí consistía en contar como observación una fila que en realidad funcionaba como borde visual, subtítulo o espacio en blanco dentro de la planilla. La solución fue excluir esas filas del core analítico y exportarlas como evidencia de control de calidad. Se descartó mantenerlas y confiar en que el ruido se corregiría más adelante, porque eso habría contaminado etapas posteriores con registros que no correspondían a la unidad analítica definida.

El cuarto problema fueron los duplicados de row_id. Incluso después de estabilizar la estructura, algunos módulos mantenían grupos duplicados. Si esos duplicados no se resuelven, la base puede sobrecontar evidencias o generar joins ambiguos. La decisión adoptada fue una deduplicación determinista, con criterio de ganador explícito y trazabilidad mediante row_uid. Se descartó tanto conservar todos los duplicados como elegir un ganador de manera arbitraria por orden de archivo, porque ambas alternativas comprometían la reproducibilidad.

El quinto problema surgió en la recodificación de indicadores. Algunas columnas usaban marcas binarias convencionales; otras usaban etiquetas no vacías, cadenas tipo tupla o anotaciones breves que funcionaban de hecho como presencia de un rasgo. El riesgo en este punto era doble: perder señal válida si se trataban esas marcas como residuales o, a la inversa, forzar como presencia lo que era una anotación descriptiva ambigua. La solución fue combinar reglas globales con overrides por columna, documentando dónde un valor no vacío equivalía a presencia y dónde esa equivalencia no era defendible. Se descartó enumerar manualmente todas las variantes de tokens positivos o dejar como NA señales sistemáticas que sí tenían valor codificado consistente.

Un sexto problema apareció en el módulo EDS. Allí se habían detectado columnas unnamed con patrones de distribución compatibles con marcas analíticas y también residuos no binarios concentrados en una fila específica. La solución fue separar esas columnas entre candidatas a indicadores y notas cuando correspondía, y preservar como NA aquellos residuos que no podían leerse como marcas binarias defendibles. La alternativa descartada fue forzar esos residuos como presencia positiva.

Un séptimo problema, de naturaleza más específicamente documental, fue detectado en el módulo Salud. Durante la revisión final se identificó un subconjunto acotado de registros correspondientes a Paraguay, específicamente al documento Paraguay 2 Programa Tercer_grado.pdf en la página 104, cuyos textos asociados a la cita presentaban problemas severos de legibilidad y codificación de caracteres. Estos registros sí presentaban activación de indicadores, pero no podían ser interpretados ni auditados sustantivamente de manera confiable en su estado actual. El riesgo de tratarlos como observaciones completamente estables era introducir en la base analítica una señal positiva cuya evidencia textual seguía siendo deficiente o dudosa. En esta etapa, sin embargo, estos casos no fueron eliminados, sino mantenidos temporalmente por razones de trazabilidad, a la espera de que la información pueda ser corregida o completada si se logra recuperar la referencia correspondiente.

Finalmente, hubo excepciones acotadas en variables de completitud, especialmente en pagina, incluyendo el caso ya identificado en PAZ y otros casos observados en ESI y Salud. La fortaleza del proceso no radica en haber eliminado toda imperfección, sino en haber distinguido entre errores estructurales, ruido removible y excepciones legítimamente acotadas o pendientes de revisión.

2.6 Documentación de decisiones de curatoría y procesamiento de datos

Uno de los rasgos metodológicamente más importantes del proceso fue que las decisiones no quedaron implícitas en los scripts, sino explícitamente registradas en un decision_log. Esta documentación permitió transformar reglas operativas en decisiones defendibles. No se trató simplemente de “hacer que el pipeline funcionara”, sino de justificar por qué el modo en que funciona es razonable.

El decision_log muestra, además, que la consolidación no fue una secuencia improvisada de correcciones, sino un proceso acumulativo de aprendizaje metodológico. Las decisiones del piloto cumplieron una función exploratoria y de prueba de reglas; las decisiones del run full extendieron, formalizaron o generalizaron esos criterios al conjunto completo de once módulos. En este sentido, el registro de decisiones documenta no sólo qué se hizo, sino también cómo ciertos problemas fueron comprendidos progresivamente y luego estabilizados como reglas de procesamiento.

En términos analíticos, las decisiones registradas pueden distinguirse en tres grandes grupos. El primero corresponde a decisiones estructurales. Son aquellas que definen cómo representar la información: mappings por módulo, normalización de cabeceras, creación de tablas core y construcción de llaves operativas. Aquí se ubican, por ejemplo, TRIAL-EDS-001, TRIAL-ECM-001, TRIAL-DDHH-001 y el conjunto de decisiones FULL-MAP-* para ESI, Género, HSE, HSE Respeto, PAZ, Pilares actitudinal, Pilares cognitivo y Salud. Estas decisiones responden a la pregunta de cómo traducir el desorden original a una estructura analítica estable.

El segundo grupo corresponde a decisiones defensivas. Aquí se ubican reglas como el fill-down restringido, la exclusión de filas con cita vacía y la deduplicación determinista. Este grupo incluye TRIAL-CORE-002, TRIAL-CORE-003, TRIAL-DEDUPE-001, FULL-CORE-002, FULL-CORE-003 y FULL-DEDUPE-001. Se trata de decisiones orientadas a prevenir riesgos metodológicos concretos: sobreconteo, pérdida de trazabilidad, fragmentación de unidades o joins ambiguos. Su función no es reinterpretar el contenido, sino proteger la integridad del proceso.

El tercer grupo corresponde a decisiones de honestidad semántica. Estas aparecen cuando la evidencia disponible no permite forzar una clasificación binaria o inequívoca sin introducir una distorsión. Aquí destacan TRIAL-RECODE-001, TRIAL-RECODE-EDS-002, FULL-RECODE-MULTI-TAGCOLS-001 y FULL-RECODE-RESIDUAL-EDS-001. En estos casos, el criterio no fue maximizar artificialmente la completitud, sino preservar la relación defendible entre codificación y significado. El caso residual de EDS es el ejemplo más claro, pero también debe incluirse aquí el tratamiento de los casos documentales en revisión en Salud: aunque esos registros presentaban indicadores, la evidencia textual asociada no era legible de manera defendible en su estado actual, por lo que se optó por mantenerlos trazados y explícitamente observados, en lugar de cerrar prematuramente su tratamiento con una decisión no verificable.

El valor de esta documentación radica en que vuelve el proceso revisable. Una contraparte puede no sólo observar el resultado final, sino reconstruir el razonamiento que llevó a él. En ese sentido, la trazabilidad no se limita a las filas de la base, sino que alcanza también las decisiones que la hicieron posible.

2.6.1 Tabla 2. Síntesis de decisiones metodológicas

Tipo de decisión	Ejemplos del `decision_log`	Función metodológica
Estructurales	`TRIAL-EDS-001`, `TRIAL-ECM-001`, `TRIAL-DDHH-001`, `FULL-MAP-ESI-001`, `FULL-MAP-GENERO-001`, `FULL-MAP-HSE-001`, `FULL-MAP-HSE_RESPETO-001`, `FULL-MAP-PAZ-001`, `FULL-MAP-PILARES_ACTITUDINAL-001`, `FULL-MAP-PILARES_COGNITIVO-001`, `FULL-MAP-SALUD-001`	Definir mappings, resolver cabeceras, separar indicadores y notas, y construir la estructura canónica del corpus
Defensivas	`TRIAL-CORE-002`, `TRIAL-CORE-003`, `TRIAL-DEDUPE-001`, `FULL-CORE-002`, `FULL-CORE-003`, `FULL-DEDUPE-001`	Evitar ruido, sobreconteo, pérdida de trazabilidad y ambigüedad en joins mediante fill-down controlado, exclusión de separadores y deduplicación determinista
Honestidad semántica	`TRIAL-RECODE-001`, `TRIAL-RECODE-EDS-002`, `FULL-RECODE-MULTI-TAGCOLS-001`, `FULL-RECODE-RESIDUAL-EDS-001`	Preservar una relación defendible entre señal codificada y significado, evitando forzar recodificaciones no binarias o ambiguas

--- title: "Documento técnico de la base ERCE 2025" --- ## Introducción Este documento corresponde al entregable del Mes 1 de la consultoría asociada al análisis cuantitativo del estudio ESD/GCE ERCE 2025. Su propósito es presentar de manera clara, completa y defendible la metodología utilizada para consolidar y validar la base de datos que servirá como soporte de las etapas analíticas posteriores. En este sentido, la entrega M1 cumple una función fundacional dentro del proyecto: antes de interpretar resultados, comparar países o construir indicadores agregados, era necesario garantizar que el corpus estuviera ordenado, que las unidades de análisis fueran consistentes y que las reglas de procesamiento estuvieran explícitamente documentadas. La relevancia de esta etapa deriva de una premisa básica del trabajo cuantitativo: los análisis sólo son tan confiables como la base sobre la cual descansan. Cuando los datos provienen de múltiples archivos, hojas, módulos y convenciones de codificación, la producción de una base consolidada deja de ser una tarea secundaria y pasa a ser una condición de posibilidad del análisis mismo. En ese contexto, el objetivo de esta entrega no fue generar conclusiones sustantivas sobre la presencia o distribución de contenidos ESD/GCE, sino construir la infraestructura metodológica que permitirá producirlas de manera válida en los meses siguientes. En coherencia con los términos de referencia de la consultoría, esta entrega incluye cuatro componentes centrales: la metodología de consolidación de bases de datos, la documentación de decisiones de curatoría y procesamiento, el libro de códigos de la base final y un conjunto de descriptivos univariados que permiten caracterizar el resultado de la consolidación. El valor de este documento reside, por tanto, en explicar no sólo qué producto final existe, sino también por qué puede considerarse confiable, cómo fue construido y qué controles permiten sostener esa afirmación. ## Antecedentes y problema a resolver El punto de partida del trabajo fue un corpus compuesto por once módulos temáticos: DDHH, ECM, EDS, ESI, Género, HSE, HSE Respeto, PAZ, Pilares actitudinal, Pilares cognitivo y Salud. Estos módulos estaban asociados a distintos archivos fuente y, en algunos casos, a distintas hojas dentro de un mismo libro. El snapshot de referencia utilizado para el run full correspondió al corte `20260225_1928`, lo que permitió trabajar sobre un universo estable de insumos y fijar un punto común para todo el proceso posterior. La heterogeneidad del corpus no era un problema meramente estético o de formato. En la práctica, implicaba que columnas conceptualmente equivalentes podían aparecer con nombres distintos, que un mismo libro podía contener más de una hoja relevante, que algunas cabeceras estuvieran duplicadas o parcialmente vacías, y que ciertos vacíos obedecieran no a ausencia real de información, sino a la lógica visual de celdas combinadas en los archivos de origen. Además, algunos módulos compartían un mismo archivo fuente, mientras que otros requerían inferencias controladas para identificar adecuadamente la hoja o el segmento relevante. En un nivel más concreto, el problema inicial puede describirse como un desajuste entre el modo en que la información estaba almacenada y el modo en que debía estar organizada para poder ser analizada. Los archivos de origen estaban pensados para contener información curricular y de codificación, pero no necesariamente para operar como una base consolidada de análisis cuantitativo. Esa diferencia es decisiva. Un archivo puede ser útil para lectura humana y, al mismo tiempo, ser riesgoso para el procesamiento si contiene ambigüedades estructurales, vacíos heredados del formato visual, duplicaciones no resueltas o registros cuya señal codificada no puede vincularse de forma confiable con una evidencia textual legible. Desde el punto de vista analítico, mantener los insumos tal como estaban implicaba varios riesgos. El primero era el riesgo de sobreconteo o subconteo: si existían duplicados no resueltos o filas separadoras tratadas como observaciones reales, los descriptivos y frecuencias podían distorsionarse. El segundo era el riesgo de pérdida de trazabilidad: si no existía una llave operativa estable para seguir cada registro a través de las distintas transformaciones, se debilitaba la posibilidad de auditar el proceso completo. El tercero era el riesgo de comparación inválida: si los indicadores no compartían un dominio común o si columnas análogas estaban definidas de forma distinta entre módulos, cualquier intento de producir síntesis comparables podía volverse metodológicamente frágil. Finalmente, existía un riesgo de opacidad: incluso si el procesamiento lograba “funcionar”, sin documentación explícita de las decisiones sería difícil defender por qué determinadas reglas fueron aplicadas y otras descartadas. Por estas razones, la primera necesidad del proyecto era ordenar el soporte empírico. Antes de responder preguntas sustantivas, había que resolver una pregunta más básica: cómo transformar un conjunto de insumos heterogéneos en una base única que preservara la información original, pero eliminara las ambigüedades estructurales que impedían su uso analítico directo. ## Enfoque metodológico general El principio rector del trabajo fue ordenar sin alterar el contenido sustantivo. Esto significa que la consolidación no fue entendida como una intervención destinada a modificar la información, sino como un proceso de estandarización, explicitación de reglas y validación de consistencia. En vez de producir nueva información, el pipeline fue diseñado para asegurar que la información existente quedara correctamente alineada, trazada y preservada en una estructura estable. Este principio tuvo varias consecuencias metodológicas. En primer lugar, todas las decisiones de procesamiento debían ser explícitas y reproducibles. No bastaba con corregir; era necesario documentar qué problema se observó, qué alternativas se consideraron, qué regla se adoptó y en qué archivos o reportes quedaba trazada esa decisión. En segundo lugar, cada paso del pipeline debía dejar evidencia verificable. Por ello, junto con los archivos principales se generaron salidas de control de calidad, resúmenes de integridad y auditorías específicas por etapa. En tercer lugar, ante casos ambiguos, se privilegió la honestidad semántica por sobre la aparente completitud. Esto fue especialmente importante en la recodificación de indicadores y en el tratamiento de excepciones documentales: cuando un valor no podía interpretarse defensiblemente como 0 o 1, o cuando la evidencia textual asociada a un registro no era legible ni verificable, se prefirió conservar la ambigüedad como `NA` o mantener el caso en revisión antes que forzar una clasificación engañosa. En términos simples, el enfoque metodológico puede resumirse así: había que dejar la misma información en una forma mejor estructurada para ser analizada, auditada y protegida frente a errores de procesamiento. Esa es la base sobre la cual una etapa posterior puede producir resultados sustantivos confiables. ## Metodología de consolidación y validación paso a paso La consolidación de la base se desarrolló mediante una secuencia de etapas encadenadas, cada una orientada a resolver un problema específico. El valor del pipeline no estuvo sólo en su orden técnico, sino en que cada paso respondió a una necesidad analítica concreta y dejó una huella verificable. La primera operación consistió en trabajar sobre un conjunto congelado de insumos. En el run full, esta etapa operó a partir de un snapshot ya generado, correspondiente al corte `20260225_1928`. Su función fue fijar una versión estable de los archivos de origen y evitar que el material cambiara a mitad del proceso. Metodológicamente, congelar los insumos es importante porque define un punto de referencia común: cualquier resultado posterior puede ser remitido al mismo universo de archivos de partida. Esta etapa permitió además inventariar los archivos disponibles y asociarlos con los módulos esperados, transformando un conjunto disperso de planillas en un corpus delimitado y auditable. Una vez estabilizado el punto de partida, el siguiente problema fue la heterogeneidad estructural entre módulos. Para resolverlo se construyeron mappings específicos por módulo. Estos mappings definieron cómo traducir columnas raw a una estructura canónica común. Su función fue decisiva: sin ellos, integrar la información de módulos distintos habría implicado suponer equivalencias de manera implícita. El mapping, en cambio, obligó a declarar de forma explícita qué columna se consideraba equivalente a qué campo canónico, qué columnas eran indicadores, cuáles eran notas y cómo se trataban cabeceras especiales, vacías o duplicadas. La validación de mappings mostró coincidencia completa entre referencias esperadas y cabeceras resueltas para los once módulos, sin columnas huérfanas al cierre de esta etapa. Definido el puente entre la estructura de origen y la estructura esperada, se construyó la tabla core por módulo. La tabla core puede entenderse como la capa base de cada módulo: reúne los campos esenciales que permiten identificar y describir cada registro en una forma homogénea. Su creación respondió a una necesidad analítica básica: antes de separar indicadores, notas o componentes específicos, había que asegurar que todas las observaciones compartieran un esqueleto común. Esta fase permitió detectar tempranamente vacíos en campos relevantes y grupos duplicados de `row_id`, lo que sirvió como diagnóstico para las correcciones posteriores. En el resumen QC previo al patch, por ejemplo, se observaban duplicados de `row_id` en varios módulos, incluyendo Salud, HSE, DDHH y EDS, y presencia de `cita` vacía en módulos como PAZ y HSE. El siguiente problema apareció en relación con artefactos visuales heredados de los archivos de origen, especialmente celdas combinadas y filas sin contenido analítico. Cuando una planilla usa celdas combinadas, es habitual que la información aparezca explícitamente sólo en la primera fila del bloque y quede vacía en las siguientes. Para lectura humana eso no es un problema, porque el ojo interpreta la continuidad. Para el procesamiento automatizado, en cambio, esos vacíos pueden desestabilizar la normalización de campos como `documento` y, por extensión, la construcción de llaves. Por ello se aplicó un patch de fill-down restringido por país y ordenado por fila de origen. En paralelo, se excluyeron filas con `cita` vacía cuando éstas actuaban como separadores o ruido y no como observaciones analíticas. Al mismo tiempo, se creó `row_uid` como llave operativa interna, capaz de preservar la trayectoria exacta de cada fila incluso cuando `row_id` todavía no era único. Después de esta etapa, los vacíos en `documento` quedaron resueltos y los vacíos en `cita` fueron eliminados de la base operativa. Una vez estabilizada la capa core, el pipeline separó tres componentes: variables núcleo, indicadores y notas. Esta división respondió a una necesidad metodológica clara. No toda la información cumple la misma función analítica, y mezclarla en una sola tabla complica tanto el control como la interpretación. Separar core, indicators y notes permitió, por un lado, recodificar y auditar indicadores sin alterar variables estructurales y, por otro, conservar el material textual en una base paralela pero alineada. La verificación central de esta fase fue que los tres componentes mantuvieran correspondencia perfecta por `row_uid` dentro de cada módulo. La etapa de recodificación de indicadores resolvió un problema distinto: la falta de un dominio comparativo común. Si los módulos usan marcas distintas para expresar presencia, ausencia, etiquetas o codificaciones parciales, no es posible sumar, comparar o auditar indicadores entre sí. Por ello se recodificaron al dominio `{0,1,NA}`, aplicando reglas globales y, cuando fue necesario, overrides por columna para variables cuya lógica de codificación estaba basada en etiquetas no vacías más que en marcas binarias convencionales. Gracias a esta etapa, los indicadores quedaron listos para uso comparativo y el pipeline pudo auditar explícitamente la ausencia de valores inválidos fuera del dominio esperado. Del mismo modo, los residuos no binarios que no podían interpretarse de manera defendible como presencia o ausencia fueron preservados como `NA`. La deduplicación trazable fue el paso siguiente. Aunque la corrección de vacíos y la separación por componentes habían ordenado la estructura, aún persistían grupos duplicados de `row_id` en algunos módulos. En vez de resolver esto de forma arbitraria, se adoptó una regla determinista: mantener como ganador el registro con menor `source_row_number` y filtrar los perdedores de manera consistente en core, indicators y notes mediante `row_uid`. Esta decisión fue clave porque permitió estabilizar el conteo sin sacrificar auditabilidad. En esta etapa, por ejemplo, Salud pasó de 969 a 909 registros, eliminando grupos duplicados que habrían afectado el conteo final. ### Reducción de registros por módulo durante la consolidación Un resultado importante del proceso de consolidación fue la reducción controlada de registros duplicados. Esta disminución no implicó pérdida arbitraria de información sustantiva, sino la eliminación trazable de observaciones que pertenecían a grupos duplicados de `row_id` y que, de mantenerse, habrían generado sobreconteo o ambigüedad analítica. En términos operativos, cada módulo partió con un número inicial de registros (`n_before`) y terminó con un número final de registros válidos (`n_after`) luego de aplicar la regla de deduplicación determinista. La diferencia entre ambos valores corresponde a los registros eliminados en esta etapa. Los registros que quedaron fueron aquellos seleccionados como observación canónica dentro de cada grupo duplicado, siguiendo la regla de conservar el caso con menor `source_row_number` y filtrar consistentemente los restantes mediante `row_uid`. ### Tabla 1. Registros antes y después de la deduplicación por módulo | Módulo | Registros antes (`n_before`) | Registros después (`n_after`) | Registros eliminados | Grupos duplicados antes | Grupos duplicados después | |---|---:|---:|---:|---:|---:| | DDHH | 670 | 658 | 12 | 12 | 0 | | ECM | 447 | 442 | 5 | 5 | 0 | | EDS | 1409 | 1399 | 10 | 8 | 0 | | ESI | 259 | 259 | 0 | 0 | 0 | | Género | 316 | 316 | 0 | 0 | 0 | | HSE | 1542 | 1526 | 16 | 16 | 0 | | HSE Respeto | 441 | 439 | 2 | 1 | 0 | | PAZ | 254 | 253 | 1 | 1 | 0 | | Pilares actitudinal | 1006 | 989 | 17 | 17 | 0 | | Pilares cognitivo | 221 | 220 | 1 | 1 | 0 | | Salud | 969 | 909 | 60 | 50 | 0 | | Total | 7534 | 7410 | 124 | 111 | 0 | La tabla muestra que la reducción total fue de 124 registros, pasando de 7.534 observaciones previas a la deduplicación a 7.410 observaciones en la base final. Esta disminución se explica por la resolución de 111 grupos duplicados de `row_id`, todos eliminados al cierre de la etapa. Con las tablas ya estabilizadas y deduplicadas, se construyó el master final. Esta etapa consistió en unir uno a uno las tablas estructurales e indicadores por `row_uid` y concatenar luego los once módulos en un único conjunto consolidado. El resultado de esta operación fue la base `erce_m1_full_master.csv`, junto con su contraparte `erce_m1_full_notes.csv`. Metodológicamente, este fue el momento en que la información dejó de estar organizada por módulos aislados y pasó a constituir un universo único, comparable y trazable. Los chequeos de cardinalidad confirmaron que en todos los módulos el join fue 1:1 y que no se generaron duplicados posteriores a la unión. En esta base final, cada fila representa una evidencia o cita curricular específica, ubicada en un documento, módulo y página determinados. Sobre esa unidad de análisis se organizan variables núcleo, variables de contexto, variables de trazabilidad e indicadores recodificados. Esta precisión es importante porque permite interpretar correctamente la estructura del conjunto: la base no resume documentos completos ni módulos enteros, sino evidencias puntuales, comparables y rastreables. El pipeline cerró con una fase de control de calidad final, descriptivos univariados, elaboración de codebook y chequeo de entrega. Esta etapa tuvo una doble función. Por una parte, validó que el resultado final cumpliera condiciones mínimas de integridad: ausencia de duplicados globales, control de faltantes esenciales, dominio válido de indicadores y consistencia entre master y notes. Por otra, produjo salidas interpretables que permiten leer cómo quedó distribuida la base por módulo, país, grado, asignatura y densidad de indicadores. Finalmente, el proceso se integró en un reporte final y una verificación de entrega, asegurando que no sólo existiera una base consolidada, sino también un conjunto de documentos y evidencias que permiten comprenderla, revisarla y reproducirla. ## Problemas detectados y soluciones adoptadas El primer gran tipo de problema fue la heterogeneidad de cabeceras. Algunos módulos presentaban nombres de columnas distintos para funciones equivalentes; otros incluían columnas vacías, duplicadas o con etiquetas repetidas. El riesgo de este tipo de heterogeneidad es sencillo de entender: si dos columnas representan lo mismo pero no se reconocen como equivalentes, la información queda fragmentada; si una sola etiqueta aparece duplicada con contenidos distintos, la integración puede mezclar elementos no equivalentes. La solución adoptada fue el mapping explícito por módulo, apoyado en resolución de cabeceras y perfiles de columnas. La alternativa descartada fue una integración implícita por coincidencia parcial de nombres o una revisión exclusivamente manual sin reglas formalizadas. El segundo problema fue la presencia de celdas combinadas y vacíos estructurales. Aquí el riesgo no era la falta real de información, sino la apariencia de falta. Cuando el nombre de un documento se muestra una sola vez en una planilla y queda visualmente extendido a las filas siguientes, el procesamiento automatizado lee vacíos donde el lector humano ve continuidad. Si esos vacíos se mantienen, se desestabiliza la construcción de llaves y se fragmenta artificialmente la unidad documental. La decisión adoptada fue aplicar fill-down de `documento` dentro de cada `pais`, conservando el orden de origen. Se descartó tanto dejar los vacíos intactos como aplicar un relleno global sin fronteras, porque ambas opciones introducían riesgos analíticos mayores. El tercer problema fue la existencia de filas separadoras o sin contenido analítico, identificables por `cita` vacía. El riesgo aquí consistía en contar como observación una fila que en realidad funcionaba como borde visual, subtítulo o espacio en blanco dentro de la planilla. La solución fue excluir esas filas del core analítico y exportarlas como evidencia de control de calidad. Se descartó mantenerlas y confiar en que el ruido se corregiría más adelante, porque eso habría contaminado etapas posteriores con registros que no correspondían a la unidad analítica definida. El cuarto problema fueron los duplicados de `row_id`. Incluso después de estabilizar la estructura, algunos módulos mantenían grupos duplicados. Si esos duplicados no se resuelven, la base puede sobrecontar evidencias o generar joins ambiguos. La decisión adoptada fue una deduplicación determinista, con criterio de ganador explícito y trazabilidad mediante `row_uid`. Se descartó tanto conservar todos los duplicados como elegir un ganador de manera arbitraria por orden de archivo, porque ambas alternativas comprometían la reproducibilidad. El quinto problema surgió en la recodificación de indicadores. Algunas columnas usaban marcas binarias convencionales; otras usaban etiquetas no vacías, cadenas tipo tupla o anotaciones breves que funcionaban de hecho como presencia de un rasgo. El riesgo en este punto era doble: perder señal válida si se trataban esas marcas como residuales o, a la inversa, forzar como presencia lo que era una anotación descriptiva ambigua. La solución fue combinar reglas globales con overrides por columna, documentando dónde un valor no vacío equivalía a presencia y dónde esa equivalencia no era defendible. Se descartó enumerar manualmente todas las variantes de tokens positivos o dejar como `NA` señales sistemáticas que sí tenían valor codificado consistente. Un sexto problema apareció en el módulo EDS. Allí se habían detectado columnas unnamed con patrones de distribución compatibles con marcas analíticas y también residuos no binarios concentrados en una fila específica. La solución fue separar esas columnas entre candidatas a indicadores y notas cuando correspondía, y preservar como `NA` aquellos residuos que no podían leerse como marcas binarias defendibles. La alternativa descartada fue forzar esos residuos como presencia positiva. Un séptimo problema, de naturaleza más específicamente documental, fue detectado en el módulo Salud. Durante la revisión final se identificó un subconjunto acotado de registros correspondientes a Paraguay, específicamente al documento `Paraguay 2 Programa Tercer_grado.pdf` en la página 104, cuyos textos asociados a la cita presentaban problemas severos de legibilidad y codificación de caracteres. Estos registros sí presentaban activación de indicadores, pero no podían ser interpretados ni auditados sustantivamente de manera confiable en su estado actual. El riesgo de tratarlos como observaciones completamente estables era introducir en la base analítica una señal positiva cuya evidencia textual seguía siendo deficiente o dudosa. En esta etapa, sin embargo, estos casos no fueron eliminados, sino mantenidos temporalmente por razones de trazabilidad, a la espera de que la información pueda ser corregida o completada si se logra recuperar la referencia correspondiente. Finalmente, hubo excepciones acotadas en variables de completitud, especialmente en `pagina`, incluyendo el caso ya identificado en PAZ y otros casos observados en ESI y Salud. La fortaleza del proceso no radica en haber eliminado toda imperfección, sino en haber distinguido entre errores estructurales, ruido removible y excepciones legítimamente acotadas o pendientes de revisión. ## Documentación de decisiones de curatoría y procesamiento de datos Uno de los rasgos metodológicamente más importantes del proceso fue que las decisiones no quedaron implícitas en los scripts, sino explícitamente registradas en un `decision_log`. Esta documentación permitió transformar reglas operativas en decisiones defendibles. No se trató simplemente de “hacer que el pipeline funcionara”, sino de justificar por qué el modo en que funciona es razonable. El `decision_log` muestra, además, que la consolidación no fue una secuencia improvisada de correcciones, sino un proceso acumulativo de aprendizaje metodológico. Las decisiones del piloto cumplieron una función exploratoria y de prueba de reglas; las decisiones del run full extendieron, formalizaron o generalizaron esos criterios al conjunto completo de once módulos. En este sentido, el registro de decisiones documenta no sólo qué se hizo, sino también cómo ciertos problemas fueron comprendidos progresivamente y luego estabilizados como reglas de procesamiento. En términos analíticos, las decisiones registradas pueden distinguirse en tres grandes grupos. El primero corresponde a decisiones estructurales. Son aquellas que definen cómo representar la información: mappings por módulo, normalización de cabeceras, creación de tablas core y construcción de llaves operativas. Aquí se ubican, por ejemplo, `TRIAL-EDS-001`, `TRIAL-ECM-001`, `TRIAL-DDHH-001` y el conjunto de decisiones `FULL-MAP-*` para ESI, Género, HSE, HSE Respeto, PAZ, Pilares actitudinal, Pilares cognitivo y Salud. Estas decisiones responden a la pregunta de cómo traducir el desorden original a una estructura analítica estable. El segundo grupo corresponde a decisiones defensivas. Aquí se ubican reglas como el fill-down restringido, la exclusión de filas con `cita` vacía y la deduplicación determinista. Este grupo incluye `TRIAL-CORE-002`, `TRIAL-CORE-003`, `TRIAL-DEDUPE-001`, `FULL-CORE-002`, `FULL-CORE-003` y `FULL-DEDUPE-001`. Se trata de decisiones orientadas a prevenir riesgos metodológicos concretos: sobreconteo, pérdida de trazabilidad, fragmentación de unidades o joins ambiguos. Su función no es reinterpretar el contenido, sino proteger la integridad del proceso. El tercer grupo corresponde a decisiones de honestidad semántica. Estas aparecen cuando la evidencia disponible no permite forzar una clasificación binaria o inequívoca sin introducir una distorsión. Aquí destacan `TRIAL-RECODE-001`, `TRIAL-RECODE-EDS-002`, `FULL-RECODE-MULTI-TAGCOLS-001` y `FULL-RECODE-RESIDUAL-EDS-001`. En estos casos, el criterio no fue maximizar artificialmente la completitud, sino preservar la relación defendible entre codificación y significado. El caso residual de EDS es el ejemplo más claro, pero también debe incluirse aquí el tratamiento de los casos documentales en revisión en Salud: aunque esos registros presentaban indicadores, la evidencia textual asociada no era legible de manera defendible en su estado actual, por lo que se optó por mantenerlos trazados y explícitamente observados, en lugar de cerrar prematuramente su tratamiento con una decisión no verificable. El valor de esta documentación radica en que vuelve el proceso revisable. Una contraparte puede no sólo observar el resultado final, sino reconstruir el razonamiento que llevó a él. En ese sentido, la trazabilidad no se limita a las filas de la base, sino que alcanza también las decisiones que la hicieron posible. ### Tabla 2. Síntesis de decisiones metodológicas | Tipo de decisión | Ejemplos del `decision_log` | Función metodológica | |---|---|---| | Estructurales | `TRIAL-EDS-001`, `TRIAL-ECM-001`, `TRIAL-DDHH-001`, `FULL-MAP-ESI-001`, `FULL-MAP-GENERO-001`, `FULL-MAP-HSE-001`, `FULL-MAP-HSE_RESPETO-001`, `FULL-MAP-PAZ-001`, `FULL-MAP-PILARES_ACTITUDINAL-001`, `FULL-MAP-PILARES_COGNITIVO-001`, `FULL-MAP-SALUD-001` | Definir mappings, resolver cabeceras, separar indicadores y notas, y construir la estructura canónica del corpus | | Defensivas | `TRIAL-CORE-002`, `TRIAL-CORE-003`, `TRIAL-DEDUPE-001`, `FULL-CORE-002`, `FULL-CORE-003`, `FULL-DEDUPE-001` | Evitar ruido, sobreconteo, pérdida de trazabilidad y ambigüedad en joins mediante fill-down controlado, exclusión de separadores y deduplicación determinista | | Honestidad semántica | `TRIAL-RECODE-001`, `TRIAL-RECODE-EDS-002`, `FULL-RECODE-MULTI-TAGCOLS-001`, `FULL-RECODE-RESIDUAL-EDS-001` | Preservar una relación defendible entre señal codificada y significado, evitando forzar recodificaciones no binarias o ambiguas |