Module Management mantiene un registro in tempo reale di ogni modulo che la piattaforma può offrire e controlla lo stato di abilitazione di ciascuno per singolo deployment. Gli amministratori abilitano un modulo per portare la sua intera superficie all'interno del sistema attivo, oppure lo disabilitano per ritirare tale superficie in modo pulito, e la modifica ha effetto sull'intera suite in un'unica soluzione. Quando un modulo viene disabilitato le sue voci di navigazione scompaiono dalla barra laterale, le sue route smettono di rispondere e i suoi endpoint programmatici negano l'accesso, così una funzionalità disattivata è realmente assente e non semplicemente nascosta dietro un menu.

Il registro contiene l'identità descrittiva di ciascun modulo: il nome visualizzato e la descrizione, l'icona e il percorso base che lo ancorano nella navigazione, l'ordinamento che ne fissa la posizione nella barra laterale e il flag che indica se è fondamentale per la piattaforma. Contiene inoltre le dipendenze dichiarate di ciascun modulo, ovvero le altre funzionalità che devono essere presenti perché possa funzionare. Su questa base il modulo distingue le funzionalità core, come le fondamenta di amministrazione di sistema e del dashboard, che la piattaforma richiede per operare e che pertanto sono protette dalla disabilitazione. Il risultato è un livello di composizione che consente a un'organizzazione di adattare la suite alla propria struttura garantendo al contempo che la piattaforma non scenda mai al di sotto del minimo necessario per funzionare.

Al centro di questo dominio c'è il concetto di modulo: una funzionalità aziendale autonoma, con un'identità stabile, un posto nella navigazione e un confine definito per i dati e le azioni che governa. Ogni modulo è identificato da un nome breve univoco che non cambia mai, così che il resto della piattaforma possa farvi riferimento in modo affidabile anche mentre la sua descrizione, la sua icona o la sua posizione vengono affinate nel tempo. Attorno a questa identità si colloca il dettaglio presentazionale che dà al modulo il suo volto nell'interfaccia, e l'ordinamento che decide dove appare rispetto ai suoi pari.

Il secondo concetto organizzativo è lo stato di abilitazione, il fatto semplice ma determinante se una funzionalità faccia attualmente parte del deployment. Lo stato non è cosmetico: determina in un solo colpo la navigazione, la risposta delle route e l'accesso, motivo per cui il registro lo tratta come fonte autorevole di verità su ciò che la piattaforma offre in un dato momento. Il terzo concetto è la dipendenza, la relazione che ciascun modulo dichiara verso gli altri da cui dipende. Una funzionalità che si appoggia all'infrastruttura dei connettori o alle fondamenta di sistema dichiara esplicitamente tali necessità, e il registro legge queste dichiarazioni come un grafo anziché come un elenco piatto, così che attivare o disattivare una funzionalità venga sempre valutato rispetto alla rete di relazioni che la circonda. Una quarta distinzione, se un modulo sia core, separa le fondamenta senza le quali la piattaforma non può funzionare, e tali fondamenta vengono mantenute abilitate in modo permanente. Insieme questi concetti descrivono un sistema che è composto anziché fisso, dove la forma della suite è una configurazione esplicita e governata.

Il flusso di lavoro che definisce tutto è la composizione. Un amministratore esamina il registro, vede ogni modulo con il suo stato attuale, la sua descrizione e le sue dipendenze, e abilita o disabilita le funzionalità in base alle esigenze dell'organizzazione. Quando un modulo viene abilitato, le sue dipendenze dichiarate vengono verificate affinché non entri mai in funzione senza le funzionalità che richiede; il registro evidenzia qualsiasi prerequisito mancante e abilita la catena nell'ordine corretto. Quando una funzionalità viene disabilitata, il registro effettua la verifica nella direzione opposta, individuando i moduli che dipendono da quello che viene ritirato, così che nulla rimanga a puntare verso una funzionalità assente. Questa valutazione bidirezionale trasforma quello che potrebbe essere un fragile esercizio manuale in un'operazione guidata e sicura.

Oltre ad abilitare e disabilitare, gli amministratori gestiscono i metadati dei moduli, regolando descrizioni, icone e ordinamento nella barra laterale per mantenere coerente la navigazione man mano che il deployment evolve. Governano il registro stesso, esaminando quali funzionalità sono attive, quali sono tenute spente e come è disposto l'intero footprint. Ognuna di queste azioni è un'operazione amministrativa protetta da autorizzazione, così che comporre la piattaforma sia un atto deliberato eseguito da chi ne ha il diritto, e il registro attuale rifletta sempre una configurazione ponderata anziché una deriva accumulata.

