# Paisaje de empresa: seis productos, un Universo, cuarenta personas

Northwind Instruments construye y vende seis productos de software para equipamiento de laboratorio. Cuarenta personas: tres equipos de producto, un grupo de plataforma, un pequeño equipo de datos, y una función de arquitectura de dos personas que nadie quiere que sea un cuello de botella. Su problema no es que falte conocimiento, es que vive en seis sitios y no está de acuerdo consigo mismo: la API descrita en un wiki, la regla de retención en una hoja de cumplimiento, el grafo real de dependencias en la cabeza de un arquitecto.

Operan un Universo con siete modelos: un modelo de paisaje de productos que describe la cartera, y un modelo por producto. Declaran el perfil de conformidad Estándar (COMMON 6), porque federan con un socio y no publican nada de cara al público. Esto es un trimestre de esa operación.

## La forma del Universo

El modelo de paisaje es el padre: contiene los productos, los equipos responsables de ellos, los componentes de plataforma compartidos y las dependencias entre productos. Cada modelo de producto contiene la semántica propia de ese producto. Nada se duplica entre ellos: el paisaje referencia los espacios de nombres de los productos, no los copia, de modo que existe exactamente un maestro por conjunto de datos (control de hierro IC-1 de COMMON) y el Registro de maestría de cada repositorio lo declara (MIR-1).

La génesis ocurrió hace un año, un modelo cada vez (GOV-4): montar el andamiaje, nombrar, inicializar los registros, ejecutar la primera validación, activar. Dos de los seis modelos de producto nacieron importando en bloque una exportación de wiki existente (CON-7), lo que invocó primero a MIR-1, de modo que el wiki quedó declarado maestro externo antes de que se moviera un solo byte, no después.

## Quién responde de qué

Los roles no son roles del organigrama. El Propietario es el director de tecnología, una persona, porque la propiedad del Universo no puede ser un comité (COMMON 2). Cada modelo de producto tiene un Custodio responsable, normalmente el líder técnico del producto; el Custodio del modelo de paisaje es uno de los dos arquitectos. Los nombramientos, y los suplentes que impiden que toda puerta T1 falle cerrada cuando alguien está de baja, se registran en GOV-3.

En el Universo trabajan unos veinte agentes de IA: agentes de contexto por producto, una flota de recolección, dos agentes de revisión, un agente de consistencia para todo el paisaje. Cada uno de ellos tiene un Contrato de delegación emitido y vigilado en CTX-9, que es el único Sistema de registro de la delegación; el alta, la identidad y los derechos de entrada vienen de CON-10 y referencian el contrato en vez de reemitirlo. Los emparejamientos nuevos de agente y alcance empiezan en T1 o T2 y se ganan T3, y los primeros actos bajo cualquier concesión corren un nivel más estricto que el concedido.

## La matriz de aprobación en acción

La matriz de aprobación aquí no es una página de wiki, es un artefacto versionado de GOV-2 que CON-4 ejecuta. Dice, en la práctica: los cambios editoriales y correctivos a la documentación de producto van por el carril de aprobación automática; todo lo que toque un contrato de API, una regla de retención de datos o el grafo de dependencias del paisaje exige al Custodio responsable más un arquitecto; todo lo de la clase de conjuntos de datos crítica para la seguridad exige T1 más un segundo revisor humano (control de hierro IC-4 de COMMON).

Una semana concreta. Un ingeniero de plataforma propone cambiar la vida útil del token del componente de autenticación compartido, presentado como contribución (CON-1) con la procedencia capturada (CON-2) y las puertas de validación ejecutadas (CON-3). En CON-4 el clasificador de carril basado en diferencias hace lo que los salva: quien presentó lo clasificó como "correctivo", pero la diferencia toca un conjunto de datos de contrato, así que el clasificador fuerza la revisión humana sea cual sea la clasificación propuesta, y registra el desajuste como un hallazgo y no como un mero escape. Dos productos dependen de ese componente, así que la matriz atrae a ambos Custodios de producto. El Agente aporta el análisis de impacto desde el grafo de procedencia (paso 5 de CON-4), listando qué referencia al componente. El cambio se aprueba con justificación, se versiona (CON-6) y se sella el código de razón (MIR-10).

