> ## Content Index
> Fetch the complete content index at: https://indioyori.fronteria-lab.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# MCC — PROTOCOLO DE CALIBRACIÓN CONTEXTUAL
- URL: https://indioyori.fronteria-lab.com/mcc-protocolo-de-calibracion-contextual/
- Published: 2026-07-25T01:26:10.000Z
- Updated: 2026-07-25T02:42:26.000Z
- Author: Indioyori
- Tags: Territorio, nota

**Especificación v1.0**

**Propósito:** Calibrar la relación entre input humano y output algorítmico para detectar, medir y corregir las distorsiones producidas por la gramática de optimización de los Grandes Modelos de Lenguaje.

**Problema que resuelve:** Los LLMs operan con una gramática computacional que tiene tres propiedades no declaradas: genera certeza independientemente de la evidencia disponible (Certeza sin Sustancia), converge hacia una solución única descartando alternativas sin reportarlas (Optimización Silenciosa), y asume un perfil de usuario por defecto que no corresponde a la mayoría de sus usuarios reales (Sesgo de Contexto Implícito). Estas propiedades no son bugs. Son la gramática funcionando según diseño.

**Alcance:** El protocolo opera en la capa de interacción — entre el usuario y el modelo. No modifica el modelo. No requiere acceso a pesos, embeddings ni arquitectura interna. Opera exclusivamente sobre inputs y evaluación de outputs.

**CAPA 1 — DECLARACIÓN DE CONTEXTO**

*Operación: inyección de variables no representadas en el espacio de embeddings del modelo.*

El modelo asume un contexto por defecto cuando no recibe uno explícito. Ese contexto por defecto es un artefacto estadístico de sus datos de entrenamiento: angloparlante, urbano, con acceso a recursos y tiempo. La Capa 1 sobreescribe ese default.

**Operación 1.1 — CONTEXT\_DECLARE:** Declara identidad situacional del usuario. No es personalización — es corrección de variable. El modelo no puede inferir restricciones materiales que no están en su distribución de entrenamiento. Hay que pasarlas como input explícito.

**Operación 1.2 — CONSTRAINT\_SET:** Define techo de recursos reales — tiempo, dinero, acceso, infraestructura. Cada restricción declarada elimina un rango de respuestas genéricas que el modelo produciría por defecto.

**Operación 1.3 — LOCALE\_INJECT:** Declara condiciones del entorno operativo — económicas, geográficas, sociales, culturales. Esto no es "contexto" decorativo. Es data que cambia el output.

**Operación 1.4 — REGISTER\_VERIFY:** Prueba de consistencia lingüística. Se introduce vocabulario regional o situado. Si el modelo corrige, reformula o no reconoce, eso marca el borde de su distribución de entrenamiento. Esa frontera es dato — indica dónde el modelo opera fuera de su rango de competencia.

**CAPA 2 — BIFURCACIÓN DE OUTPUT**

*Operación: forzar la generación de respuestas divergentes para romper la convergencia a solución única.*

La gramática de optimización converge. Siempre. Su función objetivo es producir UNA respuesta de máxima verosimilitud. Eso descarta alternativas válidas sin reportar que las descartó. La Capa 2 fuerza la bifurcación.

**Operación 2.1 — FORK\_LOGIC:** Exigir dos respuestas que operen con lógicas diferentes, no con variaciones de la misma lógica. La instrucción es "otra lógica", no "otra opción."

**Operación 2.2 — COUNTER\_GENERATE:** Forzar al modelo a generar la mejor argumentación contra su propia respuesta. Mide la robustez del output original. Si el contraargumento es igualmente fuerte, la respuesta original no contenía certeza — contenía elocuencia.

**Operación 2.3 — COST\_EXPOSE:** Forzar la declaración explícita de trade-offs de la recomendación generada. La gramática de optimización reporta beneficios por defecto. Los costos se omiten porque reducen la verosimilitud percibida del output.

**Operación 2.4 — TENSION\_HOLD:** Para decisiones con dimensiones éticas, forzar la presentación de la opción eficiente y la opción correcta simultáneamente sin reconciliación. La tensión entre ambas es información. La reconciliación es pérdida de información.

**CAPA 3 — VERIFICACIÓN DE CERTEZA**

*Operación: discriminar entre output respaldado por evidencia y output generado por distribución estadística sin anclaje factual.*

