Module Registry & SDK — How it works

Overview

The module engine is the platform's extension registry. It records the modules known to a deployment, their versions, dependencies, declared permissions and menu items, and which tenants/facilities have each module activated. It also exposes the module SDK: a self-describing manifest that a future domain plug-in ships, validated read-only before registration.

Data model & ownership

Table	Purpose
module	Registered module; stable unique module_key.
module_version	Versions of a module.
module_dependency	Declares one module depends on another.
module_permission	Permissions a module contributes.
module_menu_item	Navigation contributed by a module.
tenant_module_activation / facility_module_activation	Which tenants/facilities have the module on.

Key rules & invariants

• module_key is unique; activation is gated (dependency validation via ModuleActivationDependencyValidator).
• Manifest validation is advisory and read-only (M9-006): it checks key/semver format, self-dependency, duplicate dependencies/permissions/menu paths, and extension type/target, and resolves declared dependencies against the registry — but never registers a module, so it does not bypass Module Engine ownership.

API

See the API Reference. Endpoint groups under /api/v1/module: registered modules, versions, dependencies, permissions, menu items, tenant/facility activation, and POST /module-manifests/validate.

Configuration & feature flags

None.

Related features

• Tenant / Facility (activation scope), Access control (module-contributed permissions). Domain plug-ins call this over Feign via exchange.client.module (RegisteredModuleClient, ModuleSdkClient).