Platform overview
What the Platform app does: controlled releases, the package registry, extensions, background jobs, alerts, feature flags and recovery evidence.
What Platform is for
Platform is the control room for the system itself. It answers questions that business modules do not: which versions of which modules are approved to run, who approved this release, can we restore from a backup, did last night's background job run, and which switches are on. It does not hold customer or accounting data. It holds evidence and decisions.
Platform is a technical app. Most people never open it. A company member with no platform role sees only a Capabilities list: which apps the company has installed and the reviewed version of each.
The main areas
| Area | What it holds |
|---|---|
| Overview | One page of health: packages awaiting review, drifted packages, releases in flight, queued jobs, dead letters, open alerts, hours since the last good backup, flags waiting for approval, active extensions. |
| Packages | The registry of module versions and Extensions registered on published hook points. |
| Releases | Releases (a set of reviewed package versions going to one environment) and Environments (development, staging, production, recovery). |
| Operations | Scheduled jobs, Job runs, Restore drills, Alerts and Workload. |
| Reporting | Release readiness, Job health, Recovery evidence and Capabilities. |
| Configuration | Release policies, Alert policies, Feature flags, Vulnerability advisories, Bills of materials, Platform roles and the Audit trail. |
Key ideas
- Package. One version of one module (or a customer package), with a licence, a digest (a fingerprint of its files) and dependencies. It moves from Draft to Reviewed, then Certified, and finally Retired.
- Drift. A package is drifted when its files on the server no longer match the digest that was reviewed. A drifted package blocks a release.
- Release. A set of reviewed package versions going to one environment. It moves Draft, Reviewed, Staged, Approved, Active, Retired. Each step has gates that must pass. Approval produces a signed manifest.
- Environment. A place the system runs, with a recovery point objective (RPO), recovery time objective (RTO), a maintenance window and references to its secrets. Secrets are never stored here, only references such as
env:NAME. - Job. A background task run by the shared job engine, with a schedule, retries and a dead letter state.
- Restore drill. A proof that a stored backup can be restored in isolation, with row counts, file digests and ledger totals reconciled.
- Feature flag. A typed switch with two-person approval.
Platform roles
Platform has its own five roles, separate from business permissions:
| Role | Typical duties |
|---|---|
| Operator | Registers packages and extensions, creates releases, submits and activates them, runs jobs and drills, acknowledges alerts. |
| Release manager | Reviews packages and extensions, stages and cancels releases. |
| Independent approver | Certifies packages, approves releases and environments, activates extensions, decides flags and waives advisories. |
| Configuration owner | Creates environments, jobs and policies, retires packages and releases. |
| Viewer / auditor | Reads everything. |
The workspace owner holds every role. Only the workspace owner grants or revokes roles.
Separation of duties
The person who prepared something never approves it. This applies to packages, extensions, releases, environments, release policies and flags, and it applies to administrators and superusers too.
Platform records what was approved and when. Activating a release does not deploy code. Deployment is done on the server first, and Activate then checks the evidence and records it. There is no automatic rollback; Recover records a forward fix or a restore.