Navigation Operator Lens

Overview#

A single Argus deployment serves call handlers, dispatchers, supervisors, investigators, evidence custodians, analysts, and administrators. The historic response to that breadth was a mega-menu with eleven groups and a long scroll of destinations. New operators lost minutes finding the tool they actually needed. Experienced operators developed muscle memory for labels that still exposed them to rails full of applications they would never open on this shift. Procurement teams evaluating the platform against purpose-built CAD, RMS, or case tools often asked a blunt question: can people land in a workspace that looks like their job on day one?

Navigation Operator Lens answers that with a task-first shell. A lens names what the operator is here to do: call handling, dispatch, supervision, investigation, evidence, analysis, or administration. Each lens carries one landing route and at most seven intents on the bar at first paint. Everything else stays reachable through the command palette and the browsable capability catalogue, so the platform does not hide power; it stops shouting every capability at once. Critically, a lens is a view preference, not an authority boundary. Choosing the Administration lens grants nothing. Destinations still render access-denied states when the signed-in grants are missing, and middleware enforces every route.

For multi-agency and multi-role programmes, that distinction matters in demos and in production. Utilities dispatchers can be suggested onto a dispatch-shaped lens without widening fe2's permission hierarchy. Investigators open investigation first. Administrators still reach tenant controls when their grants allow it. The navigation_lens_v1 feature flag lets a tenant adopt the shell when catalogues and training are ready, without forcing a big-bang cutover.

Last Reviewed: 2026-09-15 Last Updated: 2026-09-15

Key Features#

Task-first lenses: Seven named lenses cover the dominant operator jobs on the platform. Each lens has a clear English description, a focal landing workspace, and a short intent bar. The shape is enforced in CI: one landing, at most seven intents, and every href must resolve against the discovered route catalogue.
Suggestion from real authority, not invention: Lens suggestion reads roles returned by /api/auth/me and, when needed, permissions. Role names include catalogue entries auth_service actually issues (including utilities-oriented roles that the fe2 authority union may not yet treat as permission grants). Suggestion never elevates privilege.
View preference versus enforcement: Operators can switch to any other lens at any time. The shell will show Administration intents to someone exploring that lens, and those intents still fail closed without the underlying permission. That design survives security review and customer questionnaire language about least privilege.
Command palette and catalogue as the long tail: Destinations beyond the seven intents remain available through the command palette and the browsable capability catalogue. Power users are not trapped in a simplified cage; newcomers are not drowned on first paint.
Feature-flagged rollout: The lens shell can sit behind navigation_lens_v1 (middleware feature-flag domain, mirrored in fe2). Tenants enable it when navigation catalogues, training packs, and change management are ready.
Keyboard-operable global navigation: Submenus and intent controls follow patterns expected under WCAG keyboard access, matching the wider shell accessibility bar.
Mobile catalogue parity: Responder mobile derives restricted route access from the same navigation catalogue vocabulary, so a role change updates which field screens appear without a separate mobile IA rewrite.
Honest denied, not-found, and failed states: Shared UI states replace blank screens when a deep link or catalogue entry points at something the operator cannot use or the service cannot load.

Use Cases#

PSAP day-one onboarding: A new call handler lands on call-handling rather than a wall of investigation and admin tools. Training time shifts from "where is everything" to "how do we take this call".
Utilities and public-safety coexistence: A utilities dispatcher is suggested onto a dispatch-relevant lens using auth_service role strings, without granting them investigative or admin permissions through a navigation side door.
Investigation and evidence focus: Analysts and custodians open lenses that put case, graph, and evidence work first, while still reaching cross-cutting tools through the palette when a lead demands it.
Supervisory tour without privilege creep: A supervisor can switch into administration-shaped navigation to understand what the team configures, and still hit access-denied on actions they are not cleared to perform.
Controlled enterprise rollout: A platform owner enables navigation_lens_v1 for a pilot agency, gathers feedback on intents and landings, then widens the flag once the catalogue is stable.

Integration#

Navigation Operator Lens is implemented in the fe2 app shell and global navigation packages (lenses.ts, catalogue, and href/shape gates). auth_service supplies roles and permissions through the standard session profile. Middleware feature flags expose navigation_lens_v1. Responder mobile consumes catalogue-derived route gates so native destinations stay aligned. Destination enforcement remains on middleware and application route guards; the lens never becomes a second RBAC system.

Integration with the Platform Capability Catalogue is intentional: the lens keeps first paint calm, and the catalogue remains the discovery surface for the long tail of modules and live tools.

Open Standards#

WAI-ARIA Authoring Practices: Intent bars and navigation submenus follow keyboard and disclosure patterns expected by assistive technology.
WCAG 2.2: Shell navigation meets the platform accessibility baseline for focus, naming, and operable controls.
OAuth 2.0 / OpenID Connect: Lens suggestion runs only after a verified authenticated session profile is available.
ISO/IEC 27001 access-control practice: Separating view preference from authorisation matches least-privilege expectations in enterprise security questionnaires.