-
Notifications
You must be signed in to change notification settings - Fork 1
Users hierarchy
In order to ensure structural integrity, operational security, and efficient delegation within the platform, a user-based hierarchy system has been established. Each user is assigned a distinct role, which determines their scope of visibility, access rights, and the operational commands they may execute.
This system is designed to facilitate clarity in responsibility, reduce permission-related conflicts, and maintain the sanctity of sensitive data operations.
The platform operates under a multi-tiered system of roles. Each role inherits or restricts abilities to match its intended operational capacity.
Roles are not merely titles — they are behavioral contracts.
Each role determines the functional scope, visibility level, and interaction rights of a user within the ecosystem.
The system adheres to the doctrine of modular authority: higher roles do not override lower ones arbitrarily, but instead observe, direct, and review within boundaries defined by their domain.
Role Code:
mgmt.supervisor.root
Visibility: All systems
Authority: Strategic & Diagnostic
Purpose:
Represents the governance body. Has panoramic access across all modules, metrics, and user activities — but cannot directly modify operational data or override user actions.
This role is a steward, not an executor.
Abilities:
- Full visibility of all user actions and content modules
- Access to system-wide statistics and performance dashboards
- May initiate proposals and structural changes
- Cannot execute or alter direct work of any analyst
Role Code:
dir.subdivision
Visibility: Assigned subdivision
Authority: Strategic & Operational
Purpose:
Oversees a specific subdivision (e.g., Digital, Events, Design). Assigns work, reviews progress, and ensures alignment with objectives.
They are strategic operators, not micromanagers.
Abilities:
- Access to their team’s boards, data, reports
- Assigns and reviews tasks
- Adds comments and strategic feedback
- Cannot execute or directly modify analyst outputs
Role Code:
sup.local
Visibility: Assigned teams
Authority: Tactical Monitoring
Purpose:
Manages the day-to-day execution within a team or function. Provides feedback, escalates issues, and tracks progress.
Their role is observational with influence, not executional.
Abilities:
- View live activity logs and status of analysts
- Mark tasks for revision or review
- Cannot assign tasks or modify existing ones
- May comment and suggest corrections
Role Code:
usr.analyst
Visibility: Assigned modules only
Authority: Executor
Purpose:
Primary functional unit of the system. Analysts are the ones who interact with integrations, perform operational tasks, and generate deliverables.
Abilities:
- Execute tasks and workflows in assigned modules
- Upload and manage content/data within scope
- Receive comments and feedback
- Cannot modify role-based permissions
Variants (depending on subdivision):
- Digital Analyst
- Event Analyst
- Creative Analyst
- Internal Ops Analyst
Role Code:
guest.observer
Visibility: Read-only access
Authority: None
Purpose:
Provides passive access to external consultants, stakeholders, or auditors. Can be temporary, time-restricted, or scoped to specific projects.
Abilities:
- View assigned boards, reports, or content
- No ability to comment, assign, or interact with data
Role Code:
sys.root
Status: Dormant by default
Purpose: Emergency override
Used only for:
- System migrations
- Critical bug interventions
- Access recovery
This role should not be used in day-to-day operations. It is stored in a sealed crypt within the platform’s system architecture.
In addition to roles, each user may be assigned Permission Sets that define specific capabilities, including but not limited to:
- Access to cross-division dashboards
- Upload privileges to shared repositories
- Beta feature usage
- API integrations or testing
This allows flexibility within a role without altering the hierarchy itself.
- Subdivision-specific dashboards
- Role audit logs and history
- Role-based visual themes
- Task execution timeline analysis per role
Let it be known that hierarchy exists not to dominate, but to harmonize function.
In perfect modularity lies order, and from order, productivity.
- Roles are assigned at user creation or by authorized administrators.
- A user's role may evolve as their duties and trust level increase.
- Certain modules may enforce role-based view modes, such as filtered dashboards or limited action buttons.
The hierarchical system is not merely an organizational preference, but a fundamental layer of the platform’s defense architecture. Misassigned permissions can lead to data compromise, workflow confusion, or unintended overwrites. Therefore, every role assignment must be deliberate and recorded.
"From the smallest task to the highest command, all must operate within their designated frame lest disorder take root."