Identity, permissions & community operations
Discord-linked identity, effective permissions, core community workflows, department/personnel data, training, tickets, applications, integrations, and audit foundations.
Roadmap · Development direction
Nexus overview · Roadmap & clients
Build the foundation first. Expand without fragmenting the platform.
ASRP is the first/reference Nexus deployment. The long-term architecture is multi-community and multi-tenant, with community-specific behavior supplied by configuration instead of being permanently hard-coded into the core.
Development phases
Current capability and future direction are clearly separated.
Deeper operations & FiveM
Broader department tooling, runtime entitlements, administration utilities, live synchronization, workflow automation, analytics, and tighter connected-system behavior.
Nexus CAD / MDT
Multi-agency calls, units, records, jurisdiction packs, configurable workflows, federation concepts, and deeper operational integration.
Desktop, mobile & in-game
The same Nexus identity, tenant, permissions, notifications, and modules extended to dedicated clients instead of creating separate accounts.
Client direction
Use the right client for the job.
Nexus does not need every task forced into one browser screen. The platform can offer specialized clients while preserving one identity and permission model.
Web
The primary universal client for member self-service, departments, tickets, applications, administration, configuration, and general Nexus access.
Desktop
A Windows-focused client for multi-monitor CAD/dispatch layouts, desktop notifications, FiveM awareness, advanced administration, diagnostics, and controlled release channels.
Mobile
iOS and Android direction for push notifications, approvals, tickets, applications, department tools, mobile CAD/MDT, maps, duty controls, secure device sessions, uploads, and quick operational actions.
In-game
A FiveM UI for authorized administration, player utilities, duty/department functions, CAD quick actions, diagnostics, and role-specific runtime tools.
Multi-community architecture
ASRP is Tenant #1, not the only community Nexus can ever support.
Branding, permissions, data models, jurisdiction packs, integrations, modules, and configuration are intended to be tenant-aware from the beginning.
That allows ASRP to remain the reference deployment while future communities can use Nexus without inheriting Alaska-specific assumptions that do not fit them.
Release discipline
Development, staging, production.
Platform administration and engineering controls are intended to respect environment boundaries, release roles, minimum supported client versions, rollout cohorts, update channels, and security-driven forced updates where necessary.
Public status language
No pretending future features are already live.
The public ASRP website will describe features as current, expanding, beta, planned, or future so members can understand the direction without confusing a roadmap with a release announcement.