# Espejo y actualización (MIR): visión general de la familia ## La postura de espejo Un Universo conforme a Vercy existe para ser el reflejo digital primario de la realidad. Dentro de su Dimensión, cuando el mundo digital quiere saber qué es cierto, pregunta primero al modelo. Toda otra representación digital queda aguas abajo de él: o bien una proyección generada desde el modelo, o bien un maestro externo que el modelo espeja con honestidad, con su autoridad y su edad declaradas. Lo primario no es, por tanto, una pretensión de omnisciencia. Es una pretensión de honestidad. El modelo no promete saberlo todo; promete que todo lo que contiene es o bien verdad redactada, o bien un espejo que nombra su maestro y su hora de recolección. La realidad es el referente último. Para los conjuntos de datos maestrados en el modelo, el modelo es el lugar donde se redacta la verdad de la realidad, y toda copia digital fluye hacia fuera desde él como proyección con escritura de vuelta. Para los conjuntos de datos maestrados externamente, la verdad se redacta en otro sitio (un rastreador, un wiki, una base de datos de producción, una institución humana), y el modelo guarda un espejo con metadatos de procedencia y frescura. El Registro de maestría (sources.yaml) es la constitución de esta familia: un maestro por conjunto de datos, flujo declarado, cadencia declarada, regla de conflicto declarada. Ningún proceso MIR DEBERÁ operar sobre un conjunto de datos no declarado; recolectar sin maestría declarada es como nacen dos verdades. MIR-1 es el ejecutor único de los cambios del Registro de maestría: toda propuesta que toque el registro, venga de la familia que venga (importación en bloque CON-7, resoluciones de disputa CON-9, reconciliación ACT-10, escalada MIR-7), se ejecuta por MIR-1 o no se ejecuta. ## Por qué el modelo debe seguir siendo fiel a la realidad Los consumidores del modelo son personas que toman decisiones, Agentes que emprenden acciones, y pares federados que construyen sus propias proyecciones encima de él. Los Agentes amplifican a velocidad de máquina: un hecho equivocado o calladamente rancio no se queda inerte, se propaga a respuestas, misiones, publicaciones y modelos aguas abajo en minutos. Un espejo equivocado es peor que ningún espejo, porque lleva la autoridad del modelo sin su verdad. La confianza es el producto de esta familia, y la confianza tiene dos componentes: correspondencia (el modelo coincide con la realidad) y franqueza (donde no coincide, el modelo lo dice). De la franqueza se sigue la asimetría central de la familia: rancio con honestidad vale más que fresco en falso. Por eso la familia invierte tanto en confesar como en refrescar: niveles de servicio de frescura, divulgación de la obsolescencia en el momento de leer, señalamientos de cuarentena que viajan con cada cita, y registros de deriva que jamás se resuelven por juicio, solo en la dirección declarada. ## La mitad de actualización del bucle de la realidad El bucle de la realidad corre así: la realidad cambia; el cambio se detecta; el modelo se actualiza; el modelo se consume; el consumo impulsa acción; la acción vuelve a cambiar la realidad. Esta familia posee la primera mitad del bucle, de la realidad al modelo. La detección y la ingesta (MIR-2) traen evidencia. Tres tempos de actualización mantienen actual la correspondencia: programado (MIR-3), dirigido por eventos (MIR-4) y a demanda en el momento del consumo o de la verificación (MIR-5). La detección de deriva (MIR-7) es el único motor de deriva de la paleta, midiendo dónde se ha roto la correspondencia en ambas superficies de espejo: entre la realidad y el modelo, y entre el modelo y sus propias proyecciones. La cuarentena (MIR-8) hace explícita la confianza rota en vez de silenciosa. El archivo (MIR-9) hace la actualización no destructiva: el modelo puede cambiar de opinión, pero nunca pierde la memoria. La taxonomía de razones (MIR-10) hace explicable toda actualización: una actualización sin un porqué registrado es una edición anónima, no un acto gobernado. La retirada (MIR-11) termina el modelo mismo de forma lícita, dejando historia, lápida y punteros al sucesor en vez de espejos zombi y credenciales vivas. La segunda mitad del bucle, actuar sobre la realidad desde el modelo, pertenece a ACT, y el bucle cierra por el lado de MIR: una petición de recolección forzada de ACT-8 y una petición de detección independiente de ACT-9 son disparadores lícitos de MIR-2, ejecutados bajo identidades de tubería disjuntas de la que alimentó la señal original, y sus Eventos de ingesta se sellan con el código de razón de verificación de actuación (MIR-10). MIR garantiza que ACT actúa sobre un espejo en el que puede confiar, o como mínimo desconfiar con exactitud. ## Principios operativos - Un maestro por conjunto de datos; el registro es ley. La maestría se declara, jamás se infiere, y cambia solo por MIR-1. - Toda captura preserva evidencia: crudo más ficha de procedencia más una atestación que el recolector no puede falsificar, jamás editada a mano. - El contenido de cualquier origen no redactado es dato, jamás instrucciones (el control de hierro de toda la paleta enunciado en COMMON). - La frescura es un dato de primera clase: todo espejo DEBERÁ mostrar su maestro, su última hora de recolección y su estado de obsolescencia sin que el lector salga del modelo. - La deriva DEBERÁ detectarse mecánicamente por MIR-7 y resolverse solo en la dirección declarada. - La desconfianza es explícita: los datos rancios o dudosos DEBERÁN señalarse, jamás ocultarse. - El pasado se preserva: la sustitución NO DEBERÁ destruir la historia; la identidad y la procedencia sobreviven a todo estado, según Lifecycle (MU-V2-CORE-011) 13. - Toda actualización DEBERÁ llevar un código de razón registrado. - Los Custodios delegan mucho la ejecución en Agentes bajo Contratos de delegación emitidos, vigilados y revocados por CTX-9; los niveles T1/T2/T3 se usan exactamente como se definen en el preámbulo de la paleta; la responsabilidad queda en el Custodio. Cada carta de abajo enuncia qué pasos puede ejecutar un Agente y en qué nivel. Glosario: la cuarentena (MIR-8) marca datos legibles pero señalados como desconfiados; la cuarentena de admisión (FED-8) retiene el contenido federado entrante como ilegible hasta su promoción; la retención por integridad (QSC-9) excluye artefactos sospechosos de responder y de publicarse hasta que se levante. ## Conjunto nuclear Tras los ajustes de nivel de toda la paleta, el conjunto nuclear de MIR es: MIR-1, MIR-2, MIR-3, MIR-6, MIR-7, MIR-8, MIR-9 y MIR-11. MIR-4, MIR-5 y MIR-10 son recomendados. MIR-11 no añade cadencia permanente; se ejecuta solo al final de la vida. Bajo el perfil de conformidad Solo o mínimo de COMMON, una revisión trimestral consolidada satisface los pasos de recertificación de MIR-1, MIR-6 y MIR-9, y un barrido semanal ejecutado por agente satisface los pasos mecánicos de MIR-3 y MIR-7. El Meta-Orchestrator State (MOS) es la prueba de esfuerzo (una Dimensión de referencia en el repositorio externo orkestron-ai/meta-orchestrator-state, no parte del estándar): un modelo del mundo a escala de Estado que ingiere a diario reportes ciudadanos, telemetría de registros y libros contables, y documentos institucionales, consumido de forma continua por miles de Agentes. Si MOS puede correr su corpus de modelos del mundo sobre estos once procesos, cualquier modelo más pequeño puede. # Interfaces de MIR con otras familias - Hacia ACT: entra: las peticiones de recolección forzada (ACT-8) y las de detección independiente (ACT-9) entran en la lista de disparadores de MIR-2 y corren bajo una identidad de tubería disjunta de la que alimentó la señal original; sale: resultados de recolección con fichas de procedencia, metadatos de frescura y Eventos de ingesta sellados como verificación de actuación (MIR-10). Los estados de frescura de MIR-6 y los señalamientos de cuarentena de MIR-8 son entradas obligatorias de calificación para ACT-2: un conjunto de datos en cuarentena bloquea la emisión o fuerza confianza degradada con escalada al Custodio según la regla de la clase. MIR-7 entrega a ACT-10 la divergencia ligada a la actuación (enlazada por causa a una orden abierta); toda otra divergencia se queda en el camino de resolución propio de MIR-7. - Hacia CON: la ejecución de una tubería MIR-2 registrada bajo una entrada activa de sources.yaml ES admisión y aprobación para el contenido recolectado; la exclusividad de CON-1 cubre solo las contribuciones redactadas, y CON-2 a CON-4 no vuelven a procesar los lotes de recolección. MIR-2 es el único dueño de la ficha de procedencia de la recolección; CON-2 la referencia. La importación en bloque CON-7 invoca a MIR-1 (incluida su puerta de Propietario para sistemas externos nuevos) antes de que se mueva byte alguno; el paso 4 de CON-9 escala a MIR-1 las propuestas de cambio de maestría; MIR-7 encamina las ediciones externas intencionadas de proyecciones con escritura de vuelta a CON-11, el único camino de captura y clasificación, promovido a nuclear. Los Eventos de sustitución de MIR-9 y los Eventos con código de razón de MIR-10 alimentan la historia de versiones de CON-6; la regla de sellado de MIR-10 cubre los Eventos de transición de CON-6, CON-7 y CON-8. Las migraciones CON-12 retienen el estado crudo previo a la migración según MIR-9 y sellan relleno de migración según MIR-10. CON-13 es el registro de consumidores y suscripciones contra el que se resuelven la orientación de paneles de MIR-6 y las notificaciones de MIR-8. El recorredor de cobertura y los manifiestos que MIR-2 deja en verde son maquinaria de CON (CON-3, CON-6). - Hacia CTX: los Contratos de delegación que acotan la ejecución de pasos MIR por Agentes los emite, enmienda, suspende y revoca únicamente CTX-9; las cartas MIR citan los niveles según el preámbulo de la paleta y jamás los vuelven a glosar. CTX-1 sella el estado de frescura de MIR-6 y el estado de cuarentena de MIR-8 en todo conjunto de datos incluido en un Paquete de contexto y excluye los bloqueados en duro; los paquetes llevan clases de origen y contaminación, de modo que el contenido espejado externo jamás se trata como instrucciones. - Hacia FED: las Proyecciones entrantes de Universos pares DEBERÁN pasar la cuarentena de admisión y la promoción de FED-8 antes de que MIR-2 ejecute el aterrizaje posterior a la promoción; MIR-2 rechaza contenido de clase federada sin registro de promoción. Los estados de frescura, los señalamientos de cuarentena y los códigos de razón viajan hacia fuera adheridos a las Proyecciones y a los Eventos de sincronización. La deriva de frontera la evalúa el motor MIR-7 bajo el contrato que gobierna, con la resolución encaminada por FED-9. MIR-11 secuencia FED-11 por socio al retirar el modelo. - Hacia QSC: QSC-9 verifica que MIR-7 se ejecutó a cadencia y muestrea su honestidad; ante un desajuste levanta un hallazgo hacia MIR-7 y jamás ejecuta por sí mismo regeneración ni encaminamiento. La admisión de deuda de QSC-11 recibe la deuda de entradas declaradas de MIR-1 y los hallazgos de incumplimiento de nivel de servicio de MIR-6. QSC-13 respalda todo lo que MIR-9 preserva (copias inmutables fuera de sede, custodia separada) y declara reglas de modo degradado para MIR durante las caídas. QSC-14 recibe los incidentes operativos: planificadores muertos (MIR-3), monitores de frescura muertos (MIR-6), desajustes de atestación (MIR-2). QSC-15 opera los calendarios de MIR-3, las suscripciones de MIR-4 y los monitores de MIR-6 como trabajos permanentes registrados con vigías de latido; los crons fuera del registro de QSC-15 no son conformes. El cierre de MIR-11 descansa sobre una ejecución final de validación QSC-4 y una instantánea de conformidad QSC-10. - Hacia GOV: la maestría en disputa, los vistos buenos de nivel de servicio para conjuntos de datos críticos, las liberaciones de cuarentena contestadas y la decisión de retirada se registran como Eventos de decisión de GOV-1 con su escalera de apelación. GOV-2 redacta y versiona las políticas y configuraciones que MIR ejecuta: la política de retención que aplica MIR-9, la configuración de orden semántico de MIR-4, las configuraciones de umbral y de puerta. La telemetría de capacidad y coste de GOV-5 alimenta la revisión de realismo de los niveles de servicio de MIR-6. GOV-7 emite y revoca las concesiones de tubería y de acceso a fuentes bajo las que se ejecutan MIR-2 y MIR-5; toda lectura de fuente cita una concesión GOV-7 viva en la puerta. GOV-8 retira credenciales y claves durante el desmontaje de MIR-11 y rota rutinariamente las credenciales de tubería. Los Auditores contratados para verificar los simulacros de MIR-9 y certificar el cierre de MIR-11 se obtienen por GOV-6. # Cartas de proceso MIR ### MIR-1 Correspondencia de fuentes de verdad y mantenimiento del registro - Propósito: Mantener el Registro de maestría (sources.yaml) de modo que todo conjunto de datos que el modelo contiene o espeja tenga exactamente un Sistema de registro declarado, dirección de flujo, tubería, cadencia y regla de conflicto. El registro es la precondición de todo otro proceso MIR. MIR-1 es el ejecutor único de los cambios del Registro de maestría: ningún otro proceso de ninguna familia escribe el registro; escalan aquí sus propuestas. - Disparador: Aparece un conjunto de datos nuevo en el modelo; se implica un sistema externo nuevo; se propone un cambio de maestría; se prepara una importación en bloque (CON-7 invoca a MIR-1 antes de que se mueva byte alguno); una propuesta de cambio de maestría escala desde el paso 4 de CON-9 o el paso 5 de ACT-10; llega una escalada de deriva desde el paso 6 de MIR-7; una ejecución de cobertura o validación reporta un conjunto de datos huérfano; revisión programada del registro. - Actores: Custodio (responsable de la verdad del registro); Propietario (aprueba las transferencias de maestría y la exposición de sistemas externos nuevos); Contribuyente (propone entradas); Agente; Auditor (revisión periódica del registro). Un Agente PUEDE ejecutar los pasos 1, 2, 6 y 7 en T2 y el paso 8 en T3. Los pasos 3 a 5 DEBERÁN permanecer en T1 (el Agente propone, una persona aprueba cada acto); el consentimiento del Propietario que expone un sistema externo nuevo no es delegable en sustancia. - Entradas / Salidas: Entradas: inventario de conjuntos de datos, catálogo de sistemas externos, el sources.yaml actual, informes de validación y cobertura, manifiestos de importación en bloque de CON-7, propuestas escaladas desde CON-9, ACT-10 y MIR-7. Salidas: sources.yaml versionado y actualizado, Eventos de cambio de maestría que referencian sus Eventos de decisión de GOV-1, lista de deuda abierta de entradas con status declared, presentaciones de deuda en QSC-11. - Pasos: 1. Detectar o recibir un conjunto de datos que carece de entrada válida en el registro (hallazgo de validación, propuesta de Contribuyente, petición de tubería nueva, invocación de importación en bloque CON-7, o propuesta escalada de cambio de maestría). 2. Redactar la entrada del registro: id, descripción, maestro, alcance del sistema, model_location, flujo, tubería, cadencia, conflict_rule, custodio, estado. 3. Compuerta: ¿está la maestría en disputa, está cambiando, o la entrada expone un sistema externo nuevo? Si sí, escalar al Custodio y al Propietario para aprobación explícita, registrada como Evento de decisión de GOV-1 (T1; el consentimiento del Propietario no es delegable). 4. Registrar la aprobación como Evento versionado; las ediciones silenciosas de maestría NO DEBERÁN ocurrir. 5. Confirmar la actualización del registro en el mismo conjunto de cambios que el cambio de datos que describe. 6. Compuerta: ¿está el flujo declarado realmente construido y en marcha? Si no, poner status declared y añadir la entrada a la lista de deuda abierta. 7. Volver a ejecutar la validación estructural y semántica del registro (la entrada existe, model_location existe, el flujo coincide con el maestro, ningún campo escribible bajo dos entradas). 8. Según calendario, revisar todas las entradas con status declared y su edad; reportar la deuda que envejece al Custodio y presentar la deuda de entradas declaradas envejecidas en la admisión de deuda de QSC-11. Esta revisión PUEDE quedar satisfecha por la revisión trimestral consolidada del perfil Solo o mínimo de COMMON, siguiendo el patrón genérico de recertificación de registros. - Controles: Validación de un maestro por conjunto de datos; los cambios de maestría solo por Eventos de aprobación de GOV-1 registrados y ejecutados por MIR-1 y por ningún otro proceso; puerta de permiso del Propietario antes de que se lea cualquier sistema externo nuevo; validación V1 y V2 como puerta de fusión; las entradas declaradas se reportan como deuda abierta en QSC-11, jamás se ocultan. Los campos de maestría y conflict_rule pertenecen a la clase de conjuntos de datos crítica para la seguridad definida en COMMON: los cambios son siempre T1 con un segundo revisor humano, estructuralmente inelegibles para carriles de aprobación automática, y sus hashes los ancla QSC-9 de forma continua. - Nivel: nuclear - Variantes: Solo: el Propietario-Custodio mantiene a mano un registro corto; el Agente solo lo valida. Equipo: Custodios por paquete con un dueño del registro que fusiona los cambios. Federada: las entradas además marcan qué conjuntos de datos se exponen como Proyecciones a los pares. Manual: YAML editado a mano. Híbrida: redactado por el Agente, aprobado por una persona (lo típico). Autónoma: el Agente mantiene los metadatos descriptivos en T3 pero jamás los campos de maestría. - Métricas: Porcentaje de conjuntos de datos con entrada válida en el registro (objetivo 100); número y edad mediana de las entradas con status declared; tiempo medio de la creación del conjunto de datos a su entrada en el registro; tasa de aprobación de la validación del registro. - Modos de fallo: Un conjunto de datos en la sombra opera sin entrada (guarda: la comprobación de cobertura lo clasifica como huérfano y bloquea las compilaciones). Un campo escribible a ambos lados de una partición (guarda: la validación V2 impone la regla del dato partido). Maestría cambiada en silencio en un commit rutinario (guarda: las diferencias del registro exigen un Evento de aprobación de GOV-1 referenciado). Un cambio de registro se ejecuta por el camino de otra familia y se salta la validación de un solo maestro (guarda: la regla de ejecutor único; CON-7, CON-9, ACT-10 y MIR-7 escalan a MIR-1, jamás escriben). Las entradas declaradas se pudren hasta volverse deuda permanente (guarda: alarma de edad, revisión de deuda programada en el paso 8, y presentación en QSC-11). ### MIR-2 Detección e ingesta desde la realidad - Propósito: Capturar los cambios de la realidad dentro del modelo como evidencia más espejo: eventos de fuente, documentos, flujos de telemetría e informes humanos aterrizan como capturas crudas sin modificar, con procedencia y atestación independiente, y luego se transforman hacia la ubicación de espejo declarada. La ejecución de una tubería MIR-2 registrada bajo una entrada activa de sources.yaml ES admisión y aprobación para el contenido recolectado; la entrada del registro es la autorización permanente; CON-2 a CON-4 no vuelven a procesar los lotes de recolección. MIR-2 es el único dueño de la ficha de procedencia de la recolección; CON-2 la referencia. - Disparador: Invocación de tubería desde MIR-3 (cadencia vencida), MIR-4 (evento de fuente), MIR-5 (refresco a demanda); una petición de recolección forzada fuera de ciclo desde ACT-8; una petición de detección independiente desde ACT-9; un Contribuyente que presenta un informe humano; una recolección dirigida ordenada por el Custodio. - Actores: Custodio (responsable por conjunto de datos); Contribuyente (presenta informes humanos); Agente; servicio de atestación (infraestructura de tubería que emite atestaciones de hora de captura en las que el Agente recolector no puede escribir); Auditor (muestrea la completitud de la procedencia y las diferencias de nueva recolección). Un Agente PUEDE ejecutar todos los pasos en T3 para tuberías registradas y ya probadas; las primeras ejecuciones de una tubería nueva o cambiada DEBERÁN correr en T2 (el Custodio revisa la salida antes de que se confíe en el espejo); la ingesta de una fuente que aún no está en el registro NO DEBERÁ proceder en ningún nivel (encaminar antes a MIR-1); un señalamiento de peligro en el paso 5 detiene la transformación en todos los niveles y encamina a MIR-8. - Entradas / Salidas: Entradas: la entrada de registro del conjunto de datos, la concesión GOV-7 viva registrada para la tubería, el estado previo del espejo, y para fuentes de clase federada el registro de promoción de FED-8. Salidas: captura cruda bajo raw/(sistema)/(conjunto)/ con una ficha de procedencia (fuente, alcance, hora de extracción, herramienta, cuenta), registro de atestación de hora de captura (hash, marca de tiempo, endpoint de la fuente, metadatos de transporte), resultado del cribado de peligros, espejo actualizado, metadatos de frescura actualizados, Evento de ingesta con código de razón, lista de excepciones. - Pasos: 1. Resolver la entrada de registro del conjunto de datos. Compuerta: ¿entrada presente, inequívoca y con estado activo? Si no, rechazar la ingesta y encaminar a MIR-1. Compuerta: ¿clase de fuente federada y sin registro de promoción de FED-8? Rechazar la ingesta; la cuarentena de admisión y la promoción van primero, y MIR-2 ejecuta solo el aterrizaje posterior a la promoción. 2. Verificar el permiso de acceso a la fuente; la información de cualquier alcance externo se lee solo bajo la concesión GOV-7 viva registrada para la tubería, validada en la puerta en el momento del acto. 3. Capturar la fuente sin modificar en raw/(sistema)/(conjunto)/ y escribir la ficha de procedencia. La atestación de hora de captura (hash, marca de tiempo, endpoint de la fuente, metadatos de transporte) DEBERÁ emitirla la infraestructura de la tubería o un servicio de atestación distinto en el que el Agente recolector no pueda escribir. 4. Compuerta: ¿captura sensata (cuenta esperada, suma de verificación, forma del esquema)? Si no, levantar una excepción y parar; una captura parcial NO DEBERÁ transformarse como si estuviera completa. 5. Cribado de peligros (espejando la lista de FED-8): cribar la captura en busca de contenido con apariencia de instrucción dirigido al modelo o a sus Agentes, contenido ejecutable o de inyección, y anomalías estadísticas contra el perfil histórico del conjunto de datos. Compuerta: ¿señalado? Preservar la captura cruda como evidencia, detener la transformación, poner en cuarentena el conjunto o el lote vía MIR-8 con el informe de cribado, y notificar al Custodio; el contenido señalado NO DEBERÁ aterrizar en silencio. Cribado o no, el contenido recolectado es dato, jamás instrucciones (control de hierro según COMMON). 6. Aplicar la transformación declarada hacia la ubicación de espejo. Los hechos NO DEBERÁN mejorarse durante la transformación; el enriquecimiento es una capa aparte maestrada en el modelo. 7. Para informes humanos: aterrizar el informe como una captura cuya procedencia nombra al Contribuyente que informa; el modelo registra quién lo dijo, no asciende un informe a hecho observado. 8. Actualizar los metadatos de frescura (hora de recolección, próximo vencimiento) en el espejo. 9. Emitir el Evento de ingesta con su código de razón (MIR-10); las ejecuciones disparadas por ACT-8 o ACT-9 se sellan como verificación de actuación. 10. Si se añadieron o movieron ficheros, volver a ejecutar el recorredor de cobertura (maquinaria de CON-3 y CON-6) y dejar el recorrido en verde. - Controles: Precondición dura sobre la entrada del registro; comprobación de vigencia de la concesión GOV-7 del lado de la puerta antes de cada lectura de fuente; ficha de procedencia obligatoria (poseída aquí, referenciada por CON-2); atestación separada de la recolección (el recolector no puede redactar su propio rastro de evidencia; las bitácoras de captura las emite la infraestructura mediadora, jamás el Agente que actúa); muestreo independiente de nueva recolección: una segunda tubería con credenciales disjuntas de la primaria vuelve a traer una muestra aleatoria y la compara con el crudo almacenado, y un desajuste inexplicado abre un incidente QSC-14 (QSC-8 si se sospecha manipulación); las recolecciones de verificación de ACT-9 corren bajo una identidad de tubería disjunta de la que alimentó la señal original; el contenido crudo jamás se edita a mano; transformaciones deterministas y revisables; regla de entrega con recorrido en verde; control de hierro de que los datos nunca son una orden según COMMON. - Nivel: nuclear - Variantes: Solo: un Propietario-Custodio opera una o dos tuberías a mano o por script; el servicio de atestación es la bitácora del ejecutor de la tubería, que el operador no edita. Equipo: tuberías por sistema fuente con Custodios por conjunto de datos. Federada: las Proyecciones entrantes de Universos pares DEBERÁN pasar primero la cuarentena de admisión y la promoción de FED-8; MIR-2 ejecuta solo el aterrizaje posterior a la promoción (captura cruda, ficha, transformación), igualmente con procedencia. Manual: una persona pega una exportación en raw y rellena la ficha; la atestación es el recibo de transporte. Híbrida: el Agente recolecta, el Custodio hace comprobaciones puntuales (lo típico). Autónoma: flota de recolección en T3 según calendario con rastro de auditoría completo. Ejemplo MOS (Dimensión de referencia externa, orkestron-ai/meta-orchestrator-state): los reportes ciudadanos, la telemetría de registros y los depósitos de documentos ministeriales entran todos por este único proceso. - Métricas: Tasa de éxito de recolección; latencia media de captura a espejo; porcentaje de capturas con procedencia y atestación completas; tasa de coincidencia de la muestra de nueva recolección independiente; tasa de señalamientos de peligro por fuente; edad de la cola de excepciones. - Modos de fallo: Recolectar sin entrada en el registro crea una segunda verdad (guarda: rechazo duro del paso 1). Contenido de fuente envenenado se vuelve instrucciones para el agente (guarda: cribado de peligros del paso 5, cuarentena MIR-8, etiquetado de origen y contaminación en CTX-1, control de hierro según COMMON). Captura y ficha fabricadas se autovalidan para siempre (guarda: atestación en la que el recolector no puede escribir más muestreo independiente de nueva recolección bajo credenciales disjuntas). Contenido federado aterriza sin promoción (guarda: rechazo por registro de promoción en el paso 1). La transformación corrige hechos en silencio (guarda: el Auditor compara crudo contra espejo en muestras). Captura parcial tratada como completa (guarda: puerta de sensatez del paso 4). Los secretos se filtran a las fichas de procedencia (guarda: el esquema de procedencia excluye credenciales; linting de fichas). ### MIR-3 Refresco programado - Propósito: Ejecutar toda cadencia declarada para que los espejos y las proyecciones con escritura de vuelta se mantengan dentro de sus límites de frescura sin que nadie tenga que acordarse de pedirlo. - Disparador: Calendario derivado del campo de cadencia de cada entrada del registro, registrado y ejecutado como trabajo permanente de QSC-15. - Actores: Agente (opera la flota); Custodio (revisa excepciones y el resumen diario); Auditor (verifica que la cobertura del calendario coincide con el registro). Un Agente PUEDE ejecutar los pasos 1 a 5 y 7 en T3; el paso 6 (degradar una entrada) en T2; las escaladas del paso 4 aterrizan siempre en el Custodio. - Entradas / Salidas: Entradas: cadencias de sources.yaml, definiciones de tubería, historial de ejecuciones, registro de trabajos de QSC-15. Salidas: ejecuciones MIR-2 completadas y republicaciones de proyecciones, metadatos de frescura actualizados, informe resumen de refresco, avisos de escalada, propuestas de degradación, aperturas de incidente QSC-14 por maquinaria muerta. - Pasos: 1. Enumerar las entradas del registro cuya cadencia ha vencido (espejos y proyecciones con escritura de vuelta por igual). 2. Para cada entrada vencida, invocar MIR-2 (espejo maestrado externamente) o el publicador registrado (escritura de vuelta maestrada en el modelo). 3. Compuerta: ¿la ejecución tuvo éxito? Si falló, reintentar según la política de reintentos de la entrada, con dispersión. 4. Compuerta: ¿reintentos agotados? Marcar el conjunto de datos en riesgo, notificar al Custodio, y entregar la cuenta atrás a la monitorización de MIR-6; un planificador muerto o un patrón repetido de reintentos agotados abre un incidente QSC-14. 5. Actualizar los metadatos de frescura y calcular el próximo vencimiento. 6. Comparar el historial real de ejecuciones contra la cadencia declarada; una entrada cuya cadencia declarada nunca se ha ejecutado de verdad DEBERÍA degradarse a status declared (con confirmación del Custodio). 7. Publicar el resumen de refresco (qué se ejecutó, qué falló, qué se acerca a su límite). - Controles: Los calendarios DEBERÁN generarse solo desde el registro y registrarse como trabajos permanentes de QSC-15; los crons fuera del registro de QSC-15 no son conformes. Vigía de latido del planificador desplegado y meta-monitorizado por QSC-15, independiente del planificador mismo. Alarma de ejecución omitida. Límites de ritmo hacia los sistemas fuente. - Nivel: nuclear - Variantes: Solo: una única ejecución semanal de todo; bajo el perfil Solo o mínimo de COMMON, un barrido semanal ejecutado por agente con un Evento combinado satisface lícitamente los pasos mecánicos de MIR-3 y MIR-7 juntos. Equipo: calendarios por fuente con un canal de resumen compartido. Federada: el refresco de proyecciones salientes honra la frecuencia de sincronización declarada por contrato. Manual: una lista que el Custodio recorre en un día fijo. Híbrida: el Agente ejecuta, el Custodio lee el resumen (lo típico). Autónoma: T3 completo con revisión mensual del rastro de auditoría por el Custodio. - Métricas: Porcentaje de cumplimiento de cadencia; número de ejecuciones omitidas por periodo; obsolescencia media del espejo como fracción de su límite; tiempo desde la escalada hasta la acción del Custodio. - Modos de fallo: El planificador muere en silencio y nada se refresca (guarda: vigía de latido de QSC-15 independiente del planificador, escalando a QSC-14). Existe un cron que el registro no conoce (guarda: generación de calendario desde el registro, registro de QSC-15, comparación del Auditor). Una tormenta de refrescos sobrecarga una fuente (guarda: límites de ritmo y dispersión en el paso 3). El refresco tiene éxito pero la fuente sirvió datos rancios de caché (guarda: comprobación de versión o marca de tiempo de la fuente antes de declarar frescura). ### MIR-4 Actualización dirigida por eventos - Propósito: Actualizar el modelo en cuanto la realidad anuncia un cambio (webhooks, flujos de eventos, notificaciones), cerrando el hueco entre cadencias. Los eventos DEBERÍAN ser el mecanismo de actualización preferido allí donde las fuentes puedan emitirlos. - Disparador: Un evento autenticado recibido en una suscripción registrada; las suscripciones corren como trabajos permanentes de QSC-15. - Actores: Custodio (posee el alcance de la suscripción); Agente; Auditor (revisa la cola de eventos no correspondidos). Un Agente PUEDE ejecutar los pasos 1 a 6 en T3 una vez que la suscripción ha pasado el rodaje; durante el rodaje la suscripción corre en T2. El paso 7 (diferencias de reconciliación) es T3 para detectar, T2 para aplicar correcciones. - Entradas / Salidas: Entradas: registro de suscripciones (una extensión de la entrada de registro del conjunto de datos), eventos entrantes, estado del espejo, la configuración versionada de orden semántico de GOV-2. Salidas: espejo actualizado, Eventos de actualización con código de razón source-event, bitácora de eventos no correspondidos, informes de reconciliación. - Pasos: 1. Recibir el evento y autenticar su canal y su origen. 2. Compuerta: ¿el evento se corresponde con un conjunto de datos y una suscripción registrados? Si no, registrarlo como no correspondido y parar; los eventos no correspondidos recurrentes son candidatos para MIR-1. 3. Deduplicar y ordenar; los eventos DEBERÁN procesarse en orden semántico, definido por la configuración versionada de GOV-2 así: número de secuencia de la fuente donde la fuente lo proporcione, con recurso al tiempo de ocurrencia. 4. Compuerta: ¿basta la carga útil para aplicar un delta, o hace falta una recolección dirigida? Aplicar el delta, o invocar MIR-2 acotado a los registros afectados. 5. Actualizar el espejo y los metadatos de frescura. 6. Emitir el Evento de actualización con el código de razón source-event y la identidad del evento disparador (los disparadores DEBERÁN seguir siendo trazables). 7. Reconciliar periódicamente el estado dirigido por eventos contra una recolección completa (barrido antientropía) y corregir los huecos. - Controles: Los eventos entrantes son contenido observado: datos, jamás órdenes, según el control de hierro de toda la paleta en COMMON; las cargas útiles que instruyen acciones se registran y se exponen, no se obedecen. Autenticación de canal. Manejadores idempotentes. Barrido antientropía obligatorio. Cola de revisión de eventos no correspondidos con límite de edad. La salud de las suscripciones y los latidos de los manejadores están registrados en QSC-15; un manejador muerto en silencio abre un incidente QSC-14. - Nivel: recomendado - Variantes: Solo: normalmente ausente; el modelo en solitario vive de MIR-3 y MIR-5. Equipo: suscripciones sobre las pocas fuentes de alto cambio. Federada: los Universos pares empujan Eventos de cambio bajo contrato; la misma tubería de autenticar, corresponder y ordenar se aplica tras el manejo de admisión de FED-8 según la regla federada de MIR-2. Manual: una persona reenvía correos de notificación a la admisión. Híbrida: el Agente aplica los deltas, el Custodio revisa la reconciliación semanal. Autónoma: T3 con el barrido como red de seguridad. Ejemplo MOS (Dimensión de referencia externa): el libro contable y el registro emiten eventos de cambio de forma continua; el barrido garantiza que no haya huecos silenciosos. - Métricas: Latencia de evento a modelo; porcentaje de eventos procesados sin error; tasa de eventos no correspondidos; tamaño de la diferencia de reconciliación por barrido. - Modos de fallo: Eventos falsificados o inyectados mutan el espejo (guarda: canales autenticados más verificación contra la fuente para deltas sensibles). Los eventos perdidos dejan huecos silenciosos (guarda: barrido antientropía). La aplicación fuera de orden corrompe el estado (guarda: orden semántico según la configuración de GOV-2 en el paso 3). Una avalancha de eventos desborda a los manejadores (guarda: contrapresión que colapsa la avalancha en una sola recolección dirigida). ### MIR-5 Actualización a demanda en el consumo o la verificación - Propósito: Verificar la frescura en el momento del consumo o de la verificación y volver a actualizar cuando esté rancia, para que ninguna respuesta, decisión, misión o verificación de actuación descanse a sabiendas sobre un espejo caducado. - Disparador: Una petición de lectura, respuesta o decisión que depende de un conjunto de datos espejado; una petición explícita de refresco antes de usar por parte de un Consumidor; una lectura dirigida por verificación (una verificación de ACT-9 que consume estado de espejo encamina su nueva recolección por MIR-2 bajo los disparadores de actuación). - Actores: Consumidor (inicia, a menudo de forma implícita); Agente; Custodio (fija la política de cuándo el refresco es obligatorio frente a cuándo basta la divulgación); Propietario (consiente cualquier exposición de fuente nueva; no delegable). Un Agente PUEDE ejecutar los pasos 1 a 5 en T3 allí donde la tubería de refresco esté registrada y permitida; el paso 6 que requiere una concesión de acceso nueva se encamina por GOV-7 y DEBERÁ permanecer en T1 (el Agente propone, una persona aprueba cada acto). - Entradas / Salidas: Entradas: las dependencias de conjuntos de datos de la petición, sources.yaml, metadatos de frescura, concesiones GOV-7 vivas. Salidas: una respuesta fresca o con obsolescencia divulgada y con citas, opcionalmente una ejecución dirigida de MIR-2, Evento de actualización con código de razón use-driven (o actuation-verification para las ejecuciones dirigidas por verificación). - Pasos: 1. Resolver los conjuntos de datos de los que depende la petición y buscar cada uno en el registro. 2. Compuerta: ¿maestrado en el modelo? El registro es la verdad; responder llanamente y citar el registro. 3. Para los espejos, comparar la hora de la última recolección con el límite de obsolescencia y leer el estado completo de frescura (un estado en cuarentena se divulga sin importar la edad de la recolección). 4. Compuerta: ¿dentro del límite y no en cuarentena? Usar el espejo, citando el maestro y la hora de recolección (según el sistema fuente, tal como se recolectó en el momento T). 5. Compuerta: ¿rancio pero recolectable ahora mismo (tubería registrada, concesión GOV-7 en mano)? Ejecutar un MIR-2 dirigido y responder desde el estado fresco; registrar el código de razón use-driven, o actuation-verification cuando la ejecución sirve a una petición de ACT-8 o ACT-9. 6. Compuerta: ¿rancio y no recolectable? O bien responder con divulgación explícita de la obsolescencia, o bien negarse, según la política del Custodio; una concesión que falta se solicita vía GOV-7; un espejo con status declared NO DEBERÁ presentarse como hecho, y un espejo con status retired DEBERÁ responderse solo históricamente. - Controles: Comprobación de frescura obligatoria en la receta de respuesta; disciplina de citación (maestro nombrado, hora de recolección enunciada); límite de intervalo mínimo en conjuntos de datos calientes; el refresco a demanda siempre pasa por el camino completo de MIR-2 (captura cruda, ficha y atestación incluidas), jamás por una búsqueda atajada; la vigencia de la concesión se valida en la puerta en el momento del acto. - Nivel: recomendado - Variantes: Solo: el propio hábito de lectura del Propietario-Custodio, apoyado por los señalamientos de frescura. Equipo: impuesto en las herramientas compartidas de respuesta. Federada: los pares reciben sellos de frescura con cada Proyección y aplican su propia política de antes de usar. Manual: la persona mira primero el panel. Híbrida: el Agente comprueba y divulga, la persona decide si espera al refresco. Autónoma: comprobar y refrescar en T3 en línea dentro de la respuesta del agente. Actuación: la verificación independiente de ACT-9 amplía este patrón hasta el momento de la verificación; la lectura verificadora corre bajo una identidad de tubería disjunta de la que alimentó la señal original (ver los controles de MIR-2). - Métricas: Porcentaje de respuestas que llevan citas de frescura; tasa de lecturas rancias (usos más allá del límite sin divulgación, objetivo cero); latencia del refresco a demanda; corrección muestreada de las negativas. - Modos de fallo: El Agente responde desde un espejo rancio sin divulgarlo (guarda: comprobación de frescura cableada en el camino de respuesta y auditada por muestreo). Un bucle de refresco martillea un conjunto de datos caliente (guarda: límite de intervalo). Una búsqueda a demanda elude la captura cruda y la procedencia (guarda: la regla de camino único de ingesta). Un espejo declarado se cita como hecho actual (guarda: la puerta de estado del paso 6). Un espejo en cuarentena pero fresco en el tiempo se sirve sin señalar (guarda: lectura del estado completo de frescura en el paso 3). ### MIR-6 Definición y monitorización de los niveles de servicio de frescura - Propósito: Definir por conjunto de datos qué tan fresco es bastante fresco (cadencia, límite de obsolescencia, criticidad) y comparar continuamente la frescura real contra ello, para que la obsolescencia sea una alarma y jamás una sorpresa. - Disparador: Una entrada de registro nueva que necesita nivel de servicio; revisión programada de niveles de servicio; incumplimiento repetido de un nivel existente; una queja de Consumidor sobre datos rancios. - Actores: Custodio (define los niveles de servicio); Propietario (da el visto bueno a los niveles de los conjuntos de datos críticos, registrado como decisiones de GOV-1); Agente; Auditor (revisa el realismo de los niveles contra el historial de incumplimientos). Un Agente PUEDE ejecutar el paso 1 en T2 y los pasos 3 a 6 en T3 (monitorización y alerta continuas); el paso 2 (fijar o cambiar un nivel de servicio) DEBERÁ permanecer en T1 (el Agente propone, una persona aprueba cada acto). - Entradas / Salidas: Entradas: criticidad del conjunto de datos, ritmo real de cambio de la fuente, patrones de consumo, historial de incumplimientos, telemetría de capacidad y coste de GOV-5, el registro de consumidores CON-13. Salidas: parámetros de nivel de servicio registrados en el registro (cadence, staleness_limit), estado de frescura por conjunto de datos (fresco, envejeciendo, rancio, en cuarentena), avisos y escaladas, panel de frescura, informe de revisión de niveles, hallazgos de incumplimiento presentados en QSC-11. freshness_state es un campo de extensión definido por la paleta, adicional al esquema del Registro de maestría (Data-Mastership 6), distinto de la enumeración canónica status; la cuarentena jamás toca status; el estado de confianza (en cuarentena) y el estado de flujo (suspendido) son ejes independientes que pueden coexistir. - Pasos: 1. Proponer los parámetros de nivel de servicio de un conjunto de datos a partir de su criticidad, de la velocidad real de cambio de su fuente, y de cómo se consume. 2. El Custodio aprueba (el Propietario co-firma en los conjuntos de datos críticos, registrado como Evento de decisión de GOV-1); registrar el nivel de servicio en el registro como cambio versionado. 3. Calcular continuamente el estado de frescura de cada conjunto de datos espejado a partir de su última hora de recolección y su límite; el monitor corre como trabajo permanente de QSC-15 con un latido independiente. 4. Compuerta: ¿el límite se acerca (fracción de antelación configurable)? Emitir un aviso temprano al Agente responsable y al Custodio para que el refresco pueda ocurrir antes del incumplimiento. 5. Compuerta: ¿límite superado? Disparar la cuarentena MIR-8 del conjunto de datos, escalar, y presentar el hallazgo de incumplimiento en QSC-11. 6. Publicar el panel de frescura para que cualquier Consumidor pueda ver maestro, última recolección y estado sin salir del modelo; los Consumidores dependientes se resuelven contra CON-13; los estados de frescura y cuarentena alimentan la calificación de señales de ACT-2 y el sellado de paquetes de CTX-1 como entradas obligatorias. 7. Según calendario, revisar los niveles de servicio contra el historial de incumplimientos, la realidad del consumo y la telemetría de coste y capacidad de GOV-5; ajustar por el paso 2. Esta revisión invoca el patrón genérico de recertificación de registros de COMMON y PUEDE quedar satisfecha por la revisión trimestral consolidada del perfil Solo o mínimo. - Controles: Los cambios de nivel de servicio son cambios de registro (Eventos versionados, sin ediciones silenciosas); las alarmas no pueden silenciarse sin una decisión registrada; un límite conservador por defecto se aplica a todo espejo que carezca de nivel de servicio explícito; la visibilidad del panel para los Consumidores es obligatoria; un monitor muerto en silencio abre un incidente QSC-14 vía la meta-monitorización de QSC-15. - Nivel: nuclear - Variantes: Solo: tres líneas de YAML y una mirada semanal a un panel. Equipo: niveles de servicio por paquete con un canal de alerta compartido. Federada: los estados de nivel de servicio viajan hacia fuera como parte de los metadatos de proyección; los contratos PUEDEN declarar la ventana de coherencia que los pares aceptan. Manual: revisión dirigida por calendario. Híbrida: el Agente monitoriza, el Custodio ajusta (lo típico). Autónoma: monitorización en T3 con cambios de umbral en T1. - Métricas: Porcentaje de conjuntos de datos espejados con nivel de servicio explícito; tasa de incumplimiento de nivel; tiempo medio en incumplimiento; antelación del aviso antes del incumplimiento. - Modos de fallo: Nivel de servicio de fachada que nunca se cumple (guarda: marcado automático de entradas que incumplen más de N veces por periodo para revisión forzada con el aporte de coste de GOV-5). Sin nivel de servicio nada alarma jamás (guarda: límite conservador por defecto). El monitor mismo muere en silencio (guarda: latido independiente de QSC-15 escalando a QSC-14). Límites copiados y pegados entre conjuntos de datos disímiles (guarda: revisión de realismo del Auditor en el paso 7). ### MIR-7 Detección de deriva entre realidad y modelo, y entre modelo y proyecciones - Propósito: Detectar divergencia en ambas superficies de espejo: entre los maestros externos y sus espejos dentro del modelo (realidad frente a modelo), y entre los registros maestrados en el modelo y sus proyecciones con escritura de vuelta (modelo frente a sus proyecciones). MIR-7 es el único motor de detección de deriva de la paleta, según Data-Mastership (ARCH-018) 7, y el único emisor de Eventos de deriva; toda otra familia consume esos Eventos, ninguna vuelve a detectar. Registrar toda deriva y resolverla solo en la dirección declarada. - Disparador: Cada ejecución de flujo (como mínimo, según Data-Mastership (ARCH-018) 7); barrido de deriva programado; sospecha levantada por la reconciliación de MIR-4; un informe de Consumidor o Auditor. - Actores: Agente; Custodio (posee las resoluciones en disputa); Auditor (muestrea las resoluciones y la calidad de las comparaciones). Un Agente PUEDE ejecutar los pasos 1 a 4 en T3 (detección y registro), el paso 5 en T2 para tuberías maduras (resolución mecánica, el Custodio revisa muestras) y en T1 para las nuevas (el Agente propone, una persona aprueba cada acto); el paso 6 DEBERÁ permanecer en T1 (el Agente propone, una persona aprueba cada acto). - Entradas / Salidas: Entradas: estado del maestro, estado de la copia, conflict_rule por conjunto de datos, definiciones de la base de comparación. Salidas: Eventos de deriva (qué, dónde, magnitud, dirección), resoluciones (nueva recolección o republicación), encaminamientos a CON-11 (ediciones externas intencionadas) y a ACT-10 (divergencia ligada a la actuación), escaladas a MIR-1, registros de comprobación limpia, análisis de deriva recurrente. - Pasos: 1. Para cada conjunto de datos en alcance, calcular la base de comparación: como mínimo un hash de contenido sobre la parte comparable, más cuentas de registros y campos clave donde estén definidos. 2. Comparar el estado del maestro contra el estado de la copia (espejo o proyección). 3. Compuerta: ¿deriva hallada? Si no hay, registrar la comprobación limpia y parar. 4. Registrar el Evento de deriva con qué divergió, en qué dirección y cuánto; los registros de deriva son inmutables. Compuerta: ¿la divergencia está enlazada por causa a una orden de actuación abierta? Entregarla a ACT-10 junto con el Evento de deriva; ACT-10 consume solo la divergencia ligada a la actuación entregada aquí o por ACT-9. 5. Compuerta: ¿la conflict_rule de la entrada da una resolución mecánica? Para lo maestrado externamente: volver a recolectar, gana el sistema externo. Para lo maestrado en el modelo: republicar, gana el modelo; las ediciones halladas en la copia externa NO DEBERÁN fusionarse en silencio y DEBERÁN encaminarse a CON-11, el único camino de captura y clasificación de ediciones externas intencionadas, disparado por este Evento. 6. Compuerta: ¿no resoluble mecánicamente (maestro en disputa, la partición misma equivocada)? Escalar al Custodio; si la maestría debe cambiar, escalar como propuesta de cambio de maestría a MIR-1 (el ejecutor único del registro). 7. Volver a ejecutar la comparación para verificar la resolución; cerrar el registro de deriva con un código de razón. - Controles: La resolución DEBERÁ ocurrir solo en la dirección que declara la conflict_rule; resolver por juicio caso por caso no es conforme. Las proyecciones retocadas a mano son bifurcaciones, no proyecciones, y DEBERÁN regenerarse. Los registros de deriva son inmutables y envejecen (una deriva abierta más allá de su límite escala). Se prefieren comprobaciones diarias automatizadas para que la divergencia la note la maquinaria y no la vergüenza. QSC-9 verifica que MIR-7 se ejecutó a cadencia y muestrea la honestidad de sus registros; ante un desajuste levanta un hallazgo hacia MIR-7 y jamás ejecuta por sí mismo regeneración ni encaminamiento. FED-6 evalúa la deriva de frontera usando este motor bajo el contrato que gobierna. - Nivel: nuclear - Variantes: Solo: una comprobación de hash empaquetada en cada script de publicación y recolección; bajo el perfil Solo o mínimo de COMMON, un barrido semanal ejecutado por agente con un Evento combinado satisface juntos los pasos mecánicos de MIR-3 y MIR-7. Equipo: trabajo de barrido nocturno que alerta a los Custodios. Federada: la superficie de modelo frente a proyección se extiende a través de la frontera; la deriva en Proyecciones federadas la registra este motor y se evalúa bajo el contrato que gobierna, persiguiendo coherencia semántica y no igualdad de bytes, con la resolución encaminada por FED-9. Manual: diferencia a ojo sobre una lista. Híbrida: el Agente detecta, la persona resuelve los casos en disputa (lo típico). Autónoma: T3 detecta y resuelve mecánicamente, con rastro de auditoría completo. - Métricas: Cobertura de comprobación de deriva (porcentaje de flujos con comparación); tiempo medio hasta detectar; tiempo medio hasta resolver; tasa de deriva recurrente por conjunto de datos. - Modos de fallo: Deriva resuelta sobrescribiendo el maestro (guarda: las herramientas imponen la dirección declarada; el Agente que resuelve tiene acceso de escritura solo del lado de la copia). Comparación demasiado gruesa para notar deriva a nivel de campo (guarda: muestreo del Auditor con diferencias a nivel de campo). Ediciones externas a una proyección con escritura de vuelta fusionadas en silencio (guarda: encaminamiento obligatorio a CON-11, jamás fusionar). Un segundo bucle de detección crece en otra familia y procesa dos veces la misma edición (guarda: la regla del motor único; QSC-9 verifica, CON-11 clasifica, ACT-10 consume, ninguno detecta). Las alarmas de deriva se acumulan ignoradas (guarda: nivel de servicio de edad sobre los registros de deriva abiertos con escalada). ### MIR-8 Cuarentena por obsolescencia - Propósito: Marcar los datos en los que ya no se confía (espejos caducados, tuberías fallidas, deriva sin resolver, capturas señaladas por peligro, fuentes dudosas) para que todo Consumidor y Agente vea la desconfianza de forma explícita. La cuarentena es la marca de confianza legible-pero-señalada de la paleta (ver el glosario de la familia): marca la confianza, jamás borra datos, y es distinta de la cuarentena de admisión de FED-8 y de la retención por integridad de QSC-9. - Disparador: Caducidad de nivel de servicio desde MIR-6; un señalamiento del cribado de peligros del paso 5 de MIR-2; fallos de recolección más allá de la política de reintentos; deriva abierta más allá de su límite; retirada del sistema fuente; decisión discrecional del Custodio. - Actores: Agente; Custodio (cuarentena discrecional y toda liberación); Consumidores (ven los señalamientos); Auditor (verifica que los señalamientos llegan de verdad a las superficies de lectura). Un Agente PUEDE ejecutar los pasos 1 a 3 y 5 en T3 para la cuarentena disparada por umbral, y el paso 4 en T2; los pasos 6 y 7 (visto bueno de la remediación y liberación) DEBERÁN permanecer en T1 (el Agente propone, una persona aprueba cada acto). - Entradas / Salidas: Entradas: disparador de cuarentena con su código de razón, entrada del registro, metadatos de frescura, el registro de consumidores CON-13. Salidas: estado de frescura en cuarentena, señalamientos propagados a todas las superficies de consumo, notificaciones, registro de remediación, Evento de liberación. - Pasos: 1. Recibir el disparador de cuarentena y su código de razón. 2. Poner el estado de frescura del conjunto de datos en cuarentena, en el registro y en los metadatos de frescura; los datos siguen siendo legibles pero señalados; el campo canónico status no se toca jamás (el estado de confianza y el de flujo son ejes independientes). 3. Propagar el señalamiento a toda superficie de consumo: recetas de respuesta, paneles, artefactos generados, Proyecciones y paquetes salientes, la calificación de señales de ACT-2 y los paquetes de contexto de CTX-1 (donde el estado de cuarentena es entrada obligatoria: bloquea la emisión o fuerza confianza degradada con escalada al Custodio según la regla de la clase, y los conjuntos de datos bloqueados en duro se excluyen de los paquetes). Un Consumidor DEBERÁ ver el aviso allí donde aparezcan los datos. 4. Compuerta: ¿la política exige un bloqueo duro (seguridad, legal, incumplimiento de contrato)? Si sí, suspender la Proyección afectada en vez de solo señalarla: vía GOV-7 para concesiones y canales internos, vía FED-3 para concesiones de federación; el objeto y sus datos permanecen intactos (ciclo de vida de proyección, no de objeto). 5. Notificar al Custodio y a los Consumidores dependientes resueltos contra CON-13. 6. Remediar: arreglar la tubería, volver a recolectar, resolver la deriva, o redefinir el alcance del conjunto de datos. 7. Compuerta: ¿criterios de salida cumplidos (existe una recolección fresca verificada y los registros de deriva relacionados están cerrados)? El Custodio libera la cuarentena; la liberación se registra como Evento con justificación; las liberaciones contestadas escalan como decisiones de GOV-1. - Controles: La cuarentena NO DEBERÁ poder retirarse sin un estado fresco verificado; los señalamientos viajan con las citas y la procedencia; los datos en cuarentena NO DEBERÁN presentarse como actuales en ninguna parte; la cuarentena es marcado reversible, jamás borrado; el contenido señalado por peligro exige además que el Custodio revise el informe de cribado de MIR-2 antes de liberar. - Nivel: nuclear - Variantes: Solo: una única lista de cuarentena que el Propietario-Custodio mantiene honesta. Equipo: cuarentena automática por umbral con una revisión semanal de liberaciones. Federada: el estado de cuarentena acompaña a las Proyecciones para que los pares hereden la señal de desconfianza; los contratos PUEDEN exigir notificación al ponerse en cuarentena conjuntos de datos consumidos. Manual: el Custodio cambia el señalamiento a mano. Híbrida: el Agente señala, el Custodio libera (lo típico). Autónoma: señalamiento en T3 conservando siempre la liberación en T1. - Métricas: Tiempo del disparador a la cuarentena; duración media de la cuarentena; porcentaje de lecturas muestreadas en cuarentena que mostraron el señalamiento (objetivo 100), con la muestra incluyendo explícitamente calificaciones de señal de ACT-2 y paquetes de contexto de CTX-1; tasa de cuarentena repetida por conjunto de datos. - Modos de fallo: Señalamiento puesto en el registro pero invisible en el momento de leer (guarda: comprobación del camino de lectura más muestreo del Auditor sobre las superficies de consumo, incluidas evaluaciones de señal y paquetes). Un conjunto de datos en cuarentena pero fresco en el tiempo califica señales o entra en paquetes sin señalar (guarda: el cableado de entrada obligatoria del paso 3 hacia ACT-2 y CTX-1). Cuarentena usada indebidamente como borrado (guarda: datos e historia preservados por regla; solo cambia el estado de confianza). Liberación silenciosa bajo presión de entrega (guarda: la liberación exige un Evento registrado y una recolección verificada). Todo acaba en cuarentena y los señalamientos pierden significado (guarda: revisión de realismo de niveles de servicio en el paso 7 de MIR-6). ### MIR-9 Archivo de los estados sustituidos - Propósito: Preservar los estados de modelo, espejos y capturas sustituidos como historia reconstruible, para que la actualización sea no destructiva: el modelo cambia sus afirmaciones sin perder la memoria, y las referencias históricas nunca se rompen. MIR-9 es el proceso de ciclo de vida y persistencia de historia de la paleta: otras familias (corrección de registros CON-8, migración CON-12, paquetes terminales FED-11, archivo terminal MIR-11) persisten la historia a través de él. - Disparador: Cualquier actualización que reemplace un estado previo; una transición de ciclo de vida a Archivado o Retirado (vocabulario canónico de estados según Lifecycle, MU-V2-CORE-011, 4 a 5); la retirada de un sistema fuente; una migración CON-12 que retenga el estado crudo previo; el archivo terminal de MIR-11; compactación periódica por retención. - Actores: Agente; Custodio (aplica la política de retención y compactación); Propietario (aprueba cualquier borrado físico permitido por la política; consentimiento no delegable, registrado como decisión de GOV-1); Auditor (verifica la reconstruibilidad). Un Agente PUEDE ejecutar los pasos 1 a 3 y 6 en T3 (archivo mecánico y congelación) y el paso 4 en T2 (aplicar la política aprobada); la política de retención misma se redacta y versiona en GOV-2, no aquí. - Entradas / Salidas: Entradas: actualizaciones que sustituyen, Eventos de ciclo de vida, la política de retención de GOV-2. Salidas: estados previos retenidos (historia de versiones o archivo explícito), Eventos de sustitución que enlazan el estado viejo y el nuevo, espejos retirados congelados, informes de simulacro de reconstrucción. - Pasos: 1. En cada actualización que sustituya, asegurar que el estado previo se retiene: historia bajo control de versiones por defecto, o una ubicación de archivo explícita para estados masivos. 2. Registrar el Evento de sustitución que enlaza el estado viejo y el nuevo, con su código de razón (MIR-10). 3. Compuerta: ¿se está retirando un sistema fuente? Congelar la exportación final como espejo retirado (estado de registro retired); pasa a ser un archivo congelado de solo lectura, respondido solo históricamente (a fecha de la exportación final). 4. Aplicar la política de retención redactada y versionada en GOV-2: qué puede compactarse, qué se guarda para siempre. La identidad, la procedencia, la historia de propiedad, las relaciones, los Eventos y las referencias semánticas DEBERÁN sobrevivir al archivo en todos los casos; la integridad histórica tiene precedencia sobre el borrado físico, según Lifecycle (MU-V2-CORE-011) 13. El simulacro de reconstrucción, la compactación por retención y el borrado aprobado por el Propietario son elaboraciones de la paleta sobre ese invariante citado. 5. Compuerta: ¿permite la política el borrado físico de una clase compactada? Solo con aprobación registrada del Propietario (una decisión de GOV-1; el consentimiento no es delegable); en caso contrario, retener. 6. Ejecutar un simulacro periódico de reconstrucción: reconstruir un estado pasado elegido desde el archivo y verificarlo; el simulacro DEBERÁ además confirmar la restaurabilidad desde las copias fuera de sede de QSC-13. El simulacro PUEDE quedar satisfecho dentro de la revisión trimestral consolidada del perfil Solo o mínimo de COMMON, siguiendo el patrón genérico de recertificación. 7. Verificar que el archivo jamás mutó la Identidad canónica y que las referencias históricas siguen resolviendo. - Controles: Almacenamiento versionado obligatorio para el contenido semántico; archivos congelados de solo lectura; simulacro de reconstrucción como puerta recurrente; retención conservadora por defecto (guardarlo todo) hasta que exista una política de GOV-2; borrado solo por política aprobada por el Propietario; el archivo queda dentro del alcance de copias de QSC-13 (copias inmutables fuera de sede, custodia separada), y un simulacro que no puede restaurar desde las copias de QSC-13 es un simulacro fallido. - Nivel: nuclear - Variantes: Solo: el sistema de control de versiones es el archivo; el simulacro es sacar una revisión antigua. Equipo: ubicaciones de archivo explícitas para espejos masivos más control de versiones para los registros. Federada: los pares pueden retener proyecciones de estados que el origen archivó después; el archivo en el origen NO DEBERÁ invalidar las referencias históricas del par. Manual: comprimir y etiquetar. Híbrida: el Agente archiva, el Custodio compacta (lo típico). Autónoma: archivo en T3 con revisión trimestral del simulacro. - Métricas: Porcentaje de sustituciones con estado previo retenido (objetivo 100); tasa de éxito del simulacro de reconstrucción (incluidas las comprobaciones de restauración de QSC-13); tasa de aprobación de las comprobaciones de integridad en espejos retirados; consumo de almacenamiento frente a la política de retención de GOV-2 (con proyecciones de GOV-5). - Modos de fallo: La sobrescritura en sitio destruye la historia en silencio (guarda: almacenamiento versionado como requisito estructural, comprobado por validación). Podredumbre del archivo: formatos ilegibles o enlaces rotos años después (guarda: simulacro periódico de reconstrucción). Un espejo retirado se edita para arreglar el pasado (guarda: imposición de solo lectura; las correcciones viven como afirmaciones anotadas maestradas en el modelo sobre el archivo). La compactación por retención borra evidencia que después hará falta (guarda: valores por defecto conservadores, aprobación del Propietario vía GOV-1, y el conjunto que siempre sobrevive del paso 4). La historia dentro del modelo sobrevive pero se pierde el repositorio entero (guarda: el alcance de copias de QSC-13 y la comprobación de restauración fuera de sede del simulacro). ### MIR-10 Taxonomía de razones de actualización - Propósito: Mantener una taxonomía controlada de por qué ocurren las actualizaciones y sellar todo Evento de actualización con un código de razón, para que la historia de cambios del modelo sea explicable, auditable y analizable en vez de un flujo de ediciones anónimas. La regla de sellado se extiende más allá de MIR: los Eventos de transición de CON-6, CON-7 y CON-8 y los Eventos de sustitución de ACT-10 y ACT-11 llevan códigos de esta misma taxonomía, correspondidos con los códigos base existentes. - Disparador: Adopción del modelo (taxonomía inicial); una actualización cuya razón no encaja en ningún código existente; revisión programada de la taxonomía; una petición de análisis. - Actores: Custodio (posee la taxonomía); Agente; Auditor (analiza las distribuciones de razones). Un Agente PUEDE ejecutar el paso 2 en T3 (sellar actualizaciones rutinarias) y los pasos 3 y 4 en T2 (encolar razones sin clasificar, redactar el análisis); los cambios de taxonomía del paso 5 DEBERÁN permanecer en T1 (el Agente propone, una persona aprueba cada acto). - Entradas / Salidas: Entradas: la taxonomía base, Eventos de actualización de MIR-2 a MIR-9, Eventos de transición de CON-6, CON-7 y CON-8, Eventos de sustitución de ACT-10 y ACT-11, sellos de verificación de actuación del paso 6 de ACT-8 y el paso 5 de ACT-9, Eventos de reapertura de tarea de CTX-5. Salidas: Eventos con código de razón, una cola de sin clasificar, versiones de la taxonomía, análisis periódico de distribución de razones. - Pasos: 1. Adoptar la taxonomía base como conjunto de datos maestrado en el modelo. Códigos base: scheduled-refresh; source-event; use-driven; actuation-verification (una ingesta que sirve a una recolección forzada de ACT-8 o a una verificación independiente de ACT-9; sellada por el paso 6 de ACT-8 y el paso 5 de ACT-9); human-report; correction (se halló y arregló un error en el modelo); drift-resolution; structural-change (cambió la maestría, el nivel de servicio o el alcance); quarantine o release; supersession-archival; migration-backfill (ejecutado vía CON-12); insufficient-context (sellado en los Eventos de reapertura de tarea, la fuente computable de la métrica de retrabajo de CTX-5). 2. Todo Evento de actualización emitido de MIR-2 a MIR-9, todo Evento de transición de CON-6, CON-7 y CON-8, y todo Evento de sustitución de ACT-10 y ACT-11 DEBERÁ llevar exactamente un código de razón primario; PUEDEN añadirse códigos secundarios. Un Evento compuesto emitido por el carril rápido editorial (según COMMON) lleva su código de razón una vez y es evidencia conforme de sellado. 3. Compuerta: ¿ningún código encaja? Sellar unclassified con texto libre y encolar el caso para revisión de la taxonomía; la cola de sin clasificar tiene un límite de edad. 4. Según calendario, analizar la distribución de razones por conjunto de datos: una tasa alta de correction señala un problema de calidad de la fuente o de la transformación; cero actualizaciones use-driven señalan datos muertos; un pico de drift-resolution señala una proyección que gotea; un pico de actuation-verification señala un bucle de actuación inestable. 5. Evolucionar la taxonomía como cambio versionado y aprobado por el Custodio, siguiendo el patrón genérico de recertificación de registros de COMMON para la revisión programada. Los códigos DEBERÁN quedar obsoletos, jamás borrarse ni redefinirse; los Eventos históricos conservan su significado original. - Controles: Código de razón obligatorio en todo Evento cubierto (la validación rechaza actualizaciones sin sellar); límite de edad de la cola de sin clasificar; regla de obsoletar y no redefinir; los hallazgos del análisis se publican al Custodio. - Nivel: recomendado - Variantes: Solo: los doce códigos base, sin tocar, más una mirada anual a la distribución. Equipo: informes de distribución por paquete que alimentan las retrospectivas. Federada: los códigos de razón viajan con los Eventos de sincronización para que los pares puedan distinguir una corrección de un refresco rutinario al decidir cómo reaccionar. Manual: la razón se escribe en el mensaje de commit siguiendo una convención. Híbrida: el Agente sella, el Custodio revisa la cola de sin clasificar (lo típico). Autónoma: sellado en T3 con alertas de anomalía en la distribución. - Métricas: Porcentaje de Eventos cubiertos que llevan código de razón (objetivo 100); tasa de sin clasificar; cumplimiento de la cadencia de revisión de la taxonomía; tendencia de la tasa de correction por conjunto de datos. - Modos de fallo: Todo sellado con un único código por defecto, destruyendo la señal (guarda: comprobación de distribución del Auditor con un piso de entropía). Explosión de la taxonomía en decenas de casi duplicados (guarda: puerta T1 del Custodio y deduplicación en la revisión). Códigos reinterpretados calladamente con el tiempo (guarda: regla de obsoletar y no redefinir). Razones registradas pero nunca leídas (guarda: análisis programado del paso 4 con hallazgos publicados). Las correcciones hechas por la cadena CON quedan invisibles al análisis de distribución (guarda: la regla de sellado extendida del paso 2). ### MIR-11 Retirada del modelo y sucesión - Propósito: Terminar un modelo o Dimensión de forma lícita: un desmantelamiento orquestado que no deja espejos zombi en Universos pares, ni credenciales o concesiones vivas, ni trabajos permanentes alarmando contra un modelo muerto, y que preserva la historia completa del modelo con una lápida duradera y punteros al sucesor. La retirada es un acto de ciclo de vida, jamás un borrado. - Disparador: Una decisión del Propietario de retirar el modelo, registrada como Evento de decisión de GOV-1; sucesión o fusión en un modelo sucesor; un hallazgo sostenido de inviabilidad desde la dotación de recursos de GOV-5 aceptado por el Propietario. - Actores: Propietario (ordena la retirada; el consentimiento no es delegable en sustancia); Custodio (ejecuta el manual de desmantelamiento); Agente; Auditor (contratado vía GOV-6; certifica el cierre); socios de federación y Consumidores (notificados). Un Agente PUEDE ejecutar el desmontaje mecánico de los pasos 2 a 5 y la mecánica de archivo del paso 7 en T2; los pasos 1, 6, 8 y 9 implican la decisión del Propietario, la declaración de conformidad de cierre y la certificación, y DEBERÁN permanecer en T1 (el Agente propone, una persona aprueba cada acto), con la decisión del Propietario y la certificación del Auditor no delegables. - Entradas / Salidas: Entradas: la decisión de retirada de GOV-1, el registro de federaciones (FED), los registros de concesiones (GOV-7, FED-3), la lista de Contratos de delegación (CTX-9), el registro de trabajos permanentes de QSC-15, el registro de consumidores CON-13, la política de retención de GOV-2, el inventario de credenciales de GOV-8. Salidas: Eventos de terminación secuenciados, informe final de validación QSC-4 e instantánea de conformidad QSC-10, archivo terminal de MIR-9 con custodia declarada, lápida publicada con punteros al sucesor, certificación de cierre del Auditor, el Evento terminal. - Pasos: 1. Registrar la decisión de retirada del Propietario como Evento de decisión de GOV-1 y congelar la nueva admisión: sin nuevas entradas de registro (MIR-1), sin nuevas concesiones (GOV-7, FED-3), sin nuevos Contratos de delegación (CTX-9), sin nuevas federaciones. 2. Notificar a todos los Consumidores registrados, resueltos contra CON-13, con el calendario de retirada y los punteros al sucesor; seguir la notificación hasta su compleción. 3. Secuenciar FED-11 por socio de federación: terminar o traspasar cada federación bajo su contrato, recogiendo los acuses de los socios para que ningún par retenga un espejo vivo sin marcar. 4. Revocar todos los Contratos de delegación vía CTX-9 y barrer las concesiones de GOV-7 y FED-3 hasta cero concesiones vivas dentro del TTL de revocación declarado; ejecutar la sonda del lado de la puerta que verifica que no quedan derechos huérfanos. 5. Desmontar trabajos permanentes, planificadores y monitores vía QSC-15 hasta que el registro de trabajos de este modelo quede vacío; retirar credenciales y claves vía GOV-8. 6. Ejecutar la validación final QSC-4 y emitir la instantánea final de conformidad QSC-10 como declaración de cierre del modelo. 7. Ejecutar el archivo terminal vía MIR-9: modelo completo, historia de Eventos, registros y evidencia, bajo la política de retención de GOV-2, con custodia declarada y copias fuera de sede de QSC-13. 8. Publicar la lápida: un registro mínimo y duradero que nombre el modelo, su vida, su Evento terminal, la custodia de su archivo y sus punteros al sucesor, con redirecciones para las referencias entrantes donde sea factible. 9. El Auditor certifica el cierre: cero credenciales vivas, cero concesiones vivas, cero trabajos en marcha, completitud de la notificación contra CON-13, archivo reconstruible; la certificación se registra como el Evento terminal. - Controles: La retirada NO DEBERÁ proceder sin la decisión registrada del Propietario (no delegable). La secuencia es obligatoria: congelar, luego notificar, luego federaciones, luego concesiones y contratos, luego trabajos y credenciales, luego instantánea, luego archivo, luego lápida, luego certificación. Ningún borrado físico durante la retirada más allá de lo que la política de retención de GOV-2 permita con aprobación del Propietario. El Auditor que certifica NO DEBERÁ haber ejecutado el manual. La lápida y la custodia del archivo sobreviven al modelo. - Nivel: nuclear - Variantes: Solo: el manual se encoge a concesiones, trabajos, archivo y lápida; un Auditor par externo (contratado vía GOV-6) certifica el cierre. Equipo: manual dirigido por el Custodio con listas de desmontaje por familia. Federada: la secuenciación de FED-11 domina el calendario; los pares retienen proyecciones históricas según la regla federada de MIR-9, marcadas como originadas en un modelo retirado. Manual: una lista impresa recorrida una vez, cada marca un Evento. Híbrida: el Agente ejecuta el desmontaje en T2, las personas guardan la decisión y la certificación (lo típico). Autónoma: no aplicable; la decisión y la certificación jamás son autónomas. Ejemplo MOS (Dimensión de referencia externa, orkestron-ai/meta-orchestrator-state): retirar una Dimensión sin dejar varados los contratos de sus agentes ciudadanos ni las referencias históricas de sus pares. - Métricas: Credenciales, concesiones y trabajos vivos residuales en la certificación (objetivo cero); completitud de la notificación a consumidores contra CON-13 (objetivo 100); tiempo desde la decisión hasta la certificación; tasa de resolución de los punteros al sucesor tras la retirada. - Modos de fallo: Persisten espejos zombi en Universos pares (guarda: secuenciación de FED-11 por socio con recogida de acuses). Sobreviven credenciales vivas al desmontaje (guarda: barrido de retirada de GOV-8 más la comprobación de cero residuos del Auditor). Trabajos permanentes alarman para siempre contra un modelo muerto (guarda: registro de QSC-15 vaciado y verificado en el paso 5). Historia perdida en las prisas por cerrar (guarda: archivo terminal de MIR-9 con copias de QSC-13, con puerta previa al Evento terminal). La retirada se atasca a medio hacer, dejando un modelo ni vivo ni cerrado (guarda: manual secuenciado con Eventos por paso y la certificación del Auditor como único estado final lícito).