Module Management maintains a live registry of every module the platform can offer and controls the enabled state of each one per deployment. Administrators enable a module to bring its full surface into the running system, or disable it to withdraw that surface cleanly, and the change takes effect across the suite at once. When a module is disabled its navigation entries disappear from the sidebar, its routes stop serving, and its programmatic endpoints refuse access, so a switched-off capability is genuinely absent rather than merely hidden behind a menu.

The registry carries the descriptive identity of each module: its display name and description, the icon and base path that anchor it in navigation, the ordering that fixes its position in the sidebar, and the flag that marks whether it is foundational to the platform. It also holds each module's declared dependencies, the other capabilities that must be present for it to function. On top of this the module distinguishes core capabilities, such as the system administration and dashboard foundations, which the platform requires to operate and therefore protects from being disabled at all. The result is a composition layer that lets an organisation tailor the suite to its structure while guaranteeing the platform never falls below the minimum it needs to run.

At the centre of this domain is the idea of a module: a self-contained business capability with a stable identity, a place in the navigation, and a defined boundary for the data and actions it governs. Each module is known by a unique short name that never changes, so the rest of the platform can refer to it reliably even as its description, icon or position are refined over time. Around that identity sits the presentational detail that gives a module its face in the interface, and the ordering that decides where it appears relative to its peers.

The second organising concept is enabled state, the simple but consequential fact of whether a capability is currently part of the deployment. State is not cosmetic: it determines navigation, route serving and access in a single stroke, which is why the registry treats it as the authoritative source of truth for what the platform currently offers. The third concept is dependency, the relationship each module declares toward the others it relies upon. A capability that draws on connector infrastructure or the system foundation names those needs explicitly, and the registry reads those declarations as a graph rather than a flat list, so that turning one capability on or off is always evaluated against the web of relationships around it. A fourth distinction, whether a module is core, sets apart the foundations the platform cannot run without, and those foundations are held permanently enabled. Together these concepts describe a system that is composed rather than fixed, where the shape of the suite is an explicit, governed configuration.

The defining workflow is composition. An administrator reviews the registry, sees every module with its current state, description and dependencies, and enables or disables capabilities to match the organisation's needs. When a module is enabled, its declared dependencies are checked so that it never comes online without the capabilities it requires; the registry surfaces any missing prerequisite and enables the chain in the correct order. When a capability is disabled, the registry checks in the other direction, identifying the modules that depend on the one being withdrawn so that nothing is left pointing at an absent capability. This two-way evaluation turns what could be a fragile manual exercise into a guided, safe operation.

Beyond enabling and disabling, administrators maintain module metadata, adjusting descriptions, icons and sidebar ordering to keep navigation coherent as the deployment evolves. They govern the registry itself, reviewing which capabilities are live, which are held dark, and how the whole footprint is arranged. Every one of these actions is an administrative operation guarded by permission, so composing the platform is a deliberate act performed by those entitled to perform it, and the current registry always reflects a considered configuration rather than accumulated drift.

The value of a composition layer lies in the rigour with which it enforces consistency, and Module Management is exacting about it. Dependency handling is transitive: because dependencies form a graph, the registry resolves them along their full chains, so enabling a capability brings up everything beneath it and disabling one is blocked or cascaded according to what still relies on it. This prevents the classic failure of a platform where a feature is nominally present but silently broken because something it needed was never switched on.

Core protection is absolute. The foundational modules that the platform depends on to function are marked as core and cannot be disabled under any circumstance, which removes an entire class of self-inflicted outage. Enforcement is defence in depth rather than a single check: disabling a module withdraws it from navigation, stops its routes and denies its endpoints, so the boundary holds whether a request arrives through the interface or directly against the platform's programmatic surface. Because the enabled state and the access boundary are one and the same, there is no gap between what a user can see and what they can reach. The registry also preserves a stable identity for every module, so permissions, audit records and integrations that reference a capability remain valid across every change to its presentation, and the composition of the suite stays legible and governable no matter how many times it is reshaped.

Module Management is the layer through which every other part of the suite becomes available. It works in concert with the permissions and access-control foundation: the registry decides whether a capability exists in a deployment, and access control decides who may use it, the two together forming the complete answer to what any given user can do. It draws directly on Connector Management, since data-integration modules declare their dependency on connector infrastructure and the registry honours that relationship when composing them. Capabilities such as Content Management sit downstream, coming online only when their system and connector prerequisites are satisfied.

Because the registry governs the sidebar, it shapes the experience delivered by the Dashboard and the navigation every operational module inherits, from finance and procurement to workforce and asset capabilities. The audit and activity layer of the suite records changes to the registry alongside every other administrative event, so the history of how the platform was composed lives in the same place as the rest of the organisation's operational record. In practical terms Module Management is the seam that lets a single suite present as many different platforms, each precisely fitted to the division or entity running it, while remaining one coherent system underneath.

AI Workers are first-class users of Module Management, working through the same registry and the same permission boundary as any administrator. An administrator can ask a Worker in plain language which capabilities are enabled across a deployment, what a given module depends on, or which modules would be affected by withdrawing a particular capability, and the Worker answers by reading the live registry and tracing the dependency graph. This turns the composition of the platform into something an administrator can interrogate conversationally rather than reconstruct by hand.

Workers also act. Within the permissions granted to them, a Worker enables or disables modules, resolves the dependency chain that a change requires, and adjusts module metadata, carrying out the composition an administrator describes. They watch the registry for anomalies and exceptions: a capability enabled without a dependency it should have, a configuration that diverges from a governed standard, an attempt to disturb a core foundation, and they raise those as alerts before they become faults. When a module's declarations or a proposed configuration arrive as a document or an external definition, Workers extract the relevant structure and reconcile it against the registry. In decision support they weigh the downstream impact of a change and lay out its consequences, and in governed workflows they participate as an approval or review node, examining a proposed change to the platform's composition and approving or holding it according to the rules the organisation has set, so that reshaping the suite is both faster and more disciplined.