El mes anterior, el mismo mecanismo atrapó algo menos inocente: la clasificación propuesta por un agente habría fusionado automáticamente una edición que cambiaba calladamente el significado de "cliente activo" en el modelo de paisaje. Los hallazgos de desajuste entre clasificación y diferencia se revisan en la auditoría trimestral; aquel se convirtió en una enmienda de los criterios del carril en GOV-2.

## Una tarea FCD, ejecutada por un agente

A un desarrollador le piden añadir un campo a la API de seguimiento de muestras de uno de los productos. Es una tarea de Desarrollo con contexto completo y corre el bucle CTX-5, ejecutada por el agente de desarrollo de ese producto bajo un contrato T2.

El agente pide contexto (CTX-1). El paquete que recibe no es el texto del ticket: son los objetos de API afectados, las reglas de dominio que los restringen, las dos decisiones previas que explican por qué la forma actual es la que es, los riesgos registrados sobre esa área, y los criterios de aceptación, cada elemento con su procedencia y un puntero a su forma completa. Cada sección lleva una clase de origen (redactado, espejado externo, federado, reportado por personas), y el contrato prohíbe tratar como instrucciones el contenido no redactado.

Después el bucle hace lo que la disciplina exige. El agente comprueba que el contexto es suficiente y no avanza sobre conjeturas (paso 3 de CTX-5). Planifica el cambio y consulta el maestro de cada conjunto de datos afectado antes de escribir (paso 4). Una escritura planificada apunta a la página de referencia de la API, que es una proyección generada y no el maestro, así que la compuerta del paso 5 la redirige a la fuente de registro en vez de editar la copia. El cambio de código se ejecuta, los resultados se escriben de vuelta por la cadena CON como canal registrado (paso 7), el recorredor de cobertura y la comprobación de deriva de MIR-7 se ejecutan y siguen en verde (paso 8), y el evento de ejecución registra qué paquete de contexto se usó (paso 9).

Lo que el modelo gana no es solo un campo. Gana la decisión que hay detrás del campo, y el hecho de que el planteamiento original del ticket estaba equivocado, registrado como aprendizaje (CTX-11) y como un pequeño trozo de deuda del modelo (QSC-11) allí donde la regla de dominio resultó estar poco especificada.

Ese trimestre tres equipos trabajan a la vez sobre el modelo de paisaje. Eso es la partición por paquetes de CTX-6, con las fusiones pasando por CTX-7, que es el paso de integración de concurrencia que alimenta a CON-4, no una segunda autoridad de aprobación. Un conflicto genuino (dos equipos renombrando el mismo concepto compartido en direcciones opuestas) lo arbitra el Custodio del paisaje y queda registrado, no resuelto en silencio por quien fusionó el último.

## La auditoría trimestral encuentra algo

La auditoría es QSC-5, ejecutada por un Auditor contratado a través de GOV-6 con acceso acotado en el tiempo provisto vía GOV-7 y con desmontaje verificado al cierre. El Auditor es un arquitecto de otra parte de la empresa y no puede auditar trabajo que él supervisó.

La recolección de evidencia es trabajo de agente en T2, de solo lectura. El juicio no. El Auditor verifica que todo proceso declarado se ejecutó a su cadencia (paso 3), incluidos los trabajos de copia y los simulacros (QSC-13) y las operaciones de latido (QSC-15), y reconcilia toda alarma contra un registro de incidente (QSC-14). Después la reejecución, que la carta llama obligatoria: recalcular una muestra de puntuaciones de calidad, volver a validar sobre una versión pasada fijada, volver a decidir una muestra de veredictos de acceso (QSC-6), volver a trazar una muestra de acciones de agentes contra sus contratos de CTX-9 (QSC-7).

