Trust described plainly,from first-party knowledge.

Every material record in Role Central is scoped to a single organisation (a workspace). Every tenant-owned table carries an indexed organisation_id. Cross-organisation reads and writes go through an explicit tenancy-bypass helper — one that always logs an audit event when used. There is no path for an ordinary caller to see or modify another workspace's data.

Access is decided by a permission model applied on the server before aggregation. Every list, count and detail request is filtered by the caller's permissions inside the caller's workspace. The same permission model runs the day-to-day list views and the audit trail — a user cannot see one thing in a table and a different thing in the audit log for the same record.

Standard roles carry a documented set of permissions; custom roles inside a workspace may add or drop permissions within the boundaries the platform allows. Platform-level permissions (super-admin, platform administration) are not grantable from inside a workspace.

Projects, requests, tasks, board topics and board replies each carry a visibility (internal or customer-visible). List queries filter by visibility before rendering, so a customer viewing their workspace never sees internal-only records even if they know a URL. This is a data-level rule, not a client-side convention.

Every material domain change writes an audit event alongside the business row and the outbox event, in a single database transaction. Audit events are append-only. Downstream event handlers are idempotent by event id — the same event cannot be processed twice.

For the hosted production deployment, the application database user will additionally be constrained to INSERT and SELECT on the audit_events table so update and delete paths do not exist at the database layer. This database-level restriction is part of the pre-launch deployment configuration and will be verified before public launch — Role Central runs local-first today, and the current audit append-only guarantee is enforced by the application layer described above.

When a customer is invited into a workspace they receive their own seat entitlement, bound to the customer organisation. Customer users cannot escalate to workspace-admin capabilities through membership assignment — the customer-vs-internal distinction is enforced on both permission checks and record scoping.

Platform administration (super-admin, feature toggles, cross-organisation reporting) is a separate, permission-gated surface. It is not exposed to ordinary workspace members. All platform-administrative actions are logged.

Role Central does not currently claim SOC 2 / ISO 27001 / similar audits. It does not claim a specific data-residency region. It does not claim uptime SLAs.

These are decisions for a later production milestone; when they are established they will be documented here in the same first-party terms as everything above.