Glossary

Look up terms while reading a task guide or API contract. Scope, population, ownership, and membership describe different facts; use the authorization example below to distinguish them. This page defines vocabulary rather than adding setup prerequisites.

How to read this glossary

Terms are grouped by the confusion they cause, not alphabetically. Each entry states what the term is and — where it matters more — what it is not.

The durable vocabulary owner is docs/doctrine/02-TERMS.md. Where a term names something that does not run yet, this page says so.

When a definition and the code disagree, the enum wins. These four are the authoritative value sets behind the terms below:

Nexia\Permission\AssignmentScope;   // tenant, legal_entity, operating_unit
Nexia\Permission\SubjectPopulation; // all, self, direct_reports, legal_entity, operating_unit
Nexia\Permission\GrantControl;      // standard, protected
Nexia\AppDescriptors\DescriptorStatus; // active, deprecated, removed1234

Minimal example

Read an authorization statement as four different terms:

Permission: workshop.note.update
Role: Workshop editor
Data scope: one Legal Entity
Subject population: all1234

The Permission names the action, the Role bundles it, and the Access Grant adds scope and population. None of those is authentication or organization membership.

Platform and ownership

Platform versus Core. Two names for one thing, aimed at two audiences: platform in prose, Core in code. The app/Platform/ directory predates the vocabulary and is service operations, not the Platform meant here.

App versus App Package. The App is the capability; the Package is how it ships. app_key identifies both and never changes.

Workspace and package resolution

These terms describe different stages of getting source code into a running tenant. They are not synonyms, and they describe current development mechanics rather than durable doctrine vocabulary.

Name repository actions directly: clone a repository, switch a branch, or restore a file. Likewise, selection by itself remains an ordinary choice; use the full phrase local package selection for the persisted package-key list.

Work execution and orchestration

Nexia Business Process uses the OMG BPMN and DMN vocabulary and references Camunda 8's authoring and orchestration model, but owns its execution state and nexia:* extensions. Workflow does not name a currently documented product area; it is reserved for a future durable-workflow runtime so it stays distinct from Business Process.

Organization structure

Everything in this group models real structure. None of it grants authority.

The rule for the whole group: participation is not permission. Membership makes something selectable. Acting on its records takes an Access Grant.

Authorization

The four parts that compose one decision:

Permission versus Role versus Grant. The Permission says what; the Role bundles which; the Grant says where and whose. Your App declares only its own Permissions — Core declares the platform's.

A Permission names capability, not scope. workshop.note.update says nothing about which defect codes.

Extension patterns

The five that look alike. The discriminator is who owns the result:

Catalog versus master data. That quality.defect_code exists is a catalog. The defect codes a factory uses are master data.

Template versus Catalog. Ship a fix to a catalog and every tenant gets it. Ship a fix to a template and existing copies are untouched.

Shell and frontend

Slot Widget versus Dashboard widget. A slot widget fills a fixed point a host surface publishes. A dashboard widget is placed by a tenant on a Dashboard.

selected/active versus focused. Durable current state versus the transient keyboard or pointer candidate.

Lifecycle

An applicable Access Grant provides standing authority. Discovery and installation make capabilities available; they do not grant permission.

Documentation and design

Named in doctrine, not implemented

Do not design around these. They are deferred, not abandoned:

When doctrine names a value an enum does not have, the enum is what runs.

Errors

Real usage

packages/assets/src/Contribution/Resources/AssetModule.php keeps capability and scope as separate declarations:

public static function permissionAssignmentScope(): AssignmentScope
{
    return AssignmentScope::LegalEntity;
}

public static function permissionResources(): array
{
    return ['assets.asset' => ['read', 'register', 'update_identity', 'validate', 'import', 'retire', 'export', 'audit']];
}123456789

The source demonstrates the glossary distinction: Permission names actions; AssignmentScope names where a grant may apply.

Related

• Tenant and context — the isolation terms in depth
• Permissions and roles — the four-part authorization model
• Extension Model — choosing between the five patterns
• Shell layout regions — the region and surface terms in depth