Extend the platform without breaking its security and business invariants.
This guide explains the architectural boundaries that matter when adding a module, integration, route, background job, or deployment change.
Central academy scope
The production tenancy model uses one central database and academy-scoped records. Browser central domains stay in the central application. Mobile API requests resolve an academy context and then require it to match both the authenticated user and token.
Safe module changes
- Validate every related identifier as global or belonging to the active academy.
- Use transactions and locks for money, state transitions, quotas, and one-time records.
- Keep client telemetry advisory; calculate learning, assessment, and entitlement state on the server.
- Use queued, idempotent work for provider calls and automation actions.
- Use the shared secret codec; never expose stored secrets in settings responses, logs, errors, or activity history.
Release workflow
- Back up the database and environment configuration.
- Run migrations and reconciliation tasks in a staged environment.
- Build assets, cache views, run tests and dependency audits, then run security readiness.
- Rotate integration credentials, revoke tokens when required by a security rollout, restart workers and scheduler, and monitor failures.
Do not copy secrets into documentation, screenshots, issue reports, or client-side configuration. Provider setup and payment activation remain controlled post-install Settings tasks.