La gestión de módulos mantiene un registro en vivo de todos los módulos que la plataforma puede ofrecer y controla el estado de habilitación de cada uno de ellos por despliegue. Los administradores habilitan un módulo para incorporar toda su superficie al sistema en ejecución, o lo deshabilitan para retirar esa superficie de forma limpia, y el cambio surte efecto en todo el conjunto de una sola vez. Cuando un módulo se deshabilita, sus entradas de navegación desaparecen de la barra lateral, sus rutas dejan de servir y sus endpoints programáticos deniegan el acceso, de modo que una capacidad desactivada está genuinamente ausente y no simplemente oculta tras un menú.

El registro contiene la identidad descriptiva de cada módulo: su nombre visible y su descripción, el icono y la ruta base que lo anclan en la navegación, el orden que fija su posición en la barra lateral y el indicador que señala si es fundamental para la plataforma. También conserva las dependencias declaradas de cada módulo, es decir, las demás capacidades que deben estar presentes para que funcione. Sobre esto, el módulo distingue las capacidades esenciales, como los cimientos de administración del sistema y del dashboard, que la plataforma necesita para operar y que, por tanto, protege de ser deshabilitadas en absoluto. El resultado es una capa de composición que permite a una organización adaptar el conjunto a su estructura, garantizando al mismo tiempo que la plataforma nunca descienda por debajo del mínimo que necesita para funcionar.

En el centro de este dominio está la idea de módulo: una capacidad de negocio autónoma con una identidad estable, un lugar en la navegación y un límite definido para los datos y las acciones que gobierna. Cada módulo se conoce por un nombre corto único que nunca cambia, de modo que el resto de la plataforma puede referirse a él de forma fiable aunque su descripción, su icono o su posición se vayan refinando con el tiempo. En torno a esa identidad se sitúa el detalle presentacional que da al módulo su rostro en la interfaz, y el orden que decide dónde aparece con respecto a sus pares.

El segundo concepto organizador es el estado de habilitación, el hecho sencillo pero determinante de si una capacidad forma parte actualmente del despliegue. El estado no es cosmético: determina la navegación, el servicio de rutas y el acceso de un solo trazo, razón por la cual el registro lo trata como la fuente autorizada de verdad sobre lo que la plataforma ofrece en cada momento. El tercer concepto es la dependencia, la relación que cada módulo declara hacia los demás en los que se apoya. Una capacidad que se sirve de la infraestructura de conectores o del cimiento del sistema nombra esas necesidades de forma explícita, y el registro lee esas declaraciones como un grafo y no como una lista plana, de manera que activar o desactivar una capacidad se evalúa siempre frente a la red de relaciones que la rodea. Una cuarta distinción, si un módulo es esencial, aparta los cimientos sin los que la plataforma no puede funcionar, y esos cimientos se mantienen habilitados de forma permanente. En conjunto, estos conceptos describen un sistema que se compone en lugar de estar fijado, donde la forma del conjunto es una configuración explícita y gobernada.

El flujo de trabajo que lo define es la composición. Un administrador revisa el registro, ve cada módulo con su estado actual, su descripción y sus dependencias, y habilita o deshabilita capacidades para ajustarse a las necesidades de la organización. Cuando se habilita un módulo, se comprueban sus dependencias declaradas para que nunca entre en funcionamiento sin las capacidades que requiere; el registro pone de manifiesto cualquier requisito previo que falte y habilita la cadena en el orden correcto. Cuando se deshabilita una capacidad, el registro comprueba en la dirección contraria, identificando los módulos que dependen del que se está retirando, de modo que nada quede apuntando a una capacidad ausente. Esta evaluación bidireccional convierte lo que podría ser un frágil ejercicio manual en una operación guiada y segura.

Más allá de habilitar y deshabilitar, los administradores mantienen los metadatos de los módulos, ajustando descripciones, iconos y el orden en la barra lateral para que la navegación siga siendo coherente a medida que evoluciona el despliegue. Gobiernan el propio registro, revisando qué capacidades están activas, cuáles se mantienen en reposo y cómo se organiza toda la huella. Cada una de estas acciones es una operación administrativa protegida por permisos, de modo que componer la plataforma es un acto deliberado que realizan quienes están facultados para hacerlo, y el registro actual siempre refleja una configuración meditada y no una deriva acumulada.

