CMDX splits each feature into layers, and each layer has one job. In the backend, routes handle HTTP, services hold the business rules, and repositories talk to the database. In the app, screens draw, hooks manage server state, and data files describe endpoints. This page explains what each layer owns and why the boundaries sit where they do.
A capability is a named permission that a role can grant, such as calendar:create. Each module declares its capabilities in code. At start-up, CMDX copies them into the database, where roles can use them. This page lists the fields of a capability, how a module registers one, and how start-up keeps the database in step. The code is in modules.capability_catalog.
CMDX settings that administrators can change at run time are declared in code as config keys and stored in the database by scope. This page lists the parts: the schema registry in core.config.lib.registry, the stored entries in the configentries table, and the audit trail in configaudit_log.
This guide is for platform engineers, plugin authors and API integrators. This page explains how CMDX is put together, so that the rest of the guide has a map to hang on.
A feature flag turns part of CMDX on or off without a new deploy. This page lists the flags the backend enforces today. Each flag is a boolean config key, so it follows the scope rules on the configuration page.
Every hook and event a plugin can subscribe to, when each one is delivered, and the keys in its payload.
The CMDX backend writes one log stream to standard output. This page lists the record format and fields, the helpers for writing records from code, what gets redacted, and the settings that control logging and Sentry error reporting. The code is in core.logging and core.privacy.redact.
One CMDX installation serves many tenants. Each tenant is an organization with its own members, courses and settings, and no tenant can see another's data. This page explains how tenants are stored, how CMDX works out which tenant a request is for, and what tenant-aware code has to do.
A plugin adds features to CMDX without changing the code in core/ or modules/. It is built from the same parts as a module: routes, tables, settings, capabilities and hook handlers. It is packaged so that an administrator can install, enable, upgrade and remove it on a running deployment. This page explains where plugins come from, the states a plugin moves through, what it can add, and how it is kept apart from the rest of CMDX.