Roles
What each role may do
Four roles exist in the drone subsystem. Published here so that a person requesting access and the administrator approving it are using the same words.
| Role | May | May not |
|---|---|---|
| Viewer | Read synthetic fleet state, mission history, protocol traffic and evidence records. | Change anything. |
| Planner | Validate route files, compose mission proposals, run preflight and recovery assessments. | Release a mission, or command a device. |
| Operator | Execute simulated mission lifecycles and run recovery planning against the protocol twin. | Command real hardware, or authorize a flight. |
| Supervisor | Everything above, plus fault injection, journal review and conformance exercises. | Authorize a flight. |
No role authorizes a flight. Not supervisor, not any combination, not any future role. Flight authorization comes from an aviation regulator and the agency operating the aircraft, and this platform is not in that path.
How a role is assigned
Roles are not selected by the person requesting them. A request states what someone needs and why; an administrator then assigns the exact workspace, roles, purposes and jurisdiction scope after approval. The subsystem reads that assignment from the verified session and enforces it server-side — the browser is never the authority on what a person may do.
What access actually gives you
A view of a synthetic development environment: seeded scenarios, deterministic protocol traffic, generated media fixtures and replayable assessments. Every screen carries a permanent notice saying so, because a simulated mission and a real one look identical in a screenshot.