Il valore di un livello di composizione risiede nel rigore con cui impone la coerenza, e Module Management è esigente al riguardo. La gestione delle dipendenze è transitiva: poiché le dipendenze formano un grafo, il registro le risolve lungo le loro catene complete, così che abilitare una funzionalità porti in funzione tutto ciò che le sta sotto e disabilitarne una venga bloccato o propagato a cascata in base a ciò che ancora vi si appoggia. Questo previene il classico fallimento di una piattaforma in cui una funzione è nominalmente presente ma silenziosamente inutilizzabile perché qualcosa di cui aveva bisogno non è mai stato attivato.

La protezione del core è assoluta. I moduli fondamentali da cui la piattaforma dipende per funzionare sono contrassegnati come core e non possono essere disabilitati in nessuna circostanza, il che elimina un'intera categoria di interruzioni autoinflitte. L'applicazione delle regole è una difesa in profondità anziché un singolo controllo: disabilitare un modulo lo rimuove dalla navigazione, ne arresta le route e nega i suoi endpoint, così che il confine tenga sia che una richiesta arrivi attraverso l'interfaccia sia che arrivi direttamente contro la superficie programmatica della piattaforma. Poiché lo stato di abilitazione e il confine di accesso sono una cosa sola, non esiste alcuno scarto tra ciò che un utente può vedere e ciò che può raggiungere. Il registro preserva inoltre un'identità stabile per ogni modulo, così che autorizzazioni, record di audit e integrazioni che fanno riferimento a una funzionalità restino validi attraverso ogni modifica alla sua presentazione, e la composizione della suite resti leggibile e governabile per quante volte venga rimodellata.

Module Management è il livello attraverso il quale ogni altra parte della suite diventa disponibile. Opera di concerto con le fondamenta di autorizzazioni e controllo degli accessi: il registro decide se una funzionalità esiste in un deployment, e il controllo degli accessi decide chi può utilizzarla, i due insieme costituiscono la risposta completa a ciò che un determinato utente può fare. Si appoggia direttamente a Connector Management, poiché i moduli di integrazione dei dati dichiarano la propria dipendenza dall'infrastruttura dei connettori e il registro rispetta tale relazione quando li compone. Funzionalità come Content Management si collocano a valle, entrando in funzione solo quando i loro prerequisiti di sistema e di connettore sono soddisfatti.

Poiché il registro governa la barra laterale, esso plasma l'esperienza offerta dal Dashboard e la navigazione che ogni modulo operativo eredita, dalla finanza e dagli approvvigionamenti alle funzionalità per il personale e per gli asset. Il livello di audit e attività della suite registra le modifiche al registro insieme a ogni altro evento amministrativo, così che la storia di come è stata composta la piattaforma risieda nello stesso luogo del resto del record operativo dell'organizzazione. In termini pratici Module Management è la cucitura che consente a un'unica suite di presentarsi come tante piattaforme diverse, ciascuna adattata con precisione alla divisione o all'entità che la utilizza, pur restando sotto la superficie un unico sistema coerente.

Gli AI Worker sono utenti di prima classe di Module Management e operano attraverso lo stesso registro e lo stesso confine di autorizzazioni di qualsiasi amministratore. Un amministratore può chiedere a un Worker in linguaggio naturale quali funzionalità sono abilitate in un deployment, da cosa dipende un determinato modulo, o quali moduli verrebbero interessati dal ritiro di una particolare funzionalità, e il Worker risponde leggendo il registro in tempo reale e tracciando il grafo delle dipendenze. Questo trasforma la composizione della piattaforma in qualcosa che un amministratore può interrogare in modo conversazionale anziché ricostruire a mano.

I Worker agiscono anche. Nell'ambito delle autorizzazioni loro concesse, un Worker abilita o disabilita moduli, risolve la catena di dipendenze che una modifica richiede e regola i metadati dei moduli, realizzando la composizione descritta da un amministratore. Sorvegliano il registro alla ricerca di anomalie ed eccezioni: una funzionalità abilitata senza una dipendenza che dovrebbe avere, una configurazione che diverge da uno standard governato, un tentativo di alterare una fondazione core, e le segnalano come alert prima che diventino guasti. Quando le dichiarazioni di un modulo o una configurazione proposta arrivano come documento o come definizione esterna, i Worker ne estraggono la struttura rilevante e la riconciliano rispetto al registro. Nel supporto alle decisioni valutano l'impatto a valle di una modifica e ne espongono le conseguenze, e nei workflow governati partecipano come nodo di approvazione o revisione, esaminando una modifica proposta alla composizione della piattaforma e approvandola o trattenendola secondo le regole stabilite dall'organizzazione, così che rimodellare la suite risulti al tempo stesso più rapido e più disciplinato.