Skip to content
NovaVMS Manual

Why governance and operations are separate roles

Why governance and operations are separate roles

An operations manager reconfiguring alert rules does not need to add a user who can see every camera in the org. The old three-role admin forced that trade — any power you gave for daily work also granted power over identity and secrets. The five-role model separates the two (per D81).

Governance is about people and secrets

Admin owns the governance surface. That means anything tied to identity, secret material, audit, or where money and data flow.

  • User CRUD and role assignment.
  • user_site_access grants (who sees which sites).
  • Audit log read access.
  • LLM model selection and cost caps.
  • Webhook secret rotation and API key issuance.
  • Org settings, password policy, org name.

Every item on that list either creates an identity, hands someone a key, or controls a compliance surface. You want exactly one role that can touch these, and you want its actions audited end-to-end. Decision D81 pins these to admin.

Operations is about devices and rules

Operator owns the operations surface. That means anything tied to the day-to-day work of running cameras.

  • Gateway pairing, updating, and removal.
  • Camera CRUD and manual trigger (Record Clip).
  • Alert rule CRUD.
  • Prompt pack content, temperature, and per-camera assignment.
  • Webhook definitions (URL and events) but not secret rotation.
  • Grids, layouts, and live view customisation.
  • Event acknowledge, star, and notes.

These are the levers you pull when a new site opens, when a camera moves, or when last night’s alerts were too noisy. A day-one operator should own all of these on day one.

Why over-granting hurts

Consider two real scenarios.

The operator who can see billing. An operations manager who rotates twice a year suddenly has permanent access to your invoice history, the owner’s email, and the payment method on file. That information leaks when the operator leaves. You now replace not just their account, but your trust in what they knew.

The admin who has to tune alert rules. An admin who lives in the identity and audit surface should not be paged at 2am because a camera moved and its alert rule needs adjusting. If the only role that can edit alert rules is the same role that approves payroll access, you get two bad outcomes: admins are overworked on ops, and operators are blocked on admins.

Splitting at D81 eliminates both. Admin stops being the oncall role; operator stops being a liability at departure.

What this means in practice

  • The /settings/users page and the audit log only render for admin and owner.
  • The /settings/ai/model page (model selection, cost caps) only renders for admin and owner. The /settings/ai/prompts page (prompt content) renders for operator and above (per D82).
  • The webhook list page shows definitions to operators. The “Rotate secret” button only renders for admin.
  • Cameras, gateways, alert rules, and grids render for operator and above.
  • Viewers see neither governance nor operations configuration. They see live, playback, and events at the sites granted to them.

Frontend route guards enforce this. The server checks the role on every request. A missing check on one page is not a soft failure — under the old model it leaked governance to operators; under the new model the role hierarchy is explicit at every handler.

See also