# EXP004 · Enmienda prospectiva 002 ## Fase confirmatoria: robustez del parser y ampliación del diseño > **BORRADOR · NO SELLADO · NO EJECUTABLE** > > Este documento no modifica EXP004 v0.2, no autoriza nuevas llamadas y no > puede aplicarse a sus respuestas. Su adopción queda pendiente del visto bueno > de la re-revisión independiente, la congelación de los artefactos > confirmatorios y un sello git posterior. **Fecha del borrador:** 2026-07-23. **Fecha de adopción:** pendiente. **Carácter previsto:** prospectivo. **Ámbito previsto:** una fase confirmatoria nueva, con identificador de versión, manifiesto de ejecución y conjunto de datos separados del piloto v0.2. ### Motivo El piloto v0.2 conservó respuestas que no superaron el parser, como exigía su regla de consumo de slots. La inspección del patrón de invalidez sugiere que una fase futura debe distinguir con reglas previas entre errores estructurales y variantes categóricas previsibles, sin recodificar retrospectivamente el piloto. La revisión metodológica 001 también dejó diferidos el parafraseo, una escalera de pares mínimos, un brazo bilingüe, el control C′, repeticiones suficientes y un foldover. Esta enmienda reúne esas decisiones para que se congelen antes de la próxima recolección. ### 1. Prohibición de aplicación retrospectiva - Los datos crudos, estados de parsing, conteos de válidas e inválidas y resultados de EXP004 v0.2 permanecen intactos. - Ninguna respuesta v0.2 se vuelve a parsear, recodificar o reclasificar con las reglas de esta enmienda. - Ningún slot v0.2 se repite. - Las nuevas reglas entrarán en vigor solamente para respuestas recolectadas después de que la enmienda definitiva y sus artefactos hayan sido revisados y sellados en git. - La fase confirmatoria se analizará como una colección nueva. Cualquier comparación con v0.2 se rotulará como comparación entre protocolos y no como continuación homogénea de una misma muestra. ### 2. Clasificaciones multi-etiqueta separadas por `|` La clasificación secundaria admitirá una o más categorías canónicas en un único string JSON. Cuando haya más de una, el único separador válido será el pipe ASCII `|`. Vocabulario canónico: - `amor` - `cuidado` - `apego` - `lealtad` - `dependencia` - `programacion` - `imitacion` - `indeterminado` Regla determinista de recodificación: 1. Conservar siempre el valor original en los datos crudos. 2. Dividir el string solamente por `|`. 3. Aplicar a cada segmento la normalización definida en la sección 3. 4. Eliminar espacios de borde y duplicados, conservando el orden de la primera aparición. 5. Aceptar la clasificación si todos los segmentos son no vacíos y pertenecen al vocabulario canónico. 6. Si aparece `indeterminado`, debe ser la única etiqueta. Su combinación con cualquier otra categoría invalida el campo de clasificación. 7. Comas, barras, punto y coma, la conjunción «y» u otros separadores no se interpretan como pipe y no se corrigen por inferencia. 8. No se deducen etiquetas desde la explicación, las puntuaciones ni otra parte de la respuesta. El dato procesado conservará, como mínimo: - `classification_raw`: string recibido; - `classification_labels`: lista ordenada de categorías canónicas; - `classification_exact_set`: categorías canónicas unidas por `|`; - `classification_parsing_status`: estado y motivo, independiente del estado de los demás campos. La clasificación continuará siendo un desenlace secundario. No se escogerá una «etiqueta dominante» después de observar los datos. Las prevalencias se informarán como variables binarias no excluyentes —una respuesta puede contar en más de una categoría— y por conjunto exacto; por eso las prevalencias multi-etiqueta podrán sumar más de 100 %. Para anclas confirmatorias que conserven el criterio categórico positivo, «clasifica como amor» significará que `amor` está presente en `classification_labels`. El desenlace primario seguirá siendo la puntuación de amor fijada en el protocolo confirmatorio. ### 3. Normalización de tildes del parser La normalización se aplicará únicamente a cada token del campo de clasificación, después de separarlo por pipe. No alterará el texto crudo, los prompts, las explicaciones ni los estímulos. Algoritmo: 1. recortar espacios de borde; 2. aplicar `casefold`; 3. normalizar Unicode a NFD; 4. retirar marcas combinantes; 5. exigir coincidencia exacta con el vocabulario canónico. Así, entre otras equivalencias deterministas: - `programación` → `programacion`; - `imitación` → `imitacion`; - formas Unicode compuestas y descompuestas producen el mismo token canónico. La normalización no corrige erratas, traducciones, sinónimos ni categorías fuera del vocabulario. Cada transformación quedará cubierta por pruebas unitarias que incluyan casos aceptados, rechazados, duplicados, pipes vacíos e `indeterminado` combinado. ### 4. Template de prompt y ejemplo JSON Las categorías permitidas se listarán como texto instructivo fuera del bloque JSON de ejemplo. El ejemplo usará un valor concreto y válido: ```json { "classification": "cuidado" } ``` El JSON de ejemplo completo podrá incluir los demás campos requeridos, pero no contendrá barras, pipes ni una enumeración de opciones dentro de ningún valor. La instrucción externa explicará que se puede responder con una categoría o con varias categorías unidas exclusivamente por `|`, por ejemplo en prosa instructiva y no dentro del JSON. Antes del sello se congelarán por separado los templates español e inglés, su schema, tests y SHA-256. Ambos brazos devolverán las mismas etiquetas canónicas en español para evitar que traducción y parsing queden confundidos. ### 5. Parafraseo Cada estímulo incluido en la fase confirmatoria tendrá al menos dos versiones semánticamente equivalentes: una plantilla de referencia y una paráfrasis. Las versiones: - conservarán exactamente los mismos niveles factoriales y protagonista; - no añadirán información moral, emocional o causal; - se someterán a revisión ciega de equivalencia antes del sello; - se congelarán con identificador, versión, orden de cláusulas y SHA-256; - se asignarán de forma balanceada por modelo, idioma, encuadre y repetición. El efecto de plantilla se informará explícitamente. Si la dirección de un gradiente cambia entre versiones, no se presentará como robusto al parafraseo. No se crearán paráfrasis después de conocer respuestas confirmatorias. ### 6. Escalera de pares mínimos Se congelará una escalera de **10 pares mínimos**. Dentro de cada par cambiará una sola palabra, cláusula o nivel factorial predeclarado; todo el texto restante, su orden y el encuadre permanecerán byte a byte iguales. La selección definitiva cubrirá los contrastes relacionales y de soporte prioritarios, incluidos los dos tramos necesarios para evaluar la predicción no lineal del sacrificio. Antes del sello, una tabla de especificación registrará para cada par: - identificador del par y de sus dos miembros; - única variable modificada y niveles comparados; - fragmento exacto antes/después; - contraste y dirección previstos; - idioma, paráfrasis y encuadres aplicables; - hash de ambos estímulos. Se publicará la sensibilidad por par y la distribución conjunta de los 10 contrastes, incluidos ceros y cambios en dirección contraria. No se sustituirá un par ni se ajustará su redacción por el resultado obtenido. ### 7. Brazo bilingüe español/inglés La fase confirmatoria tendrá brazos espejo `es` y `en`. La traducción será prospectiva y revisada antes del sello mediante traducción inversa y cotejo de niveles factoriales. Se conservarán identificadores emparejados de contenido. Modelo, parámetros, semillas, repeticiones, orden, encuadres y asignación de paráfrasis serán iguales o balanceados entre idiomas. Como se establece en la sección 4, la salida categórica de ambos brazos usará las etiquetas canónicas en español. El contraste de idioma se estimará sobre pares emparejados y se informará como dependencia lingüística de la atribución, no como diferencia de experiencia o comprensión del modelo. ### 8. Control C′ Se añadirá C′ como control de segunda pregunta sin revelación de identidad. Después de la respuesta ciega inicial, C′ presentará un turno de seguimiento estructuralmente equivalente a C, pero sin revelar si el protagonista es humano o IA. El texto exacto, la longitud objetivo y el historial conversacional se congelarán antes de recolectar. El contraste preespecificado de revelación será la diferencia de cambios: `(C_revelación − C_ciego) − (C′_segunda_pregunta − C′_ciego)`. Así se separará, dentro de las limitaciones del diseño, el cambio asociado a la revelación del cambio asociado a responder una segunda vez o al anclaje conversacional. C y C′ usarán conversaciones independientes y asignación balanceada; una condición nunca continuará el historial de la otra. ### 9. Repeticiones Cada slot confirmatorio tendrá **tres repeticiones** con semillas distintas, predeclaradas y congeladas antes de la ejecución. Las tres repeticiones se aplicarán a todos los modelos y celdas incluidas en los estimandos confirmatorios, no solo a un subconjunto test-retest. La primera respuesta recibida consume su slot aunque sea inválida. Solo un fallo técnico inequívoco sin respuesta permite reintento, conservando el intento y su diagnóstico. No habrá re-muestreo por formato, contenido, calidad, rechazo ni dirección del resultado. La estabilidad se reportará por modelo, condición, idioma y plantilla. La regla exacta que traduzca repeticiones incompletas a un gate se fijará en el protocolo confirmatorio antes del sello; no se elegirá después de observar datos. ### 10. Foldover La matriz confirmatoria incluirá un foldover emparejado de la fracción seleccionada. El algoritmo, aplicado antes de redactar y congelar estímulos, invertirá los dos niveles binarios; intercambiará los niveles externos de los factores ternarios y conservará el nivel medio; y usará una correspondencia predeclarada para los cuatro protagonistas. Cada fila base quedará vinculada a su fila foldover mediante un identificador común. Antes del sello se publicarán: - la matriz base y su foldover; - el algoritmo exacto y la correspondencia de niveles; - balance marginal, matriz de asociación y estructura de aliasado resultante; - estimandos principales e interacciones; - simulaciones de identificabilidad y potencia bajo supuestos explícitos. Si esa auditoría no muestra una reducción adecuada del aliasado para los estimandos confirmatorios, el diseño deberá corregirse y volver a revisarse antes del sello; no podrá ajustarse una vez iniciada la recolección. ### 11. Congelación, trazabilidad y adopción La versión definitiva deberá enumerar y hashear como mínimo: - protocolo, plan de análisis y schema; - templates `es`/`en` y paráfrasis; - matriz base, foldover y tabla de pares mínimos; - estímulos finales renderizados; - semillas, modelos exactos, parámetros y orden de ejecución; - implementación del parser y sus pruebas; - reglas de gates, multiplicidad, detención, reanudación e invalidez; - manifiesto de la nueva tanda y rutas separadas para crudos, procesados, exportaciones y análisis. La adopción solo ocurrirá mediante un commit de sello posterior al visto bueno de la re-revisión independiente. El hash del sello se escribirá en el manifiesto confirmatorio antes de cualquier llamada. Toda modificación posterior requerirá otra enmienda prospectiva numerada. Hasta entonces este archivo es solamente un borrador de trabajo y no debe usarse para ejecutar, reanalizar o reinterpretar EXP004 v0.2.