Glossary

Customer Portal uses several similar words for deliberately different concepts. Use these meanings in issues, documentation, code review, and module proposals so a discussion does not confuse packaging, product navigation, or authorization.

Platform and composition

Customer Portal

The MIT-licensed Nuxt package family that combines a headless core, UI primitives, platform layers, and optional business layers into a deployable portal.

Host application

The Nuxt application that composes enabled layers and owns branding, public pages, app.vue, layouts, global styling, assets, and deployment configuration. The host should not import feature-private menus, pages, or server handlers.

Core

The visually headless foundational layer that owns sessions, active-organization context, authorization adapters, the feature registry, database access, and shared contracts. Business layers depend on core; core never depends on an optional feature.

Platform layer

A layer that provides reusable portal infrastructure rather than one optional business capability. UI, authentication, organizations, and administration are current platform layers; public sites are host-owned.

Feature layer

The source and packaging boundary for one coherent business capability. A feature layer can own pages, components, composables, plugins, API routes, translations, types, tests, and a PostgreSQL schema. service-requests and timesheets are feature layers.

Module

A cohesive product area contributed to the application shell. A module has a landing route, matching route prefixes, audiences, and an optional sidebar menu. One feature layer may contribute multiple modules; the timesheets layer contributes Timesheets and Invoices.

Feature definition

The typed PortalFeatureDefinition registered by a layer. It groups the feature ID, navigation, modules, dashboard widgets, and organization-role policy.

Contribution

One item a feature adds to a shared portal surface, such as a navigation link, module, module-menu item, dashboard widget, or named PortalSurfaceContribution. The UI aggregates contributions without importing the feature directly.

Feature registry

Core's runtime collection of feature definitions. Registration is idempotent by feature ID: registering the same ID again replaces its previous definition, enabling capability-filtered menus, widgets, and surfaces.

Identity, tenancy, and authorization

Active organization

The organization selected in the authenticated session. Feature APIs derive their tenant boundary from this context instead of trusting an organization ID supplied by the browser.

Tenant

An organization whose records must remain isolated from other organizations. A tenant-owned query always includes the authorized organization boundary.

Organization role

Membership authority inside one organization: owner, admin, or member. A person can have a different role in another organization.

Organization owner

The highest organization role. Owners receive the feature actions granted to owner and may perform especially sensitive organization operations that ordinary organization administrators cannot.

Organization administrator

An organization member with the admin role. Administrators normally configure feature workspaces and manage organization workflows, but they are not automatically installation-wide system administrators.

System administrator

An installation-wide administrator identified by the platform’s system role. System administrators receive the standard feature-policy bypass and can administer users and organizations across the installation.

Audience

A shell-visibility category: public, authenticated, organizationAdmin, or admin. Audiences decide whether navigation is shown; they do not protect an API route.

Policy

A typed mapping from organization roles to feature actions. Each server route independently enforces the relevant action through core authorization adapters.

Action

A feature-defined authorization verb such as read, create, submit, approve, or manage. Actions describe business authority more precisely than a visible route or button.

Capability

A context-specific result that says whether a user can perform or see something in the active organization. Capabilities may combine role, feature policy, workspace settings, assignments, linked-organization access, and pending work.

Cross-organization access

Explicit access from one organization to narrowly scoped records owned by another. Client review, supplier timesheets, and received invoices use dedicated relationships rather than weakening the normal active-organization boundary.

User interface contracts

Navigation item

A top-level destination contributed by a feature. It has a stable ID, translated label, route, audiences, location, order, and optional badge.

Module menu

The sidebar destinations for the currently active module. Route prefixes select the module; audiences and capabilities filter what the current user sees.

Dashboard widget

A feature-owned Vue component placed by the UI layer into attention, main, or aside. Its definition also declares size and deterministic order. An error boundary isolates each widget from the rest of the dashboard.

Badge

A static or capability-derived indicator on navigation, modules, or menu items. Counts communicate pending work but never replace server authorization.

Data and API contracts

Feature-owned PostgreSQL schema

A PostgreSQL namespace containing a provider's tables and enums. Its name normally derives from the provider ID. Cross-schema foreign keys may reference core users and organizations.

Provider migration stream

An immutable migration directory owned by one official, local, or third-party provider. The kit validates checksums and applies provider streams in dependency order under a PostgreSQL advisory lock, with one journal table per provider.

DTO

A data-transfer object explicitly shaped for an API consumer. DTOs keep persistence details and private columns out of client responses.

Server adapter

A stable core function used by feature APIs for sessions, active organizations, authorization, organization members, organization lookup, and database access. It prevents runtime dependencies on private authentication or host implementations.

OpenAPI contract

Machine-readable metadata describing an API operation, request, response, and error behavior. Customer Portal serves the generated contract through its authenticated API documentation routes.

Timesheets and invoices

Timesheet workspace

The active organization’s configuration for time entry, team members, clients, projects, activities, rates, approvals, reports, and invoicing.

Supplier organization

The organization that owns a timesheet workspace and supplies recorded work to a linked client organization.

Client organization

An organization linked to a supplier workspace for view, review, or invoice access. The link does not grant broad access to the supplier’s tenant data.

Internal approval

The supplier organization’s review of a submitted member week. Current configuration can enable the workflow, decide which members require it, and assign one or more eligible approvers.

Client review

A linked client organization’s decision on the portion of approved work relevant to it. Reviewers can approve or dispute according to explicit supplier-workspace assignments.

Sales invoice

An invoice created and managed by the supplier organization from approved, eligible time or manual lines.

Received invoice

The client-side view of an issued supplier invoice, available only to configured invoice viewers in the linked client organization.

Distribution and documentation

Source layer

A host-owned feature layer referenced through localPortalLayer(). It uses the same manifest and provider model as official packages while remaining in the consuming application.

Remote layer

A Nuxt layer loaded from a pinned Git source through extends. Nuxt supports the mechanism; the layer author owns package compatibility, manifest resolution, and migration integration.

Packaged layer

A separately versioned Nuxt layer published to a package registry and loaded through extends. Official packages share an alpha version and expose explicit package entry points.

Disable

Stop composing a layer so its pages, APIs, contributions, and translations disappear while its stored data remains. Disabling code is intentionally separate from deleting data.

Remove

Permanently delete layer code and, only after an explicit retention decision, apply a reviewed migration that removes its database objects.

Source pin

The immutable Customer Portal commit against which a documentation version was checked. Every rendered page, documentation report, and MCP discovery response carries the same pin.

Compatibility baseline

The exact Customer Portal revision, runtime, database expectation, and layer version proven together by tests. A moving branch or the word latest is not a reproducible baseline.

Continue with the feature contract reference for exact fields or use the source map to open their current implementations.