System Management brings the platform's operational surface into one place. System health reports the live condition of the host and the runtime: operating system, processor load, memory pressure, uptime and the runtime powering the application, alongside the status and physical size of every database in the estate and a running count of the records they hold. A components inventory lists the installed packages and their versions, giving administrators an exact picture of what is deployed. Cache statistics expose the in-process caches that accelerate the platform, and a single action flushes them when configuration must be reloaded immediately.

Two logs anchor accountability. The audit log is a searchable, filterable history of consequential actions, filterable by action type and by affected entity, and exportable to spreadsheet for offline review or evidence. The error log captures application faults and warnings with severity, message, stack and the route on which they arose, so a fault can be traced to its origin in seconds. Regional settings govern locale, timezone, date, number and currency formatting for the entire platform. Style and branding control the colours, logo, favicon and brand name that render across every layout. Maintenance mode, developer indicators and the platform's operating mode complete the set, letting administrators signal the environment's posture unambiguously to every user.

Conceptually, System Management is organised around four ideas that rarely surface together in one module but belong together here. The first is platform state: the momentary, measured truth about how the system is running. State is observed rather than authored, gathered live from the host, the runtime and each database, and it is never something an administrator edits, only something they read and act upon.

The second idea is the activity record. Every meaningful action leaves a durable trace: what was done, on which entity, by whom, from which address and at what moment, together with a structured detail of the change. Faults form a parallel record, graded by severity and tied to the context in which they occurred. Both are enriched at the point of reading, so that an actor recorded only as an identifier is resolved into a real, named user drawn from the identity domain. This separation, an immutable ledger of activity kept apart from the live operational data it describes, is what lets the record be trusted.

The third idea is platform configuration: the durable choices that shape behaviour everywhere. Regional conventions and the visual identity are each held as a single authoritative setting, read constantly by the rest of the suite and written only through this module. The fourth idea is the protected estate: the set of databases treated as one recoverable whole, so that a backup captures a consistent moment across every store and a restore returns the platform to that moment intact. Together these four concepts describe everything the control room governs without exposing any of the machinery beneath them.

The daily rhythm begins with the health dashboard. An administrator opens it to confirm that services are responsive, that memory and processor headroom are comfortable, and that every database is online and sized as expected. When a figure looks wrong, the same screen offers the immediate remedies: flush the caches to force fresh configuration, or inspect the component inventory to confirm exactly what is running.

Investigation flows through the two logs. A reported problem is traced by filtering the error log to the relevant severity and searching for the message or route, then cross-referencing the audit log to see which action preceded the fault and which user performed it. Where an audit trail is required for governance or dispute, the administrator filters to the period and entity in question and exports the result to a spreadsheet. Configuration flows are deliberate and reviewable: an administrator opens regional settings or branding, makes a change, and the platform adopts it globally, with the change itself written to the audit log. Protection flows on a schedule and on demand: backups are created and listed as aggregated points in time, and a restore selects one such point and returns the estate to it. Maintenance mode brackets any disruptive operation, presenting a clear signal to users while work proceeds.

The depth of this module lies in its rigour. Health aggregation is genuinely multi-database: the transactional store, the operational data store, the logging store, the configuration store, the binary store and the analytical warehouse are each measured for size and table count and reported side by side, so capacity planning rests on real figures rather than estimates. Audit coverage is comprehensive by design. Operating-mode changes, branding updates, error-log clearances and every backup operation write their own audit entries, which means even the acts of administration are themselves accountable, and the record cannot be quietly emptied without leaving a trace of the emptying.

Regional handling is treated as a correctness concern rather than a cosmetic one. Locale, timezone and the formatting of dates, numbers and currencies are resolved centrally so that a value is stored once and rendered consistently wherever it appears, which removes an entire class of ambiguity from cross-border operation. Branding is applied as a global read: every layout, sidebar and component consumes the current identity without needing write access, so a single change propagates everywhere at once. Logging is structured throughout, with connector traffic captured in both directions, complete with method, status, latency and payloads, giving integration faults the same forensic clarity as internal ones. Backups are consistent across stores and restores are point-in-time, so recovery is exact rather than approximate.

System Management is the layer the rest of the suite stands on. It works most closely with Users and Roles and the permission framework: every audit and error entry is enriched with real user detail drawn from identity, and every capability in this module, from viewing health to clearing errors to creating backups, is gated by a fine-grained permission subject. It underpins Module Management, reading the module registry to report versions and status and flushing its cache when the registry changes.

Its configuration reaches everywhere. Regional settings feed formatting into Finance and Accounting, Sales, Procurement and every module that renders a date, an amount or a currency, so a single locale choice governs the whole platform. Branding is consumed by the shared layout that frames every screen in the suite. The connector traffic log gives Integrations a precise record of ingress and egress, and the aggregated backup coverage protects the data owned by every operational module in one consistent operation. Because email and notification delivery, number generation and the event flow all route their administrative actions through this module's audit and error logging, System Management is the common accountability layer beneath the entire product.

AI Workers operate inside System Management as first-class administrators with their own scoped permissions. An administrator queries the platform conversationally, asking which database has grown fastest this month, which routes are producing the most errors, or who changed the branding last week, and the Worker answers directly from health metrics and the audit and error records rather than from a static report. Workers execute administrative actions on instruction: flushing caches, exporting an audit period, or initiating a backup, each action itself audited exactly as a human's would be.

Their standing value is vigilance. Workers watch health telemetry and the error stream continuously, raising an alert when memory pressure climbs, when a database approaches a capacity threshold, when error rates spike on a particular route, or when an anomalous pattern of privileged actions appears in the audit trail. They extract structure from raw logs, distilling a burst of stack traces into a single explained root cause, and they offer decision support by correlating a fault with the configuration change or deployment that preceded it. Where a sensitive operation demands oversight, such as clearing the error log or restoring the estate, a Worker serves as a review or approval node in the workflow, checking the request against policy and the current health picture before the action is allowed to proceed.