Quorium
v2.0 ENTERPRISE RELEASE

The Runtime Governance Layer
for Enterprise Frontends

Quorium is a runtime governance system for enterprise frontend composition. It unifies permission filtering, route generation, navigation, runtime rebuild, and plugin capability boundaries into one coherent platform — built on Vue 3 + Quasar.

It prevents permission drift, route sprawl, and store chaos in large-scale Vue applications.

Etymology

Quorium combines Quorum — the minimum agreement needed to act — and Core.

A quorum-based runtime that determines what is allowed to exist in a frontend system — based on rules, permissions, and capabilities.

projects.module.ts
export const ProjectsPlugin: QuoriumPlugin = {
  manifest: { id: 'projects', version: '1.0.0' },
  routes:   projectsRouteSpecs,
  install({ app }) {
    app.provide(PROJECTS_SERVICE_TOKEN, new ProjectsService());
  },
  isEnabled(flags) {
    return flags.has('module.projects');
  }
};
One file. Typed DI. Permission-governed routing. Feature-flag gated. That's a Quorium module.

Why Quorium Exists

Large frontend applications eventually collapse into chaos. Quorium introduces runtime composition — your app decides at runtime what is allowed to exist.

The Problem
The Collapse of SPAs
cancelSpaghetti routing that no one dares refactor
cancelBloated global stores leaking across boundaries
cancelHidden cross-feature dependencies
cancelFeature flags scattered across every component
cancelPermission checks duplicated everywhere
The Answer
Quorium Governance
check_circleRoutes generated dynamically from permissions
check_circleTyped DI tokens isolate every module boundary
check_circleCross-module communication via capability contracts
check_circleFeature flags centrally governed per tenant & edition
check_circleSingle source of truth for permissions & navigation
It’s not a UI kit. It’s not just a folder pattern.
It’s a governed execution layer
for modern enterprise frontends.
Without Quorium
Scattered route meta across dozens of files
Global store chaos with leaking state
Hidden permission checks in components
Feature flags disconnected from UI
Manual menu config that drifts from routes
With Quorium
Single RouteSpec per module
Scoped stores via typed DI tokens
Automatic permission-filtered navigation
Dynamic route rebuild on session change
Governed plugin lifecycle with manifests

What Quorium Does

Designed to mirror the discipline of backend frameworks like NestJS — on the client side.

Permission-Driven Routing

Routes are generated dynamically based on user permissions. No more hiding menu items while routes remain manually accessible.

Plug-and-Play Modules

Install a feature. Enable it via backend flag. Quorium composes it into the runtime automatically without redeploying.

Navigation via Single Source

Routes define navigation. Navigation reflects permissions. Absolutely no duplicated menu configuration.

Runtime Rebuild

Login. Logout. Role update. Quorium intercepts session mutations and rebuilds your entire runtime safely and instantly.

Strict Module Boundaries

No circular imports. No peer-module chaos. Cross-module capabilities are strictly injected via typed DI tokens.

Feature Flag Governance

Modules can be enabled or disabled per tenant, per edition, or per organization entirely at runtime.

How It Works

Quorium sits above the UI layer and intercepts module installation, routing, and capabilities — composing your application purely at runtime.

Boot Lifecycle
Quasar Boot
Load Session
Fetch Flags
Install Modules
Build Routes
Build Nav
App Ready
Tier 3 — UI Presentation
Vue 3 Pages
Quasar Layouts
Auto-Generated Nav
Tier 2 — Quorium Orchestration Engine
Route Manager
DI Registry
Permission Guards
Feature Flags
Session Events
Validates Permissions Checks Feature Flags Rebuilds on Session Change
Tier 1 — Independent Feature Modules
Auth Module
Session & Tokens
Projects Module
CRUD & Store Domain
Billing Module
Tenant Flag-Gated
Inside Each Module
projects.module.ts
Entry point — wires service via DI, declares routes, checks isEnabled
Client
Typed HTTP calls
Service
Business logic
Store
Pinia + DI
Pages
List / Detail / Create
Policy
Permission checks
Runtime Rebuild Cycle
Session Changed
Flush Routes
Reinstall Modules
Rebuild Nav
Live
Login, logout, or role change triggers a full runtime recomposition — zero page reload.

Designed For

  • Enterprise admin panels
  • Multi-tenant SaaS platforms
  • Role-based systems
  • Edition-based products (Free / Pro / Enterprise)
  • Large Vue applications with 20+ feature modules
  • Teams that want discipline without losing flexibility

Not Just Structure — Governance

Quorium treats the frontend like a governed system, not a pile of components. It enforces:

  • Feature boundaries & Capability contracts
  • Manifest validation for versioned plugins
  • Route + permission absolute alignment
  • Centralized runtime decision logic
  • Future-ready remote module loading
This is frontend architecture with intent.

The Vision

Quorium is not just a pattern. It’s a step toward treating frontend systems as governed platforms. Where features are not hardcoded — they are admitted by quorum.

Documentation

8 parts — from philosophy to remote plugin loading. One coherent system.

Part 1
Philosophy & Rules

Separation of concerns, naming conventions, dependency flow, and cross-module communication patterns.

Part 2
Core Layer

Typed DI tokens, event bus, session service, auth guard, module manager, navigation, and the governance flow diagram.

Part 3
Module Example

Complete Projects module: routes, client, service, store, policy, and DTOs — the full pattern in practice.

Part 4
Wiring & Boot

Quasar boot file, module registry, feature flag loading, session event wiring, and defense-in-depth guards.

Part 5
Plugin & Addons

QuoriumPlugin contract, manifest schema, RuntimeCtx, requires/provides capability model, and lifecycle phases.

Part 6
Plugin Infrastructure

JSON Schema, Zod runtime validation, manifest validator, and the quorium-cli scaffold generator concept.

Part 7
Remote Plugins

Loading flow, signed manifests, domain allowlist, and trust levels: Core / Verified / Community.

Part 8
Architecture Summary

Layer responsibility table, full capabilities matrix, and Quorium as a frontend runtime platform.

Get Started

From a fresh Quasar project to a governed runtime platform in 5 steps.

1
Configure the Generator

Set your database connection and target tables in generator.config.ts.

tables: [
  { table: 'users',    global: true  },
  { table: 'projects', global: false },
]
2
Run the Generator

Generates the full Quorium module structure — client, service, store, routes, pages, policy, DTOs — from your DB schema.

npm run generate
# Outputs: template-frontend-q/src/modules/{table}/
#          template-frontend-q/src/core/
#          template-frontend-q/src/boot/modules.ts
3
Module Registry (Auto-Generated)

src/modules/index.ts is the single registry. Generated automatically — just import and ship.

import { ProjectsModule } from './projects/projects.module';
import { UsersModule }    from './users/users.module';

export const modules = [ProjectsModule, UsersModule];
4
Register the Boot File

Add src/boot/modules.ts to your Quasar config. This single file wires the entire governance runtime.

// quasar.config.ts
boot: ['modules']
5
Auto-Generated Navigation in Layout

Consume permission-filtered navigation directly. No menu config file needed — ever.

// MainLayout.vue
const navItems = computed(() =>
  buildNavigation(modules, {
    permissions:    new Set(session.getPermissions()),
    enabledModules: new Set(flags.enabledModules),
  })
);
Done. Login, logout, or role change now rebuilds everything automatically.
Quorium
The Quorum That Governs Your Frontend.
© 2026 Quorium Architecture. Open Source Enterprise Pattern.