# CON: contribución y control de entrada Esta familia gobierna cómo entra la información en un meta-modelo conforme a Vercy y cómo se controla esa entrada. Su doctrina se sigue de tres invariantes del canon: todo fichero tiene un significado declarado (ARCH-017), todo conjunto de datos tiene exactamente un maestro (ARCH-018), y todo cambio es un suceso explícito y trazable (Lifecycle, Change Process). De ahí la familia deriva sus cuatro leyes: 1. **Ninguna puerta lateral para el contenido de autoría.** Nada escrito pasa a formar parte del modelo si no es por el camino de entrada declarado (CON-1). Un commit que se saltó la recepción es un defecto que el recorredor de cobertura debe sacar a la luz. El contenido recolectado es distinto por diseño: la ejecución de una canalización MIR-2 registrada bajo una entrada activa de `sources.yaml` ES la recepción y la aprobación del contenido recolectado; la entrada de registro es la autorización permanente; CON-2 a CON-4 no vuelven a procesar los lotes de recolección. 2. **Ningún hecho anónimo.** Toda entrada lleva su procedencia: quién la afirmó, cuándo, desde qué fuente, bajo qué autoridad y por qué (CON-2). Una entrada sin procedencia no es admisible. Para el contenido recolectado, la procedencia de registro es la ficha lateral de MIR-2; CON-2 la referencia y jamás la reescribe. 3. **Escribe solo donde vive la verdad.** Las ediciones aterrizan únicamente en el Sistema de registro de cada conjunto de datos. Los intentos de editar espejos, capturas crudas o artefactos generados se rechazan y se encaminan al maestro (CON-5). Un conjunto de datos ausente del registro y sin sistema externo implicado es maestrado por el modelo y se escribe en su sitio, según el valor por defecto de Data-Mastership 6. 4. **Las personas siguen siendo responsables, los agentes ejecutan.** Los Custodios delegan mucho: la mayoría de los pasos de esta familia corren en T2 o T3 bajo Contratos de delegación (niveles según el preámbulo de la paleta), pero la aprobación de entradas rompedoras o disputadas, la aceptación de conjuntos críticos para la seguridad y la concesión de derechos de entrada siguen siendo actos humanos, y las resoluciones de CON-9 no se delegan en sustancia. La responsabilidad nunca se transfiere al Agente. El ciclo de vida del Contrato de delegación es de CTX-9; CON solo lleva el registro de derechos de entrada que lo referencia. Dos instrumentos entre familias moldean la ejecución de esta familia. La clase de conjuntos de datos crítica para la seguridad (definida en COMMON) es estructuralmente inelegible para las vías de auto-aprobación: la compuerta de CON-4 impone esa inelegibilidad de forma mecánica, la aceptación es siempre T1 con un segundo revisor humano, y el clasificador de vías basado en diferencias que decide la elegibilidad es un artefacto de GOV-2 que nunca se fía de la clasificación que propone el propio agente que envía. La vía rápida editorial (definida en COMMON) va en sentido contrario: para cambios editoriales o correctivos por debajo del umbral de tamaño declarado, una canalización de agente en T3 emite un único Suceso compuesto que es evidencia conforme para CON-1, CON-2, CON-3, CON-4 y CON-6. Vocabulario (según el glosario COMMON): cuarentena es la marca de confianza legible-pero-señalada de MIR-8 (y también el estado de frescura de MIR-6); cuarentena de admisión es la retención entrante de FED-8, ilegible hasta su promoción; retención por integridad es el marcador de exclusión de QSC-9. La retención de recepción de CON no es ninguna de ellas: es un estado de aparcamiento previo a la admisión para envíos que aún no han pasado las puertas de identidad o de procedencia. La familia escala desde un Propietario-Custodio en solitario con un modelo del tamaño de un cuaderno (donde recepción, revisión y aprobación se colapsan en una sola persona más un agente portero en T3, y el perfil de conformidad Solo/Mínimo de COMMON consolida las revisiones periódicas) hasta el caso de esfuerzo MOS: un Universo a escala de Estado donde miles de agentes ciudadanos de IA contribuyen sin parar, las importaciones masivas cargan corpus enteros de modelos del mundo, y las disputas sobre entradas son rutina (MOS remite al repositorio externo de la Dimensión de referencia, orkestron-ai/meta-orchestrator-state, no al estándar). La paleta soporta esa escala porque las puertas de validación (CON-3), las vías de auto-aprobación (CON-4) y la imposición de la maestría (CON-5) son enteramente mecánicas, mientras la atención humana queda reservada a ejecutar la matriz de aprobación de GOV-2, las disputas y las concesiones de derechos. Los modelos en producción de Orkestron (el modelo de producto de Orkestron.AI, el modelo de la plataforma DevTeam.Games) sirven de implementaciones de referencia de los patrones de maestría y de captura de deriva. Procesos nucleares (ningún modelo conforme opera sin ellos): CON-1, CON-2, CON-3, CON-4, CON-5, CON-6, CON-8, CON-10, CON-11. Recomendados: CON-7, CON-9, CON-12, CON-13. ## Interfaces con otras familias - **GOV:** GOV-1 registra las resoluciones y apelaciones del Propietario que CON-9 escala y las decisiones de adopción de migración que disparan CON-12. GOV-2 redacta y versiona la matriz de aprobación, los criterios de vía de auto-aprobación, el clasificador de vías basado en diferencias, las configuraciones de puerta y el TTL de propagación de revocaciones; CON-3, CON-4 y CON-10 ejecutan esos artefactos y jamás los redactan. GOV-3 nombra a los Custodios y suplentes que la matriz de CON-4 nombra. GOV-5 recibe de CON-13 los informes de carga de consumidores y dependencias. GOV-6 contrata al Auditor que muestrea las aprobaciones de CON-4, las importaciones de CON-7 y las migraciones de CON-12. GOV-7 emite las concesiones de acceso internas que CON-13 refleja en entradas de consumo. GOV-8 suministra las credenciales del acceso a canales que CON-10 provisiona. - **MIR:** MIR-1 es el ejecutor único de los cambios del Registro de maestría: el paso 1 de CON-7 lo invoca (con su puerta del Propietario para sistemas externos nuevos) antes de que se mueva un byte, el paso 4 de CON-9 le escala las disputas de maestría, y las actualizaciones de registro de CON-5 y CON-6 se ejecutan por él. MIR-2 es recepción y aprobación del contenido recolectado bajo una entrada activa de `sources.yaml` y el dueño único de la ficha de procedencia de recolección que CON-2 referencia; los aterrizajes crudos de CON-7 siguen la disciplina de MIR-2. MIR-7, motor único de detección de deriva, emite los Sucesos de deriva que disparan CON-11, y el paso 7 de CON-6 dispara su camino de republicación y comprobación. Las notificaciones de cuarentena de MIR-8 resuelven destinatarios contra CON-13. MIR-9 persiste los estados superados para CON-6 y CON-8 y las instantáneas previas a la migración para CON-12. MIR-10 aporta la taxonomía base de motivos que se estampa en los Sucesos de transición de CON-6, CON-7 y CON-8. - **ACT:** Las adiciones de Sucesos de decisión, orden e intención de ACT son canales CON-1 registrados que se ejecutan por la cadena CON, con la vía mecánica de auto-aprobación declarada en CON-4 para las adiciones mecánicas de sucesos. Los avisos de sustitución de ACT-10 resuelven sus destinatarios contra CON-13; ACT-10 encamina los cambios de registro a MIR-1 y los de catálogo o efector a ACT-1 y ACT-3, mientras que sus Sucesos de sustitución llevan códigos de motivo de MIR-10 igual que los propios de CON. - **CTX:** Los conjuntos de escritura de vuelta de CTX-5 son un canal CON-1 registrado; CTX-7 es el paso de integración de concurrencia que alimenta CON-4, no una autoridad de aprobación paralela. CTX-9 es el único Sistema de registro del ciclo de vida del Contrato de delegación: CON-10 obtiene contratos por referencia, los derechos de entrada mueren con su contrato, y los Sucesos de suspensión y revocación de CTX-9 se propagan al registro de derechos de entrada de CON-10 y al desmontaje de canales dentro del TTL de GOV-2, verificados por una sonda del lado de la puerta. Los paquetes de CTX-1 consumen los metadatos de procedencia de CON-2 y los perfiles de consumidor de CON-13. - **FED:** Las propuestas de Universos socios entran en CON-1 bajo su Contrato de federación, y sus cargas llegan a CON solo tras la cuarentena de admisión de FED-8 y su promoción. Los avisos de retirada de CON-8 se propagan bajo los términos de divulgación del Contrato de federación, y FED-11 lee CON-13 para los consumidores del lado del socio de los espejos congelados. Las disputas que cruzan fronteras de soberanía salen de CON-9 hacia FED-9. La notificación a pares de CON-12 usa las correspondencias entre versiones de FED-7 a través de la ventana de compatibilidad declarada. - **QSC:** CON emite la materia prima sobre la que corren las auditorías: informes de validación (CON-3), Sucesos de aprobación con razón (CON-4), estadísticas de completitud de procedencia (CON-2), hallazgos de escape y discrepancia de auto-aprobación, y la historia de cambios de solo adición (CON-6), consumidos por QSC-5 y QSC-9. QSC-9 verifica que MIR-7 y las puertas de CON corrieron con su cadencia y ancla de continuo los hashes de la clase crítica para la seguridad que CON-4 protege. QSC-11 recibe los hallazgos de escape de vía y los informes de dependencia de CON-13 como recepción de deuda. QSC-14 recibe de CON-10 los incidentes de incumplimiento de TTL y autoridad residual, y los incidentes operativos escalados desde trabajos permanentes de CON que han muerto. QSC-15 ejecuta y meta-vigila los trabajos permanentes de CON: el barrido de recomputación completa del índice de enlaces de CON-3, los calendarios de recertificación de CON-10 y CON-13, y la salud de la automatización de puertas. - **La estructura y la autoría del manifiesto son territorio de CON:** las reglas de tipo del manifiesto, las listas de exclusión y las declaraciones de disposición son contenido maestrado por el modelo, escrito por la cadena CON, ejecutado como ley por las puertas de CON-3 y mantenido mediante los cambios estructurales de CON-6; el recorredor de cobertura es la invariante de fusión de CON-6, y los informes de recorrido frescos viajan con todo cambio estructural. ### CON-1 Recepción de contribuciones - Propósito: Recibir y registrar toda entrada de autoría propuesta al modelo, venga de una persona o de un agente, sea un registro estructurado o material crudo, y encaminarla por el camino de entrada correcto. La recepción es la única puerta principal de las contribuciones de autoría: el contenido escrito que no pasó por ella NO DEBERÁ pasar a formar parte del modelo. El contenido recolectado no pasa por aquí: la ejecución de una canalización MIR-2 registrada bajo una entrada activa de `sources.yaml` ES la recepción y la aprobación del contenido recolectado; la entrada de registro es la autorización permanente; CON-2 a CON-4 no reprocesan lotes de recolección. - Disparador: Un Contribuyente envía contenido por cualquier canal aceptado (propuesta de cambio, pull request, mensaje, formulario, propuesta de agente); CON-11 reenvía una propuesta patrocinada que empaqueta una edición externa intencionada; llega por su canal registrado la adición de un Suceso de decisión, orden o intención de ACT; llega por su canal registrado un conjunto de escritura de vuelta de CTX-5; llega una propuesta de un Universo socio bajo su Contrato de federación (tras la cuarentena de admisión de FED-8 y su promoción). - Actores: El Contribuyente envía. El Custodio es dueño de la cola de recepción y de su política de encaminamiento. El Agente PUEDE clasificar y encaminar envíos en T2 y PUEDE registrarlos y acusarlos en T3; un Agente NO DEBERÁ descartar un envío en silencio en ningún nivel. - Entradas / Salidas: Entradas: el envío, el manifiesto del repositorio y sus reglas de tipo (ARCH-017), el Registro de maestría (`sources.yaml`), el registro de derechos de entrada de CON-10. Salidas: una contribución registrada con un identificador de recepción estable, un Suceso de recepción, una decisión de encaminamiento (camino estructurado, camino crudo, encaminamiento a maestro externo o rechazo) y, cada vez que una decisión de encaminamiento cambie después, un Suceso de reencaminamiento obligatorio que referencia el identificador de recepción. - Pasos: 1. Recibir el envío y asignarle un identificador de recepción (Suceso: contribución recibida). 2. Identificar al Contribuyente y comprobar sus derechos de entrada contra el registro de CON-10; la puerta valida la vigencia del Contrato de delegación citado en el momento del acto (regla de revocación de COMMON), sin fiarse jamás de que el agente se detenga solo. Para las propuestas patrocinadas de CON-11, la comprobación de derechos se resuelve contra el Contrato de delegación del Agente que empaqueta; el editor externo aparece solo en la procedencia. Compuerta: ¿derechos válidos para este conjunto de datos y este tipo? Si no, rechazar con motivo o encaminar a la incorporación de CON-10; las identidades desconocidas van a la retención de recepción, jamás a la fusión. 3. Compuerta: ¿estructurado o crudo? Los registros estructurados siguen el camino de registro; el material crudo de autoría (documentos, transcripciones, capturas enviadas) aterriza bajo `raw///` sin tocar, con una ficha de procedencia vía CON-2. 4. Resolver el conjunto de datos destino en `sources.yaml`. Compuerta: ¿es el modelo el maestro? Si el conjunto es maestrado externamente, pasar a CON-5 para su encaminamiento al sistema maestro. 5. Invocar CON-2 para capturar la procedencia completa del envío. 6. Encolar la contribución para las puertas de validación de CON-3 y acusar recibo al Contribuyente. Todo cambio posterior de la decisión de encaminamiento DEBERÁ registrarse como un Suceso de reencaminamiento que referencie el identificador de recepción. - Controles: Comprobación de identidad y de derechos de entrada antes de aceptar contenido alguno, con la vigencia del contrato validada en la puerta en el momento del acto; búsqueda obligatoria del conjunto de datos antes de encaminar; el material crudo NUNCA se edita durante la recepción; los envíos de actores no registrados DEBERÁN quedar en la retención de recepción, no fusionarse; la frase de exclusividad de la recolección del Propósito es normativa; las adiciones mecánicas de Sucesos de ACT y CTX viajan por la vía mecánica de auto-aprobación declarada en CON-4, sujetas al clasificador de vías de GOV-2; el Suceso compuesto de la vía rápida editorial de COMMON es evidencia conforme para esta ficha. - Nivel: nuclear - Variantes: Solo: el Propietario-Custodio es el único Contribuyente humano y la recepción degenera en un Agente portero (T3) que registra las propias ediciones del Custodio; la mayoría de cambios editoriales viajan por la vía rápida editorial de COMMON. Equipo: una cola compartida con encaminamiento por conjunto de datos. Federado: las propuestas que llegan de Universos socios entran por la misma puerta pero se comprueban además contra el Contrato de federación que rige, y sus cargas llegan a CON-1 solo tras la cuarentena de admisión de FED-8 y su promoción. La ejecución manual es una lista de comprobación; la híbrida usa un Agente para clasificar con decisiones humanas de encaminamiento; la autónoma corre toda la recepción en T3 con revisión por muestreo. - Métricas: Tiempo mediano de recepción a decisión de encaminamiento; porcentaje de envíos auto-encaminados correctamente, calculado a partir de los Sucesos de reencaminamiento; tasa de rechazo en recepción; recuento de fusiones detectadas que se saltaron la recepción (objetivo cero). - Modos de fallo: Commits directos que se saltan la recepción (guardia: recorredor de cobertura más protección de rama del repositorio; todo fichero huérfano dispara una auditoría de recepción). Lotes de recolección reprocesados por error a través de CON-1, atascando refrescos programados en una cola de revisión (guardia: la frase de exclusividad de la recolección; la entrada de registro es la autorización permanente). Material crudo mal clasificado como registro estructurado y pulido a mano (guardia: la clasificación de origen del paso 3 es mecánica, por canal y ubicación). Contenido de un contribuyente desconocido fusionado por urgencia (guardia: retención de recepción, sin fusión sin comprobación de derechos). ### CON-2 Captura de la procedencia - Propósito: Atar toda entrada a su procedencia completa: quién la afirmó, cuándo, desde qué fuente, bajo qué autoridad y por qué. La procedencia es lo que permite que la maquinaria de confianza aguas abajo (validación V3-02, el Grafo de procedencia, la confianza en federación) funcione siquiera. - Disparador: Toda contribución aceptada por CON-1; toda ejecución de generación que produce artefactos; toda corrección o retirada en CON-8. Las ejecuciones de recolección quedan excluidas: MIR-2 es el dueño único de la ficha de procedencia de recolección, y CON-2 referencia esa ficha como procedencia de registro del contenido de origen recolectado. - Actores: El Contribuyente aporta la razón. El Custodio define el esquema de procedencia del modelo. El Agente DEBERÁ ejecutar la captura mecánica en T3: un agente que no pueda completar la procedencia DEBERÁ aparcar la entrada, no fusionarla. - Entradas / Salidas: Entradas: la contribución, la identidad del actor, los metadatos del canal, para los agentes el identificador del Contrato de delegación, y para el contenido de origen recolectado la referencia a la ficha de MIR-2. Salidas: un registro de procedencia completo (para conjuntos crudos de autoría, una ficha `_provenance.yaml`: fuente, alcance, hora de captura, herramienta, número de registros; para contenido recolectado, una referencia a la ficha de MIR-2), aristas `assertedBy` y `derivedFrom` para el Grafo de procedencia, y una marca de procedencia completa en la entrada. - Pasos: 1. Determinar el actor que afirma: identidad humana, o identidad del agente más el Contrato de delegación bajo el que actúa. Para las propuestas patrocinadas, el actor que afirma es el Agente que empaqueta bajo su contrato; el editor externo se registra como fuente de la afirmación vía `derivedFrom`, jamás como el remitente titular de derechos. 2. Registrar la marca de tiempo y el canal de entrada. 3. Clasificar el origen: de autoría, recolectado o generado (ARCH-017, sección 9). Compuerta: ¿es determinable el origen? Si no, retener la entrada y escalar al Custodio. 4. Para contenido de origen recolectado, la procedencia de registro es la ficha de MIR-2 con su atestación de hora de captura (emitida por la infraestructura de canalización en la que el Agente recolector no puede escribir, según COMMON); CON-2 enlaza con ella y NO DEBERÁ reescribirla. Para contenido generado, registrar el generador y sus entradas. Para envíos crudos de autoría, escribir la ficha en la recepción. 5. Capturar del Contribuyente la razón (por qué existe esta entrada). 6. Emitir las aristas `assertedBy` y, cuando se conozcan las entradas, `derivedFrom` como parte del Suceso de recepción. 7. Compuerta: ¿procedencia completa según el esquema del modelo? Si no, devolver al Contribuyente; si sí, marcar procedencia completa y liberar a CON-3. ### CON-3 Puertas de validación - Propósito: Aplicar comprobaciones mecánicas de admisión a toda contribución antes de que pueda llegar a revisión: sintaxis, estructura y clasificación de tipo, conformidad de esquema, nombres y estilo, e integridad de enlaces. Las puertas hacen de la calidad una propiedad de la canalización, no de la vigilancia de quien revisa. - Disparador: Una contribución liberada por CON-2; una comprobación previa a la fusión sobre cualquier conjunto de cambios; una revalidación programada de todo el modelo. - Actores: El Agente DEBERÁ ejecutar las puertas en T3. GOV-2 redacta y versiona la configuración de puertas; CON-3 la ejecuta. El Contribuyente arregla los fallos reportados. El Auditor PUEDE revisar la cobertura de las puertas. - Entradas / Salidas: Entradas: la contribución, los esquemas, las reglas de tipo del manifiesto y su lista de exclusión, las convenciones de nombres, las reglas de estilo del modelo y el índice de enlaces de todo el modelo. Salidas: un informe de validación explicable (identificadores de comprobación, pasa o falla, motivo), un veredicto de paso o fallo, y para los cambios estructurales un informe fresco de recorrido de cobertura. - Pasos: 1. Ejecutar la validación de sintaxis (V0): todo artefacto se analiza. 2. Ejecutar la validación estructural (V1): el fichero queda clasificado por exactamente una regla de tipo o enumeración de capa; ningún huérfano, ninguna clasificación ambigua (ARCH-017, sección 7); las ubicaciones declaradas existen. 3. Ejecutar la validación de esquema contra el esquema del tipo declarado y sus campos obligatorios. 4. Ejecutar las comprobaciones de nombres y estilo: nombres canónicos, patrones de identificador, reglas editoriales del modelo. 5. Ejecutar la integridad de enlaces (V2) contra el índice de enlaces de todo el modelo, mantenido de forma incremental: toda referencia interna resuelve, incluidas las referencias entrantes al contenido cambiado; las referencias a maestros externos resuelven a una entrada de registro. Un barrido de recomputación completa programado (un trabajo permanente dado de alta en QSC-15) es el respaldo de integridad que corrige la deriva del índice. 6. Para contribuciones que tocan la base normativa de reglas, ejecutar la comprobación de consistencia de políticas: un cambio que haga insatisfacible el conjunto de reglas NO DEBERÁ pasar. 7. Compuerta: ¿pasan todas las puertas? Si no, devolver el informe explicable al Contribuyente (Suceso: validación fallida). Si sí, encaminar a CON-4 (Suceso: validación superada). - Controles: Toda comprobación tiene un identificador estable y un resultado explicable; la configuración de puertas es un artefacto de política de GOV-2 que CON-3 ejecuta; las definiciones de puerta pertenecen a la clase crítica para la seguridad (COMMON), de modo que sus cambios solo se aceptan en T1 con un segundo revisor humano a través de CON-4, y QSC-9 ancla sus hashes de continuo; no existe camino de fusión que se salte las puertas; las reglas de tipo del manifiesto y las listas de exclusión son contenido maestrado por el modelo escrito por la cadena CON (territorio de CON) y aquí ejecutado como ley. - Nivel: nuclear - Variantes: Solo: un hook local previo al commit más el recorredor de cobertura; el índice de enlaces PUEDE ser la propia salida del recorredor. Equipo: las puertas corren en automatización compartida sobre todo cambio propuesto. Federado: el contenido federado entrante pasa además las comprobaciones de interoperabilidad V4. La ejecución manual (una persona con una lista) es conforme pero DEBERÍA ser temporal; la híbrida y la autónoma corren las puertas en T3. - Métricas: Tasa de éxito de puertas a la primera; tiempo medio del informe de fallo al reenvío; número de defectos hallados aguas abajo que una puerta debió atrapar (defectos escapados, objetivo cero); hallazgos de divergencia índice-contra-barrido por recomputación completa (objetivo cero). - Modos de fallo: Puertas debilitadas para llegar a una fecha (guardia: los cambios de configuración de puertas son clase crítica para la seguridad, T1 más segundo revisor, visibles en la historia). Ficheros huérfanos acumulándose vía la lista de exclusión (guardia: excluir afirma que no hay contenido semántico; el Auditor muestrea exclusiones). El índice de enlaces derivando de la realidad, de modo que las comprobaciones por contribución pasan mientras el modelo se pudre (guardia: el barrido de recomputación completa es el respaldo; las divergencias son hallazgos, y un barrido que deja de correr es una escalada de QSC-15). ### CON-4 Revisión y aprobación - Propósito: Decidir qué entradas necesitan aprobación humana y cuáles se auto-aprueban, ejecutar la cadena de revisión y registrar toda aprobación como un Suceso trazable. Aquí es donde se ejerce la responsabilidad del Custodio. - Disparador: Una contribución supera las puertas de validación de CON-3; CTX-7 entrega un conjunto de cambios integrado tras concurrencia (CTX-7 es el paso de integración de concurrencia que alimenta CON-4, no una autoridad de aprobación paralela); llega una adición mecánica de Suceso desde los canales registrados de ACT o CTX para la vía mecánica declarada. - Actores: El Custodio aprueba dentro de sus secciones; revisores adicionales según exija la matriz de aprobación. El Agente PUEDE pre-revisar en T2 (resumir el cambio, calcular la diferencia, señalar riesgos, proponer una clasificación) y PUEDE auto-aprobar en T3 solo dentro de una vía de auto-aprobación explícitamente declarada cuya elegibilidad confirme el clasificador de GOV-2. La aprobación de cambios rompedores DEBERÁ ser humana; la aceptación de conjuntos críticos para la seguridad DEBERÁ ser T1 con un segundo revisor humano. - Entradas / Salidas: Entradas: la contribución validada, su registro de procedencia, la matriz de aprobación (artefacto de GOV-2 que CON-4 ejecuta), el veredicto del clasificador de vías basado en diferencias (configuración de puerta de GOV-2), la clasificación del cambio. Salidas: un Suceso de aprobación o rechazo con actor y razón, una entrada fusionada entregada a CON-6, o una contribución devuelta. - Pasos: 1. Clasificar el cambio en los dos ejes del Proceso de cambio: impacto (editorial, correctivo, evolutivo, rompedor) y tipo de cambio semántico (estructura del modelo, significado, contrato, comportamiento de proyección, etc.). Un Agente PUEDE proponer la clasificación en T2, pero la clasificación que consume la compuerta de vía NO DEBERÁ proceder del agente que envía ni de su orquestador. 2. Ejecutar el clasificador de vías basado en diferencias (configuración de puerta de GOV-2): fuerza la revisión humana siempre que la diferencia toque palabras clave normativas, esquemas, identidades, entradas de registro, contratos o cualquier conjunto crítico para la seguridad, sea cual sea la clasificación propuesta; las discrepancias entre clasificación y diferencia se registran como hallazgos, no solo como escapes. Compuerta: ¿vía de auto-aprobación? Un cambio califica solo si el clasificador lo permite y se cumplen los criterios declarados de la vía (típicamente: impacto editorial o correctivo, conjunto de bajo riesgo, todas las puertas superadas, contribuyente en buena posición); la clase crítica para la seguridad y las propuestas patrocinadas (de origen externo) son estructuralmente inelegibles. Si es elegible, fusionar en T3 con rastro de auditoría completo (Suceso: auto-aprobado) y saltar al paso 7. 3. Compuerta: ¿toca el cambio la clase de conjuntos crítica para la seguridad (COMMON)? Si sí, la aceptación DEBERÁ ser en T1 con un segundo revisor humano, sea cual sea la clasificación. 4. Asignar revisores según la matriz de aprobación. Compuerta: ¿es el Contribuyente también el único aprobador requerido? Si la matriz prohíbe la auto-aprobación para esta clase, añadir un revisor independiente. 5. Quienes revisan valoran significado, ubicación y consecuencias; el Agente aporta el análisis de impacto (qué referencia esta entrada, qué depende de ella) desde el Grafo de procedencia. 6. Compuerta: ¿aprobar, pedir cambios o rechazar? Las peticiones vuelven al Contribuyente; los rechazos cierran con su razón. 7. Registrar el Suceso de decisión (actor, marca de tiempo, clasificación, razón) y entregar las entradas aprobadas a CON-6. - Controles: La matriz de aprobación, los criterios de vía y el clasificador son artefactos versionados redactados por GOV-2 que CON-4 ejecuta; las entradas rompedoras y las que cambian significado NO DEBERÁN auto-aprobarse; los conjuntos críticos para la seguridad y las propuestas patrocinadas son estructuralmente inelegibles para la auto-aprobación, lo que se impone en la compuerta del paso 2 y no por clasificación; límites de auto-aprobación según la matriz; toda decisión lleva su razón; las vías de auto-aprobación se revisan periódicamente contra su tasa de escape; la vía rápida editorial de COMMON es una vía declarada cuyo clasificador es este mismo mecanismo de GOV-2 y cuyo Suceso compuesto es evidencia conforme para esta ficha. - Nivel: nuclear - Variantes: Solo: el Propietario-Custodio lo aprueba todo; el control práctico es la pre-revisión del Agente en T2 haciendo de segundo par de ojos, más la vía rápida editorial para cambios editoriales; la regla del segundo revisor para conjuntos críticos para la seguridad obliga incluso en solitario (un par externo o el Auditor). Equipo: cadenas multi-revisor guiadas por la matriz. Federado: las entradas que afectan a Proyecciones expuestas o a Contratos de federación requieren además al Custodio de cara a la contraparte. La ejecución autónoma significa vías T3 amplias con revisión humana de muestras y de todo caso señalado, que es la postura normal a escala MOS. - Métricas: Tiempo mediano de revisión; proporción de auto-aprobación y su tasa de escape (entradas auto-aprobadas luego corregidas o retiradas); hallazgos de discrepancia clasificación-diferencia por periodo; carga de revisión por Custodio; porcentaje de decisiones con razón sustantiva. - Modos de fallo: Vía de auto-aprobación ensanchada hasta que la revisión es ficción (guardia: los cambios de criterios de vía son cambios de GOV-2 de clase crítica; un umbral de tasa de escape suspende la vía automáticamente). Auto-licencia vía clasificación propuesta por el agente (guardia: la elegibilidad de vía deriva del clasificador independiente basado en diferencias, jamás del agente que envía). Sellado automático bajo carga (guardia: el Auditor muestrea aprobaciones; se reportan el tiempo de respuesta y la profundidad). Cola huérfana cuando falta un Custodio (guardia: suplente nombrado vía GOV-3 y citado en la matriz; las alertas de envejecimiento escalan por GOV-1). ### CON-5 Imposición de la maestría - Propósito: Garantizar que toda escritura aterriza solo en el Sistema de registro de su conjunto de datos. Las ediciones dirigidas a espejos, capturas crudas o artefactos generados se rechazan y se encaminan al verdadero maestro, según ARCH-018. - Disparador: Cualquier intento de escritura sobre el modelo; CON-1 detectando un destino maestrado externamente; una corrección en CON-8 dirigida a contenido espejado. - Actores: El Agente DEBERÁ imponer en T3: consultar el registro, rechazar escrituras no conformes, empaquetar y encaminar correcciones. El Custodio atiende escaladas, huecos de registro y disputas de maestría. El Contribuyente con acceso al sistema externo lleva allí las correcciones encaminadas. - Entradas / Salidas: Entradas: la petición de escritura, `sources.yaml`, la clasificación de origen del fichero destino. Salidas: una escritura ejecutada en el maestro, o un rechazo con explicación más un paquete de corrección encaminado, más Sucesos de encaminamiento; posiblemente una anotación maestrada por el modelo acerca del espejo. - Pasos: 1. Resolver el conjunto de datos destino en `sources.yaml`. Compuerta: ¿existe entrada de registro? Si no hay entrada y no hay sistema externo implicado, el conjunto es maestrado por el modelo y se escribe en su sitio según el valor por defecto de Data-Mastership 6: seguir por CON-3 y CON-4 y abrir una tarea de completar el registro con MIR-1. Rechazar la escritura y abrir una tarea de hueco de registro solo cuando haya implicación externa o cuando el origen o la maestría sean ambiguos (el deber de negativa de Agent-Operations 6: un agente que no puede decir qué le está permitido editar no debe editar). 2. Compuerta: ¿es el modelo el maestro? Si sí, proceder con la edición en su sitio por la cadena normal (CON-3, CON-4). 3. Si es maestrado externamente: rechazar la edición en su sitio. Empaquetar la corrección (sistema destino, alcance, cambio propuesto, evidencia, procedencia). 4. Entregar la corrección al sistema externo directamente si el Agente tiene allí un camino de escritura lícito; en caso contrario, a un Contribuyente o Custodio que tenga acceso. 5. Opcionalmente registrar una anotación maestrada por el modelo, claramente separada, acerca del espejo ("la fuente dice X, nosotros valoramos Y") si el modelo necesita fijar su posición antes de que la fuente se arregle. 6. Programar o disparar una nueva recolección para que el espejo refleje el maestro corregido; registrar el Suceso de encaminamiento de punta a punta. - Controles: Los espejos, `raw/` y `artifacts/` son de solo lectura dentro del modelo sin excepción; las condiciones de negativa de Agent-Operations 6 obligan a todo Agente; las anotaciones DEBERÁN estar visual y estructuralmente separadas de los hechos espejados; los cambios de maestría son sucesos de registro versionados ejecutados únicamente por MIR-1, jamás ediciones silenciosas; la regla por defecto de registro del paso 1 es el valor por defecto de Data-Mastership 6, no un endurecimiento de la paleta. - Nivel: nuclear - Variantes: Solo: el Propietario-Custodio suele tener acceso a ambos lados, así que encaminar es un recordatorio más una nueva recolección. Equipo: el encaminamiento apunta al equipo dueño del sistema externo. Federado: las correcciones a contenido maestrado por un Universo socio se encaminan por el canal de federación; la federación nunca transfiere maestría. La imposición es autónoma (T3) en todas las variantes; solo los huecos de registro y las disputas de maestría llegan a personas. - Métricas: Número de escrituras no conformes rechazadas (una señal sana, no un recuento de errores); tiempo mediano de la corrección encaminada al espejo recolectado de nuevo; cobertura del registro (conjuntos con implicación externa tocados por escrituras que tienen entrada de registro, objetivo 100 por ciento); incidentes de deriva causados por ediciones a copias (objetivo cero). - Modos de fallo: Una edición cómoda a un espejo rancio "solo por esta vez" (guardia: la negativa en T3 es incondicional; el camino rápido es la anotación del paso 5). Una escritura con implicación externa cayendo en silencio al valor por defecto de maestrado por el modelo porque falta la entrada de registro (guardia: el paso 1 rechaza ante cualquier implicación externa sin entrada; validación de registro V2; el valor por defecto lícito de edición en su sitio se aplica solo cuando no hay sistema externo implicado). Correcciones encaminadas que mueren en la bandeja de alguien (guardia: los Sucesos de encaminamiento tienen estado abierto; las correcciones encaminadas que envejecen avisan al Custodio). ### CON-6 Versionado e historia de cambios - Propósito: Convertir toda entrada aprobada en un cambio versionado y reconstruible: registrar el Suceso de transición, avanzar la línea de versión correcta, mantener ciertos los registros y el recorrido. La historia es de solo adición; el pasado del modelo DEBERÁ ser siempre recuperable. - Disparador: CON-4 aprueba una contribución; una transición de maestría ejecutada por MIR-1; una actualización de registro o de manifiesto. - Actores: El Agente DEBERÁ ejecutar mecánicamente en T3 (aplicar, confirmar, emitir Sucesos, actualizar registros, volver a ejecutar el recorredor); solo escalan los fallos del recorredor y los conflictos de registro. El Custodio fija la política de versionado (qué incrementa una versión de registro frente a una versión de modelo) y revisa la salud de la historia. - Entradas / Salidas: Entradas: la contribución aprobada con todo su rastro de decisión, la política de versionado, los identificadores de versión actuales, la taxonomía base de motivos de MIR-10. Salidas: el cambio aplicado en la ubicación maestra, un Suceso de transición (actor, marca de tiempo, estado previo, estado nuevo, razón, exactamente un código de motivo primario), identificadores de versión actualizados, un registro de cambios actualizado, un informe fresco de recorrido de cobertura donde la estructura cambió, y actualizaciones de registro donde proceda. - Pasos: 1. Aplicar el cambio en la ubicación maestra del conjunto de datos. 2. Registrar el Suceso de transición con actor, marca de tiempo, estados previo y nuevo, y razón, manteniendo distintos los tres tiempos independientes: que un objeto se retire, que una definición cambie de versión y que una proyección sea revocada son tres Sucesos diferentes. Estampar exactamente un código de motivo primario de la taxonomía base de MIR-10 en el Suceso de transición (corrección, cambio estructural, relleno de migración, etc.). 3. Avanzar los identificadores de versión según la política (nivel de registro siempre; versión de paquete o de modelo según las reglas de agregación de la política). La Identidad NO DEBERÁ cambiar jamás: solo un reemplazo semántico crea una Identidad nueva. 4. Actualizar la entrada del registro de cambios que enlaza el Suceso, la Solicitud de cambio o el ID de recepción, y la clasificación de CON-4. 5. Compuerta: ¿el cambio añadió, movió o borró ficheros? Si sí, volver a ejecutar el recorredor de cobertura y confirmar el informe fresco en el mismo cambio; un huérfano bloquea la fusión. 6. Compuerta: ¿el cambio creó un conjunto de datos, alteró una canalización o movió la maestría? Si sí, el cambio de registro DEBERÁ ejecutarse a través de MIR-1 (ejecutor único de los cambios del Registro de maestría) y viajar en el mismo conjunto de cambios (registros antes que memoria). 7. Publicar el estado fusionado; si el conjunto alimenta proyecciones de vuelta, disparar la republicación y la comprobación de deriva vía MIR-7. - Controles: Sin transiciones silenciosas (Lifecycle 6); historia de solo adición, sin reescritura; el recorrido DEBERÁ estar en verde en cada punto de fusión; las actualizaciones de registro viajan en el mismo cambio que describen y se ejecutan por MIR-1; los manifiestos son contenido maestrado por el modelo mantenido aquí como cambios estructurales (territorio de CON); los estados superados persisten según MIR-9; el Suceso compuesto de la vía rápida editorial de COMMON es evidencia conforme para esta ficha. - Nivel: nuclear - Variantes: Solo: el control de versiones más una convención de commits disciplinada satisface la mayoría de los pasos; el Agente impone la disciplina de Sucesos, códigos de motivo y registro que la persona olvidaría. Equipo: automatización compartida en el camino de fusión. Federado: los Sucesos de versión son lo que consume la sincronización de federación, de modo que su completitud es visible desde fuera. La conformidad manual es posible pero frágil; lo normal es híbrido y autónomo. - Métricas: Porcentaje de fusiones con Sucesos de transición completos que llevan un código de motivo primario; estado del recorrido en la fusión (porcentaje en verde, objetivo 100); incidentes de registro rancio (cambios que debieron actualizar `sources.yaml` y no lo hicieron); tasa de éxito en comprobaciones puntuales de reconstrucción de la historia. - Modos de fallo: Costumbres de squash o rebase que destruyen el rastro de Sucesos (guardia: política de solo adición sobre la historia publicada; el Auditor comprueba la reconstruibilidad). Identificadores de versión avanzados sin Sucesos, o Sucesos sin avance de versión (guardia: el agente en T3 hace ambas cosas de forma atómica). Recorredor omitido en movimientos "triviales" (guardia: la automatización de fusión rechaza sin un informe fresco en verde cuando cambiaron rutas). ### CON-7 Importación masiva - Propósito: Ingerir grandes cuerpos de contenido (carga inicial del modelo, migración desde un sistema heredado, incorporación de un conjunto externo grande) bajo control, sin inundar las puertas por entrada ni blanquear datos sin procedencia dentro del modelo. - Disparador: Un Custodio autoriza una importación; se incorpora un sistema externo nuevo; un plan de migración (por ejemplo desde un sistema de registro retirado) llega a ejecución. - Actores: El Custodio autoriza y es dueño de la decisión de aceptación. MIR-1 ejecuta la entrada de registro, incluida su puerta del Propietario para sistemas externos nuevos. El Agente ejecuta en T2 para reimportaciones rutinarias (la persona revisa muestras y excepciones) y DEBERÁ correr en T1 para la primera importación de una fuente nueva (el Agente propone, la persona aprueba cada etapa). El Auditor (contratado vía GOV-6) DEBERÍA muestrear el resultado tras la importación. - Entradas / Salidas: Entradas: el conjunto de datos de origen, la autorización de importación, las reglas de correspondencia y transformación, `sources.yaml`. Salidas: una captura cruda con la ficha de procedencia propiedad de MIR-2, registros transformados en el modelo, un Suceso de importación por lote que referencia un manifiesto de los elementos importados y lleva un código de motivo primario, un informe de muestreo y un punto de reversión. - Pasos: 1. Declarar primero: invocar a MIR-1 para crear o actualizar la entrada de registro del conjunto (maestro, alcance, cadencia, o una entrada de migración de una sola vez), incluida la compuerta de aprobación del Propietario de MIR-1 para sistemas externos nuevos y decisiones de maestría, antes de que se mueva un byte; la importación masiva es un disparador registrado de MIR-1. 2. Ensayar la transformación sobre una muestra. Compuerta: ¿muestra aceptable para el Custodio? Si no, arreglar las reglas de correspondencia y repetir. 3. Aterrizar la captura sin modificar bajo `raw///` según la disciplina de aterrizaje de MIR-2, con la ficha de procedencia propiedad de MIR-2 y su atestación de hora de captura; los hechos NO DEBERÁN mejorarse durante la captura. 4. Transformar a registros candidatos en un área de preparación; el enriquecimiento más allá de la fuente es una capa aparte, maestrada por el modelo, jamás mezclada en la transformación. 5. Ejecutar las puertas de validación de CON-3 sobre todo el lote; triar los fallos (arreglar reglas, apartar registros fallidos o aceptar excepciones documentadas). 6. Revisar por muestreo estadístico según los criterios de aceptación del Custodio (tamaño del lote, riesgo). Compuerta: ¿lote aceptado? Si no, volver al paso 4 o abortar reteniendo la captura cruda como evidencia. 7. Fusionar como un único cambio masivo: un Suceso de importación que referencia el manifiesto de elementos, estampado con exactamente un código de motivo primario de la taxonomía de MIR-10 (relleno de migración para migraciones), un punto de reversión, actualizaciones de registro ejecutadas por MIR-1, recorredor reejecutado. 8. Tras la importación: el Auditor muestrea; el Custodio confirma la cadencia continua de la entrada de registro o cierra la entrada de una sola vez. - Controles: Regla de registro primero (ninguna importación sin entrada declarada, ejecutada por MIR-1 con su puerta del Propietario); la captura cruda es obligatoria e inmutable; procedencia a nivel de lote más enlaces de derivación por registro; fusión única revertible; umbrales de muestreo proporcionales al riesgo del lote. - Nivel: recomendado - Variantes: Solo: las mismas etapas comprimidas en una sesión; la disciplina que sobrevive es registro primero (por MIR-1), crudo primero, una fusión revertible. Equipo: la revisión de preparación se reparte entre el dueño de los datos y el Custodio del modelo. Federado: importar desde un Universo socio usa el canal de federación y sus contratos (cuarentena de admisión de FED-8 y promoción) en lugar de una recolección cruda, pero las etapas de preparación y muestreo son idénticas. Primera ejecución en T1, régimen estable híbrido en T2. - Métricas: Tasa de puertas a la primera del lote; tasa de defectos muestreados tras la importación; tiempo desde la autorización al lote fusionado; invocaciones de reversión (objetivo cero, pero la gracia es que sea posible). - Modos de fallo: Transformación que "arregla" en silencio hechos de la fuente, bifurcando la verdad respecto de la fuente (guardia: comparación con la captura cruda; el enriquecimiento vive en una capa aparte). Importación fusionada como miles de cambios individuales, imposibilitando la reversión (guardia: Suceso y fusión masivos únicos). Basura heredada importada en bloque para limpiarla después (guardia: puerta de muestreo antes de fusionar; carril aparte para los registros fallidos). Una fuente externa nueva incorporada solo con autoridad del Custodio, saltándose la puerta del Propietario (guardia: el paso 1 invoca a MIR-1, cuya compuerta de aprobación del Propietario obliga). ### CON-8 Corrección y retirada - Propósito: Arreglar una entrada equivocada o retirarla del todo, preservando la historia, la identidad y la procedencia. El modelo se corrige a la vista: una entrada retirada se marca, jamás se borra. - Disparador: Un informe de error de un Consumidor, un Auditor o un Contribuyente; una revalidación fallida; una corrección de la fuente aguas arriba que llega por nueva recolección; una resolución de CON-9. - Actores: El Custodio decide las retiradas y las correcciones disputadas; la aprobación de una retirada DEBERÁ permanecer en T1 (el Agente propone, la persona aprueba cada acto). El Agente PUEDE ejecutar correcciones en T2 y PUEDE tratar correcciones mecánicas (enlaces rotos, erratas, formato) en T3 por la vía de auto-aprobación. A los Consumidores se les notifica, no se les consulta. - Entradas / Salidas: Entradas: el informe de error o la resolución, la entrada afectada con su procedencia e historia de versiones, el análisis de impacto del Grafo de procedencia, el registro de consumidores de CON-13. Salidas: una versión nueva corregida o una marca de retirada, un Suceso de corrección o retirada con razón y código de motivo primario, notificaciones a los Consumidores afectados y a los modelos aguas abajo resueltos contra CON-13. - Pasos: 1. Registrar el informe (Suceso: defecto reportado) y enlazarlo con la entrada afectada. 2. Compuerta: ¿es el contenido afectado maestrado por el modelo? Si es un espejo, la corrección se encamina por CON-5 al sistema maestro; el modelo PUEDE añadir una anotación provisional. 3. Ejecutar el análisis de impacto: qué deriva de esta entrada, qué la referencia o qué se divulgó a partir de ella (recorrido del Grafo de procedencia; un Agente lo ejecuta en T3). 4. Compuerta: ¿corrección o retirada? Corrección: escribir el arreglo como versión nueva por CON-3 y CON-4 (los arreglos mecánicos PUEDEN usar la vía de auto-aprobación). Retirada: marcar la entrada como retirada o superada con su motivo, usando el vocabulario canónico de estados (Lifecycle 4-5); identidad, procedencia e historia permanecen intactas y alcanzables. 5. Registrar el Suceso de corrección o retirada con su razón, el enlace al informe que lo originó, y exactamente un código de motivo primario de la taxonomía base de MIR-10 (corrección). 6. Notificar a los Consumidores afectados y a las derivaciones aguas abajo identificadas en el paso 3, resolviendo destinatarios contra el registro de CON-13; cuando la entrada alimentara proyecciones de vuelta o Proyecciones federadas, disparar la republicación o el aviso de federación bajo el Contrato de federación que rija. 7. Cerrar el informe con su resolución. - Controles: El borrado físico de la historia está prohibido, según Lifecycle 13 (la integridad histórica prevalece sobre el borrado físico; las adiciones operativas de la paleta desarrollan esa invariante citada); la corrección misma lleva procedencia; la retirada de entradas que se divulgaron externamente DEBERÁ disparar el paso de notificación; las retiradas requieren aprobación del Custodio, jamás T3; la completitud de la notificación se mide contra CON-13, no contra el folclore. - Nivel: nuclear - Variantes: Solo: un bucle ligero (el informe es una nota, la corrección una edición versionada), pero la marca de retirada y el Suceso siguen siendo obligatorios. Equipo: recepción de informes por el mismo canal que las contribuciones. Federado: los avisos de retirada se propagan bajo los términos de divulgación del Contrato de federación; la nueva recolección del socio cierra el bucle. Lo normal es híbrido: T3 para lo mecánico, T2 para lo sustantivo, persona para las retiradas. - Métricas: Tiempo del informe a la resolución; porcentaje de retiradas con notificación aguas abajo completada contra la lista de destinatarios de CON-13; tasa de recurrencia (el mismo defecto reportado otra vez); proporción de correcciones que pasan las puertas a la primera. - Modos de fallo: Sobrescritura silenciosa del valor equivocado, perdiendo el hecho de que el modelo alguna vez dijo otra cosa (guardia: las correcciones son versiones nuevas con Sucesos; historia de solo adición). Retirada por borrado, rompiendo referencias entrantes y socios de federación (guardia: estado retirado según Lifecycle; las comprobaciones de enlaces V2 atrapan referencias colgantes). Los consumidores aguas abajo nunca se enteran de la corrección (guardia: la notificación es un paso con estado abierto, seguido hasta completarse contra el registro de CON-13). ### CON-9 Resolución de disputas de entrada - Propósito: Resolver el desacuerdo sobre una entrada: si es verdadera, admisible, correctamente ubicada o correctamente maestrada. Las disputas se sacan a la luz y se dirimen, no se entierran en guerras de ediciones. - Disparador: Cualquier rol disputa una entrada; dos contribuciones chocan de forma irreconciliable; un conflicto de encaminamiento de CON-5 donde se disputa la partición o el propio maestro; un olor a maestría por deriva repetida escalado desde CON-11. - Actores: El Custodio dirime dentro de su sección; el Propietario es la instancia de apelación, con las apelaciones registradas en el libro de GOV-1. El Auditor PUEDE ser contratado por independencia (vía GOV-6). El Agente PUEDE compilar el expediente de evidencia en T3 y PUEDE redactar una valoración en T2; la resolución DEBERÁ ser humana y no se delega en sustancia. - Entradas / Salidas: Entradas: el enunciado de la disputa, la entrada en litigio con su procedencia e historia de versiones, capturas crudas y el estado del sistema maestro donde proceda, resoluciones previas. Salidas: un Suceso de resolución con su razón, el resultado aplicado (mantenida, enmendada, retirada o desviación registrada) y, cuando se dispute la maestría, una propuesta de cambio de maestría a MIR-1. - Pasos: 1. Registrar la disputa (Suceso: disputa abierta) nombrando la entrada, quien disputa y la pretensión. 2. Marcar la entrada como Disputada. La marca es visible para los Consumidores; la entrada queda señalada, no oculta ni revertida antes de la resolución. 3. El Agente compila el expediente de evidencia: cadena de procedencia, capturas crudas, estado del sistema maestro, historia de versiones, análisis de impacto (T3). 4. Compuerta: ¿la disputa versa sobre la maestría o la partición (quién es dueño de la verdad) y no sobre el contenido? Si sí, escalar como propuesta de cambio de maestría a MIR-1, ejecutor único de los cambios del Registro de maestría, incluida su compuerta de Custodio y Propietario; CON-6 registra el Suceso de transición resultante como de costumbre. 5. El Agente redacta una valoración con opciones (T2); el Custodio resuelve: mantener la entrada, enmendarla, retirarla o registrar una desviación anotada ("la fuente dice X, nosotros valoramos Y") cuando el modelo y la fuente discrepan lícitamente. 6. Aplicar la resolución por la cadena normal (CON-4 para enmiendas, CON-8 para retiradas) y limpiar o actualizar la marca de Disputada. 7. Registrar el Suceso de resolución con su razón. Compuerta: ¿apela quien disputa? Las apelaciones van al Propietario una vez, registradas como Suceso de decisión de GOV-1; la decisión del Propietario es definitiva dentro del Universo. - Controles: Las entradas disputadas permanecen visibles con su marca; hay límites de tiempo en cada etapa para que las disputas no queden pendientes indefinidamente; quien resuelve NO DEBERÁ ser quien escribió la entrada en litigio cuando el tamaño del equipo lo permita; todas las resoluciones son buscables como precedente; los resultados de maestría se ejecutan solo por MIR-1. - Nivel: recomendado - Variantes: Solo: las disputas llegan de Consumidores o de conflictos entre fuente y modelo; resuelve el Propietario-Custodio, y el resultado de desviación anotada hace la mayor parte del trabajo. Equipo: resuelve el Custodio, el Propietario oye las apelaciones por GOV-1. Federado: las disputas sobre contenido federado se tratan bajo FED-9; este proceso trata solo la entrada local y sus marcas. A escala MOS, las valoraciones redactadas por agentes (T2) y la búsqueda de precedentes hacen manejables miles de disputas de agentes ciudadanos. - Métricas: Tiempo mediano hasta la resolución; proporción de disputas resueltas por anotación de desviación frente a enmienda frente a retirada; tasa de apelación; tasa de disputas reabiertas. - Modos de fallo: Guerra de ediciones en lugar de disputa (guardia: la marca de Disputada congela los cambios de contenido de la entrada salvo por la resolución). Disputas usadas para paralizar hechos incómodos (guardia: límites de tiempo; la entrada sigue visible y utilizable mientras esté Disputada). Resolución sin revisar la evidencia (guardia: el expediente es una entrada obligatoria del Suceso de resolución). Un cambio de maestría ejecutado dentro de la cadena CON, saltándose la validación de un solo maestro de MIR-1 (guardia: el paso 4 encamina exclusivamente a MIR-1). ### CON-10 Incorporación de Contribuyentes y Agentes - Propósito: Conceder derechos de entrada con deliberación: establecer la identidad, acotar los derechos a conjuntos de datos y tipos, atar obligaciones y entregar el briefing de incorporación. El control de entrada empieza por quién puede entrar siquiera. El ciclo de vida del Contrato de delegación (emisión, enmienda, suspensión, revocación, escalera de niveles, periodo de prueba) es de CTX-9, el único Sistema de registro; CON-10 obtiene y referencia contratos, jamás los emite. - Disparador: Una persona o un agente solicita derechos de contribución; un Custodio invita a un Contribuyente; se despliega un Agente nuevo contra el modelo; llega un Suceso de suspensión o revocación de CTX-9 para su propagación; vence la revisión periódica de derechos. - Actores: El Propietario concede derechos o delega la concesión en los Custodios; el Custodio define el alcance y las obligaciones de sus secciones. El Agente PUEDE ejecutar la mecánica de incorporación (comprobaciones, entrega del briefing, actualizaciones de registro) en T2. La concesión misma DEBERÁ permanecer en T1 (el Agente propone, la persona aprueba cada acto). - Entradas / Salidas: Entradas: la identidad del candidato (cuenta humana, o identidad de agente más su operador humano responsable), el alcance solicitado, `sources.yaml`, el BOOTSTRAP y las convenciones del modelo, y para Agentes la referencia al Contrato de delegación de CTX-9. Salidas: una entrada en el registro de derechos de entrada (para Agentes, referenciando el identificador de contrato de CTX-9), un Suceso de concesión, acceso a canales acotado a la concesión, y Sucesos de propagación de revocación con los resultados de su sonda de puerta. - Pasos: 1. Establecer la identidad y, para un Agente, el operador humano responsable detrás. 2. Compuerta: ¿persona o agente? Persona: entregar el briefing (BOOTSTRAP, convenciones, deber de procedencia, reglas de maestría) y obtener acuse. Agente: verificar que puede satisfacer los requisitos nativos de IA (leer el punto de entrada, clasificar ficheros, distinguir qué le está permitido editar), y luego obtener su Contrato de delegación vía CTX-9; los niveles, el periodo de prueba y la escalera de niveles son solo de CTX-9, y CON-10 NO DEBERÁ emitir, enmendar ni llevar un régimen de prueba propio. 3. Definir el alcance con el Custodio: qué conjuntos, qué tipos, qué procesos. El alcance DEBERÁ cubrir solo conjuntos que el modelo maestra; los derechos sobre datos maestrados externamente no son de este modelo para concederlos. 4. Registrar el Suceso de concesión y actualizar el registro de derechos de entrada; para Agentes, el derecho de entrada referencia el identificador de contrato de CTX-9 y solo vale mientras ese contrato esté vivo. Provisionar acceso a canales que case exactamente con el alcance concedido, con credenciales tratadas según GOV-8. 5. Propagar revocaciones: los Sucesos de suspensión y revocación de CTX-9 DEBERÁN alcanzar el registro de derechos de entrada y el desmontaje de canales en ejecución dentro del TTL declarado (una configuración de GOV-2); una sonda del lado de la puerta verifica que no quedan derechos huérfanos pasado el TTL; la autoridad residual pasado el TTL es un incidente abierto en QSC-14. 6. Ejecutar la revisión periódica de derechos vía el patrón de recertificación de registros de COMMON, parametrizado por el registro de derechos de entrada, sus umbrales de antigüedad y uso, y el Custodio que concede como aprobador; las concesiones caducadas o sin uso se retiran con Sucesos. 7. Ante incumplimiento de obligaciones: revocar los derechos de entrada de inmediato (Suceso: derechos revocados), notificar a CTX-9 (la suspensión o revocación del contrato es acto de CTX-9), y revisar de nuevo las entradas recientes del actor. - Controles: Mínimo privilegio por defecto; concesiones, cambios y revocaciones son Sucesos versionados; los derechos de entrada de un Agente mueren con su Contrato de delegación de CTX-9, y toda puerta valida la vigencia del contrato en el momento del acto (regla de revocación de COMMON), sin apoyarse en que el agente se detenga solo; la propagación de la revocación está acotada por TTL con una sonda del lado de la puerta; la responsabilidad permanece en el Custodio que delega en todo momento. - Nivel: nuclear - Variantes: Solo: la auto-concesión del Propietario-Custodio es trivial, pero la incorporación de Agentes no lo es: incluso un modelo en solitario DEBERÁ encaminar sus Agentes portero y recolector por CTX-9 para tener Contratos de delegación reales, o la disciplina de niveles no tiene anclaje; bajo el perfil Solo/Mínimo la revisión trimestral consolidada satisface lícitamente el paso 6. Equipo: concesiones acotadas por el Custodio con supervisión del Propietario. Federado: los Universos socios no se incorporan aquí; su acceso es un Contrato de federación, y cualquier derecho de propuesta local que reciban pasa igualmente por este proceso. Mecánica de incorporación híbrida en T2; la concesión siempre humana. - Métricas: Tiempo de la solicitud a la decisión; porcentaje de quienes escriben activamente con entrada vigente en el registro y, para Agentes, con referencia viva a un contrato de CTX-9 (objetivo 100); tiempo de propagación de la revocación frente al TTL declarado (incumplimientos objetivo cero); revocaciones por periodo y tiempo medio hasta revocar ante incumplimiento. - Modos de fallo: Credenciales compartidas o ambientales que permiten escribir a actores no registrados (guardia: el acceso a canales se provisiona solo desde el registro con credenciales de GOV-8; la recepción rechaza identidades desconocidas). Deriva de alcance del agente más allá de su contrato (guardia: CON-5 y CON-3 comprueban el contrato actuante contra los conjuntos tocados en cada escritura; la vigencia se valida en la puerta). Derechos huérfanos que sobreviven a una revocación de CTX-9 (guardia: propagación acotada por TTL más la sonda del lado de la puerta; la autoridad residual pasado el TTL abre un incidente de QSC-14). Derechos jamás revisados, acumulándose para siempre (guardia: las concesiones caducan; el patrón de recertificación corre según calendario con una alarma de envejecimiento). ### CON-11 Captura de ediciones externas - Propósito: Recuperar las ediciones intencionadas que la gente hace en las proyecciones de vuelta (copias de patrón M publicadas en wikis, sitios o gestores de incidencias) como propuestas de cambio patrocinadas en regla, en lugar de fusionarlas o perderlas en silencio. Según ARCH-018, las ediciones en una copia proyectada no tienen autoridad, pero a menudo llevan información real. CON-11 es el único camino de captura y clasificación de ediciones externas intencionadas; la detección pertenece exclusivamente a MIR-7, el motor único de detección de deriva de la paleta. - Disparador: Un Suceso de deriva de MIR-7 sobre una proyección de vuelta (CON-11 es el consumidor registrado de esos Sucesos para la clase de escritura de vuelta); una persona externa pide cambiar una página publicada. - Actores: El Agente DEBERÁ clasificar y empaquetar en T3, señalando los casos inciertos. El Custodio decide la propuesta resultante por CON-4 en T1 o T2 según sensibilidad; las propuestas patrocinadas son estructuralmente inelegibles para las vías de auto-aprobación. Al editor externo se le acredita en la procedencia como fuente de la afirmación, jamás como Contribuyente titular de derechos. - Entradas / Salidas: Entradas: el Suceso de deriva de MIR-7 con su diferencia y los metadatos de edición del sistema externo (quién, cuándo), la proyección de vuelta, los registros maestros de los que se generó, `sources.yaml`. Salidas: una clasificación (daño accidental o mejora intencionada), una propuesta de cambio patrocinada que entra en CON-1 con procedencia completa, y una proyección reconciliada (republicada o corregida). - Pasos: 1. Recibir el Suceso de deriva de MIR-7 con la diferencia extraída y los metadatos de la edición externa; CON-11 no ejecuta detección propia. 2. Clasificar la deriva: daño accidental (formato destrozado, borrado parcial) frente a mejora intencionada (alguien arregló un hecho o una redacción en la copia). Un Agente clasifica en T3 y señala los casos inciertos al Custodio. 3. Compuerta: ¿daño accidental? Devolver la disposición a MIR-7: la copia externa se sobrescribe en la siguiente publicación y se notifica al dueño del sistema externo; hecho. 4. Para ediciones intencionadas: empaquetar una propuesta patrocinada hacia la recepción de CON-1. El Contrato de delegación del Agente que empaqueta es el remitente titular de derechos; el editor externo queda registrado en la procedencia como fuente de la afirmación (`derivedFrom` la copia externa, con identidad del editor y hora de edición), jamás como Contribuyente titular de derechos. Los bytes espejados en el modelo no se tocan nunca directamente. 5. La propuesta recorre la cadena normal (CON-2 a CON-4). Las propuestas patrocinadas son estructuralmente inelegibles para las vías de auto-aprobación y DEBERÁN recibir una decisión del Custodio en T1 o T2 según sensibilidad. 6. Compuerta: ¿aceptada? Si sí, fusionar al maestro y republicar la proyección para que copia y maestro converjan en los términos del modelo. Si se rechaza, republicar la proyección sobre la edición externa con un aviso que explique dónde corresponden los cambios. 7. Registrar el ciclo completo como Sucesos (clasificación, propuesta creada, resolución, republicado), cada uno enlazado al Suceso de deriva de MIR-7 que lo originó. 8. Compuerta: ¿deriva intencionada repetida en la misma copia? Eso es un olor a maestría: escalar como disputa a CON-9, que encamina cualquier propuesta de cambio de maestría a MIR-1. - Controles: La fusión silenciosa de ediciones externas está prohibida (Data-Mastership 5.1); la proyección lleva su marca de "no editar aquí" con un puntero al canal de propuestas; CON-11 NO DEBERÁ correr un bucle de detección propio (MIR-7 es el motor único, y QSC-9 verifica que MIR-7 corrió con su cadencia); la salud del trabajo permanente de comprobación de deriva la vigila QSC-15, escalando a QSC-14; las propuestas patrocinadas jamás viajan por una vía de auto-aprobación. - Nivel: nuclear - Variantes: Solo: la comprobación automatizada de MIR-7 más este camino de clasificación hacen que la divergencia la note la maquinaria y no la vergüenza; la mayoría de derivas se resuelve por sobrescritura. Equipo: la escalada del paso 8 mantiene las cuestiones de maestría fuera de las guerras de ediciones. Federado: no se aplica a las Proyecciones federadas (esas las gobiernan la sincronización de federación y FED-6); se aplica solo a copias de vuelta dentro del dominio de gobernanza. Clasificación y empaquetado plenamente autónomos en T3; las decisiones de aceptación según CON-4, siempre humanas para propuestas patrocinadas. - Métricas: Proporción de Sucesos de deriva de escritura de vuelta de MIR-7 clasificados dentro de la ventana declarada; proporción clasificada como ediciones intencionadas; tiempo mediano del Suceso de deriva a la reconciliación; tasa de deriva repetida por copia (un olor a maestría). - Modos de fallo: Ediciones externas intencionadas sobrescritas en silencio, quemando la buena voluntad de quien contribuye y perdiendo correcciones (guardia: el paso de clasificación y el camino de propuesta patrocinada existen justo para esto; la sobrescritura es solo para el daño accidental). Ediciones externas fusionadas en silencio en el modelo, bifurcando la autoridad (guardia: la prohibición de escribir en espejos de CON-5 hace del camino de propuesta el único camino; las propuestas patrocinadas no pueden auto-aprobarse). Personas anónimas adquiriendo derechos de contribuyente por el camino de captura (guardia: el patrón de propuesta patrocinada; el editor externo existe solo en la procedencia). Sucesos de deriva producidos por MIR-7 pero jamás consumidos (guardia: CON-11 es el consumidor registrado para la clase de escritura de vuelta; los Sucesos de deriva sin consumir envejecen hacia una escalada de QSC-15). ### CON-12 Migración de estándares y esquemas - Propósito: Migrar el modelo de una versión del estándar que lo rige o de una generación de esquemas de todo el modelo a la siguiente como un único cambio controlado y revertible, en lugar de congelarse en un estándar muerto o migrar a salto de mata, que es el patrón de edición anónima que esta paleta existe para evitar. - Disparador: Una versión nueva del estándar que rige se adopta por decisión de GOV-1; un cambio de objetivo de conformidad de QSC-10 exige migración; un cambio de generación de esquemas de todo el modelo cruza conjuntos de datos. - Actores: El Custodio planifica y es dueño de la migración. El Propietario aprueba el plan de migración (una Solicitud de cambio rompedora; cuando el plan toca definiciones de puerta o de proceso es de clase crítica para la seguridad, T1 con un segundo revisor humano). El Agente ejecuta la transformación en T2. El Auditor (vía GOV-6) DEBERÍA muestrear tras la migración. - Entradas / Salidas: Entradas: el plan de migración como Solicitud de cambio, las versiones antigua y nueva del estándar y de los esquemas, las reglas de correspondencia, `sources.yaml`, la Declaración de conformidad actual de QSC-10. Salidas: el estado transformado del modelo, el estado crudo previo a la migración retenido según MIR-9, informes duales de validación de QSC-4 (nivel antiguo y nuevo), notificaciones a pares con una ventana de compatibilidad declarada (vía FED-7), un único Suceso de cambio revertible estampado como relleno de migración, y una Declaración de conformidad de QSC-10 actualizada. - Pasos: 1. Escribir el plan de migración como Solicitud de cambio: análisis de impacto de los cambios normativos, conjuntos y esquemas afectados, reglas de correspondencia y transformación, criterios de reversión, y la ventana de compatibilidad para los pares. Aprobar por CON-4 en T1 (clase rompedora). 2. Preservar el estado crudo previo a la migración según MIR-9 antes de cualquier transformación; es evidencia inmutable y el sustrato de la reversión. 3. Ejecutar la transformación en una rama; el modelo vivo no se toca hasta el cambio. 4. Ejecutar QSC-4 por duplicado: validar la rama contra el nivel antiguo y el nuevo del estándar; triar los fallos contra las reglas de correspondencia. 5. Notificar a los pares federados la migración y la ventana de compatibilidad declarada; mantener las correspondencias entre versiones de FED-7 para los pares que sigan en la versión antigua durante la ventana. 6. Compuerta: ¿validación dual en verde y ventana de compatibilidad declarada? Si no, arreglar las reglas de correspondencia y repetir, o abortar reteniendo la rama como evidencia. 7. Hacer el cambio como una única modificación revertible: un Suceso de cambio estampado con el código de motivo relleno de migración, actualizaciones de registro y manifiesto en el mismo conjunto de cambios (los cambios de registro ejecutados por MIR-1), recorredor reejecutado en verde. 8. Actualizar la Declaración de conformidad de QSC-10 a la versión nueva del estándar; el Auditor muestrea tras la migración; revertir según los criterios del plan si la verificación falla. - Controles: Ninguna migración parcial improvisada fuera de un plan aprobado; el estado crudo previo a la migración es obligatorio e inmutable; la validación dual es obligatoria antes del cambio; el cambio es un único Suceso revertible; la ventana de compatibilidad DEBERÁ respetarse antes de que termine el soporte de la versión antigua; la redeclaración de conformidad es un paso obligatorio, no algo de después. - Nivel: recomendado - Variantes: Solo: el plan PUEDE ser de una página, pero la rama, la ejecución dual de QSC-4 y el cambio único revertible sobreviven a la compresión. Equipo: la autoría de las correspondencias y el triaje de validación van separados. Federado: la notificación a pares y las correspondencias de FED-7 son obligatorias, y la duración de la ventana la informa el contrato. La transformación corre en T2; la decisión de cambio es humana. - Métricas: Tasa de validación dual a la primera; tiempo de la aprobación del plan al cambio; pares aún en la versión antigua al cierre de la ventana (objetivo cero); invocaciones de reversión; defectos posteriores a la migración trazados a las reglas de correspondencia. - Modos de fallo: Migración ejecutada como muchas ediciones pequeñas sin coordinar (guardia: el plan más el único Suceso de cambio; la ejecución dual de QSC-4 rechaza estados parciales). Pares federados rotos a mitad de ventana (guardia: correspondencias de FED-7 mantenidas durante la ventana declarada). Estado previo a la migración perdido, imposibilitando la reversión (guardia: retención de MIR-9 antes de cualquier transformación, verificada en el paso 2). Afirmación de conformidad rancia tras el cambio (guardia: la actualización de QSC-10 es un paso numerado con Suceso). ### CON-13 Registro de consumidores y suscripciones - Propósito: Mantener el registro maestrado por el modelo de los Consumidores: identidad, conjuntos y proyecciones que consumen, dependencias declaradas, canal de notificación y SLA. Este es el registro contra el que resuelven las notificaciones de MIR-8, CON-8, ACT-10 y FED-11; "Consumidores dependientes conocidos" lo define este registro, no el folclore. - Disparador: Un Consumidor recibe una concesión de acceso (GOV-7 internamente, FED-3 para federación); un Consumidor declara o cambia sus dependencias; una ejecución de notificación pide destinatarios; vence la recertificación periódica. - Actores: El Custodio es dueño del registro. El Agente mantiene entradas en T3 para la sincronización mecánica con los registros de concesiones y en T2 para los cambios de SLA de notificación. Los Consumidores declaran sus propias dependencias. - Entradas / Salidas: Entradas: Sucesos de concesión de GOV-7 y FED-3, declaraciones de dependencia de los Consumidores, `sources.yaml`, el catálogo de proyecciones. Salidas: el registro de consumidores como conjunto de datos maestrado por el modelo, Sucesos de cambio de registro, listas de destinatarios para las ejecuciones de notificación e informes de dependencia. - Pasos: 1. Dar de alta al Consumidor en la primera concesión: identidad, canal de notificación, SLA, y los identificadores de concesión de GOV-7 o FED-3 sobre los que se apoya el consumo. 2. Registrar los conjuntos y proyecciones consumidos y cualquier dependencia declarada; cuando el Consumidor no declare nada, las dependencias se toman por el alcance de la concesión, jamás por conjetura. 3. Sincronizar mecánicamente con los registros de concesiones: una concesión revocada o caducada marca el consumo como terminado; la entrada se conserva por historia, jamás se borra (disciplina de Lifecycle 13). 4. Servir la resolución de destinatarios: los pasos de notificación de MIR-8, CON-8, ACT-10 y FED-11 DEBERÁN resolver sus receptores contra este registro, y la completitud de la notificación se mide contra él; la orientación de paneles de MIR-6 lo lee para las listas de Consumidores dependientes. 5. Recertificar entradas vía el patrón de recertificación de registros de COMMON (registro, umbrales de antigüedad y uso, el Custodio como aprobador); las entradas muertas se cierran con Sucesos. 6. Reportar concentraciones de dependencia y recuentos de consumidores a la planificación de QSC-11 y a las entradas de capacidad de GOV-5. - Controles: El registro es maestrado por el modelo y cambia por la cadena CON normal; ningún paso de notificación DEBERÁ reclamar completitud salvo contra este registro; las entradas se cierran, jamás se borran; la sincronización con los registros de concesiones es mecánica, y una concesión activa sin entrada de registro es un hallazgo. - Nivel: recomendado - Variantes: Solo: el registro PUEDE ser un único fichero, pero sigue siendo la fuente de verdad de las notificaciones; los modelos que publican o federan DEBERÍAN tratar este proceso como si fuera nuclear, ya que sin él la completitud de las notificaciones de CON-8 y FED-11 es inmedible. Equipo: los Consumidores declaran sus dependencias por autoservicio. Federado: la terminación de FED-11 lee este registro para los consumidores del lado del socio de los espejos congelados. Sincronización autónoma en T3; cambios de SLA en T2. - Métricas: Completitud de la notificación (notificados sobre destinatarios registrados, objetivo 100 por ciento); proporción de concesiones activas con entrada de registro (objetivo 100 por ciento); tasa de entradas rancias hallada en la recertificación; descubrimientos de consumidores no registrados por periodo (objetivo cero). - Modos de fallo: Notificaciones enviadas a los consumidores "conocidos" de memoria (guardia: la resolución de destinatarios DEBERÁ leer el registro; la completitud se calcula contra él). El registro derivando de la realidad de las concesiones (guardia: sincronización mecánica más la comparación de recertificación contra GOV-7 y FED-3). Dependencias inferidas en silencio y mal (guardia: declaradas o tomadas por el alcance de la concesión, con el valor por defecto registrado como tal).