All documentation

Book 6

Engineering Handbook

Public engineering principles for extending OPSQAI without weakening product, entitlement or customer-data boundaries.

1. Conventions

  • Strict typed application code and explicit server boundaries.
  • Semantic design tokens and the active documented visual language.
  • Every new public data table includes grants, row-level security and policies.
  • No private key or provider credential is shipped to the browser.

2. Product architecture

The canonical sequence is Core Platform → Company Profile → Enabled Products → Optional Add-ons → Effective Configuration → Visible Workspaces. Legacy module names are compatibility inputs, not a second catalogue.

3. Adding a Product Workspace

Workspaces belong to a canonical OPSQAI Product, reuse Core context, and appear only after entitlement and role checks. New workspaces must represent implemented domain behavior rather than invented ERP, TMS, HRIS or accounting functionality.

4. Issuing a license

Management Center selects an existing company, shows its Company Profile and enabled Products, and issues an Ed25519-signed JWT. Reissuing distributes changed entitlements; Self-Hosted validates and activates the bundle locally.

5. AI providers

AI access stays behind the provider abstraction. Ollama supports fully local operation; other approved providers are installation configuration. Features must preserve language, grounding, access and audit requirements.

6. Windows releases

The release pipeline produces signed Windows installation and update packages. Customer Portal exposes only authorized release material; Self-Hosted verifies and applies updates through its supported operational flow.

7. Verification

  • Architecture and entitlement tests pass.
  • Windows packaging and boundary checks pass.
  • Fresh install and upgrade health checks pass.
  • License preview, activation and audit history work.
  • Public documentation matches the implemented product.