Platform architecture
One control plane, twelve modules.
Multi-tenant isolation, a real time-bound and risk-tiered role model, a database-level-immutable audit log, and governed maker-checker approvals are shared infrastructure every module inherits — not bolted on per module after the fact.
Blueprint register
Five control layers inherited by every operating module.
Tenant & company structure
012 shared controls
Roles & permissions
022 shared controls
Approvals & workflow engine
032 shared controls
Immutable audit trail
041 shared control
Tenant onboarding & module entitlement
052 shared controls
Inherited across
What the platform is
Vercentlabs' platform architecture is the cross-cutting control plane every module runs on — multi-tenant and multi-company data isolation, role-based access control, a governed approvals and workflow engine, and an immutable audit trail, built once and inherited by all 12 modules rather than reimplemented per module.
Platform blueprint
One control plane beneath every module.
The platform centralises isolation, access, approvals, audit, and onboarding so operational modules do not have to recreate those controls independently.
Tenant & company structure
Organizations, companies, branches, departments, cost centers, and teams, with granular membership-scoped access.
Structural isolation
Company and branch scoping is enforced at the database layer, not filtered in the application.
Not all-or-nothing access
Access can be scoped to a specific company, branch, or department rather than granted organisation-wide.
Roles & permissions
12 seeded system roles with time-bound assignments and framework-neutral, per-module permission packages.
Time-bound role assignments
A role assignment can carry a start and expiry date, so access doesn't outlive its purpose.
Per-module permission packages
Permission keys are scoped per module, not one blanket 'admin' toggle.
Approvals & workflow engine
A generic approval-requests system plus a governed command registry with reusable decision and separation-of-duties primitives.
Reused across 8 modules
Accounting, Sales, CRM, HR, Assets, Projects, POS, and Support all build their approval chains on the same primitives.
Separation-of-duties by construction
The registry makes self-approval blocking a shared capability, not something each module has to reimplement correctly on its own.
Immutable audit trail
A database trigger makes the audit table immutable — UPDATE/DELETE are rejected at the Postgres level.
Enforced below the application
Even an application bug can't alter history, because the rejection happens at the database trigger level.
Tenant onboarding & module entitlement
Organisation bootstrap and module access are governed the same way for every tenant.
One-transaction bootstrap
Signup seeds 12 roles and roughly 29 numbering series in a single transaction.
Entitlement-gated modules
Each module's UI and API respect per-organisation entitlement — you only see and can use what you're licensed for.
See the controls in context
Follow a real transaction across modules, permissions, approvals, and audit history.
Inherited by design
The same controls, wherever work happens.
These modules expose different workflows, but they inherit the same identity, access, approval, and audit foundations.
One platform, every workflow