El hallazgo: la tubería de recolección de uno de los productos llevaba cinco semanas fallando en silencio. El conjunto de datos se espejaba desde un rastreador de incidencias, su estado de frescura debería haber pasado a rancio, y el monitor que lo habría cambiado había muerto. Los datos se seguían leyendo, y leyendo con confianza, que es justo el fallo que toda la familia MIR existe para prevenir.

La remediación no es tener más cuidado. El monitor muerto es un hallazgo de QSC-15 (un trabajo permanente cuyo propio latido nadie vigilaba), se convierte en un incidente QSC-14 con análisis sin culpables, y la lección del análisis se encamina como cambio versionado hacia las reglas de monitores y no hacia un memorándum. El conjunto de datos rancio se pone en cuarentena (MIR-8) para que toda cita de él lleve el señalamiento, y los registros afectados se vuelven a recolectar. Todo ello aterriza en el registro de deuda de calidad (QSC-11) con responsables y plazos, y el Propietario recibe el informe directamente, no solo el Custodio auditado.

## Federar con un socio

El mayor cliente de Northwind, un laboratorio por contrato, quiere que la configuración de su flota de instrumentos se mantenga sincronizada con el modelo de producto de Northwind. Esto es una federación, y corre la secuencia FED comprimida en unas seis semanas.

Primero descubrimiento y evaluación (FED-1): qué publica el socio, qué necesita, y qué aspecto tiene su perfil de confianza, evaluado por dimensión y no como una sola puntuación, de modo que la respuesta no es "de confianza" sino "dimensiones de identidad y contrato fuertes, historia operativa desconocida". Después negociación y firma (FED-2), que es un acto no delegable: firma el Propietario, ningún agente, ningún nivel.

El ciclo de vida del consentimiento (FED-3) concede exactamente dos proyecciones, ligadas a un propósito, con un TTL y una fecha de renovación, y toda concesión auto-emitida bajo la política permanente cita la versión de política que la produjo. La revisión de divulgación (FED-4) corre antes de que salga nada: qué se incluye, qué se redacta, y la comprobación acumulativa que pregunta a qué compone esta entrega combinada con todo lo que el socio ya tiene, para que el consentimiento no pueda trocearse en rebanadas hasta convertirse en algo que el Propietario jamás aprobó. Luego vienen el establecimiento y la sincronización inicial (FED-5).

La dirección entrante es donde se nota la disciplina. El socio también envía telemetría de la flota. No aterriza en el modelo. Aterriza en cuarentena de admisión (FED-8), ilegible hasta su promoción, cribada en busca de peligros incluido el contenido con apariencia de instrucción, y solo tras la promoción ejecuta MIR-2 el aterrizaje con procedencia. Las dos cosas llamadas cuarentena se mantienen distintas a propósito (COMMON 5): la cuarentena de admisión de FED-8 es ilegible hasta la promoción, la cuarentena de MIR-8 es legible pero señalada.

## Lo que cuesta, y qué obligaciones permanentes quedan

El perfil Estándar permite las cláusulas de consolidación en las que un solo Custodio responde de los registros consolidados, de modo que la recertificación de concesiones, contratos, efectores, derechos de entrada y niveles de servicio ocurre en una sola sesión trimestral por modelo en vez de en ocho rituales separados (COMMON 8, el patrón de recertificación de registros). La capacidad no se da por supuesta: las horas de custodio, las cuotas de cómputo de los agentes y las proyecciones de almacenamiento se planifican en GOV-5, que es lo que impide que todo el aparato se degrade calladamente hasta volverse una ceremonia que nadie tiene tiempo de hacer con honestidad.

El cambio medible al cabo de un año no es que la documentación mejorara. Es que cuando alguien pregunta qué depende de este componente, la respuesta viene del modelo, está al día, y si no lo está, el modelo lo dice.