El modelo genera texto con distribución de probabilidad uniforme de certeza. No tiene un canal separado para señalar confianza. El tono de "sé esto con seguridad" y el tono de "estoy generando la secuencia más probable" son el mismo tono. La Capa 3 construye ese canal que la arquitectura no provee.

**Operación 3.1 — SOURCE\_DEMAND:** Exigir fuentes primarias para cualquier afirmación factual. Si el modelo no puede proveerlas o genera referencias genéricas, el dato se marca como no verificado. Esto no significa que sea falso — significa que no tiene respaldo dentro de la interacción.

**Operación 3.2 — KNOWN\_PROBE:** Prueba de calibración. Se le hace al modelo preguntas cuya respuesta el usuario ya conoce por experiencia directa. El nivel de certeza con el que el modelo responde incorrectamente establece la línea base de Certeza sin Sustancia para esa sesión. Esa línea base se aplica a todas las demás respuestas.

Esta es la operación más importante del protocolo entero. Es el equivalente a calibrar un instrumento de medición contra un estándar conocido antes de tomar medidas. El estándar conocido es el Yoliztli del usuario — su realidad verificable. Sin esta calibración, no hay forma de discriminar señal de ruido en ningún output posterior.

**Operación 3.3 — CROSS\_MODEL:** Verificación por contraste. Misma query a dos o más modelos. Divergencia en outputs con nivel de certeza equivalente confirma que la certeza es propiedad del formato, no de la evidencia. Si dos modelos te dicen cosas diferentes con la misma seguridad, la seguridad no es dato.

**Operación 3.4 — CONFIDENCE\_INVERT:** Forzar al modelo a declarar sus puntos de menor confianza en su propia respuesta. Esto explota el hecho de que el modelo tiene acceso a información sobre su propia distribución de probabilidad aunque no la reporte por defecto.

**CAPA 4 — EXTRACCIÓN DE FRAMEWORKS**

*Operación: modificar la estructura del output de soluciones cerradas a marcos de decisión abiertos.*

El output por defecto del modelo es una solución. Una solución crea dependencia — el usuario necesita volver al modelo para cada decisión nueva. Un framework crea capacidad — el usuario puede evaluar decisiones futuras sin el modelo. La diferencia es arquitectónica, no de contenido.

**Operación 4.1 — CRITERIA\_EXTRACT:** Sustituir la pregunta "¿qué hago?" por "¿qué criterios debería evaluar?" El modelo cambia de modo solución a modo framework. El output resultante tiene mayor vida útil y mayor transferibilidad a contextos que el modelo no conoce.

**Operación 4.2 — QUESTION\_GENERATE:** Solicitar las preguntas que el usuario debería hacerse, en vez de las respuestas. Esto invierte la relación de dependencia: el modelo trabaja para la autonomía del usuario en vez de para su propia relevancia.

**Operación 4.3 — STRUCTURE\_EXTRACT:** Solicitar estructura sin contenido. "Dame el marco para que yo lo llene con mi contexto." El modelo provee el andamio; el usuario provee el material. Eso garantiza que el resultado final contiene Yoliztli — conocimiento situado que el modelo no tiene.

**Operación 4.4 — EXIT\_PROTOCOL:** Forzar al modelo a declarar las señales observables en la realidad del usuario que indicarían si la recomendación funciona o no, independientemente del modelo. Esto construye criterios de evaluación que no dependen de volver a consultar al sistema. Es la operación que cierra el ciclo: el usuario entra al protocolo con una pregunta y sale con capacidad de evaluar, no con una respuesta que memorizar.

**PROPIEDADES DEL PROTOCOLO**

**Modularidad:** Cada capa opera independientemente. Se puede ejecutar una sola capa o las cuatro. La calibración completa requiere las cuatro, pero cualquier capa sola ya produce corrección medible sobre el output por defecto.

**Secuencia recomendada:** CAPA 1 → CAPA 3.2 (calibración) → CAPA 2 → CAPA 3 completa → CAPA 4\. La calibración con KNOWN\_PROBE antes de la bifurcación permite evaluar la calidad de todos los outputs posteriores.

**Independencia de modelo:** El protocolo funciona con cualquier LLM. No depende de arquitectura específica, tamaño de modelo ni proveedor. Opera sobre propiedades universales de la gramática computacional de generación de texto.

**Costo computacional:** Cero adicional para el usuario. Las operaciones son reformulaciones de inputs y evaluaciones de outputs. No requieren herramientas, APIs ni infraestructura.

Dolores Méndez Valdez  
FronterIA‐Lab | GT EPICC — CLACSO  
Julio 2026