Roles and permissions overview
This document describes the role and permission model used in Balyze.
It focuses on access principles and responsibilities rather than technical implementation details.
Roles
At the current ALPHA stage, Balyze defines a minimal set of roles.
Candidate
The default role assigned to regular users.
A candidate:
- manages their own positions, applications, and documents
- may only access data they own
- interacts with the system within strict ownership boundaries
This role represents the primary user of the platform.
Administrator
An administrator has elevated access for maintenance and supervision purposes.
Administrators:
- may bypass ownership restrictions when necessary
- do not follow candidate-specific domain constraints
- are intended for operational and support use only
Administrative access is explicit and limited.
Permission model
Permissions are defined to support domain actions rather than technical operations.
General principles:
- permissions describe what can be done, not how
- permissions are evaluated in addition to ownership rules
- lack of permission results in access denial by default
Permissions are designed to evolve as the domain grows.
Ownership and permissions
Ownership remains the primary access boundary.
In practice:
- ownership is checked first
- permissions refine allowed actions
- domain services enforce business validity independently
Permissions do not override domain rules.
Out of scope considerations
The following topics are intentionally deferred:
- fine-grained permission sets
- permission management UI
- dynamic role creation
- public or third-party access roles
These aspects will be introduced progressively as needed.
Guiding principles
- minimal roles, explicit responsibilities
- deny by default
- ownership before permissions
- domain rules cannot be bypassed by permissions