El valor de una capa de composición reside en el rigor con el que impone la coherencia, y la gestión de módulos es exigente al respecto. El tratamiento de las dependencias es transitivo: dado que las dependencias forman un grafo, el registro las resuelve a lo largo de sus cadenas completas, de modo que habilitar una capacidad levanta todo lo que hay por debajo de ella, y deshabilitar una queda bloqueado o se propaga en cascada según lo que siga apoyándose en ella. Esto evita el fallo clásico de una plataforma en la que una funcionalidad está nominalmente presente pero silenciosamente rota porque algo que necesitaba nunca se activó.

La protección de lo esencial es absoluta. Los módulos fundamentales de los que depende la plataforma para funcionar se marcan como esenciales y no pueden deshabilitarse bajo ninguna circunstancia, lo que elimina toda una categoría de interrupciones autoinfligidas. La aplicación de las reglas es una defensa en profundidad y no una única comprobación: deshabilitar un módulo lo retira de la navegación, detiene sus rutas y deniega sus endpoints, de modo que el límite se sostiene tanto si una solicitud llega a través de la interfaz como directamente contra la superficie programática de la plataforma. Dado que el estado de habilitación y el límite de acceso son una y la misma cosa, no hay brecha entre lo que un usuario puede ver y lo que puede alcanzar. El registro también preserva una identidad estable para cada módulo, de modo que los permisos, los registros de auditoría y las integraciones que hacen referencia a una capacidad siguen siendo válidos a lo largo de cada cambio en su presentación, y la composición del conjunto se mantiene legible y gobernable por muchas veces que se remodele.

La gestión de módulos es la capa a través de la cual cada una de las demás partes del conjunto pasa a estar disponible. Funciona en concierto con el cimiento de permisos y control de acceso: el registro decide si una capacidad existe en un despliegue, y el control de acceso decide quién puede usarla, formando ambos juntos la respuesta completa a lo que cualquier usuario dado puede hacer. Se apoya directamente en la gestión de conectores, ya que los módulos de integración de datos declaran su dependencia de la infraestructura de conectores y el registro honra esa relación al componerlos. Capacidades como la gestión de contenidos se sitúan aguas abajo, entrando en funcionamiento solo cuando se satisfacen sus requisitos previos de sistema y de conectores.

Dado que el registro gobierna la barra lateral, da forma a la experiencia que ofrece el Dashboard y a la navegación que hereda cada módulo operativo, desde finanzas y aprovisionamiento hasta las capacidades de plantilla y de activos. La capa de auditoría y actividad del conjunto registra los cambios en el registro junto con todos los demás eventos administrativos, de modo que el histórico de cómo se compuso la plataforma reside en el mismo lugar que el resto del registro operativo de la organización. En términos prácticos, la gestión de módulos es la costura que permite que un único conjunto se presente como tantas plataformas distintas, cada una ajustada con precisión a la división o entidad que la utiliza, sin dejar de ser por debajo un sistema coherente.

Los AI Workers son usuarios de primera clase de la gestión de módulos, y trabajan a través del mismo registro y del mismo límite de permisos que cualquier administrador. Un administrador puede preguntar a un Worker, en lenguaje natural, qué capacidades están habilitadas en un despliegue, de qué depende un módulo determinado o qué módulos se verían afectados al retirar una capacidad concreta, y el Worker responde leyendo el registro en vivo y trazando el grafo de dependencias. Esto convierte la composición de la plataforma en algo que un administrador puede interrogar de forma conversacional en lugar de reconstruir a mano.

Los Workers también actúan. Dentro de los permisos que se les han concedido, un Worker habilita o deshabilita módulos, resuelve la cadena de dependencias que exige un cambio y ajusta los metadatos de los módulos, llevando a cabo la composición que describe un administrador. Vigilan el registro en busca de anomalías y excepciones: una capacidad habilitada sin una dependencia que debería tener, una configuración que se aparta de un estándar gobernado, un intento de perturbar un cimiento esencial, y las señalan como alertas antes de que se conviertan en fallos. Cuando las declaraciones de un módulo o una configuración propuesta llegan como un documento o una definición externa, los Workers extraen la estructura relevante y la reconcilian con el registro. En el apoyo a la decisión sopesan el impacto aguas abajo de un cambio y exponen sus consecuencias, y en los flujos de trabajo gobernados participan como un nodo de aprobación o revisión, examinando un cambio propuesto en la composición de la plataforma y aprobándolo o reteniéndolo según las reglas que la organización haya establecido, de modo que remodelar el conjunto resulta a la vez más rápido y más disciplinado.