Application

What It Models

The console presents application access through two related answers. The personal list controls application sections and page entry. The administrative overview explains workspace availability and licence dates. Both depend on Platform, but they have different audiences and refresh paths.

Identity and Attributes

A stable application key connects the personal context to console domains. The overview adds name, availability, licensing and operational details. Features accompany the personal list without enabling domains themselves. Freshness uses a provider timestamp initialized on mount and updated by successful application-refresh responses.

Relationships

Applications enable menu sections and classify page paths. The shell retains the personal list for its selected context. Security computes that list, while Operations owns the licensing and operational records. The administrative service reads those records directly rather than reading client memory.

Invariants

The structured invariants cover entitlement-derived sections, application-first page refusal and workspace-safe refresh. Staff wildcard permissions add no application. Administrative responses omit staff-only and commercial details. Refresh replaces applications and features while leaving the remaining context intact.

How It Is Stored and Shared

The console view exists in memory and has no physical tables or metadata registration. Operations stores its own application registry and workspace application state. Security provides the personal context and refresh read; the administrative operation provides the separate overview.

Open Design Questions

The overview parser treats every availability value except explicit false as available. Renewal-warning placement and the scope of returning-tab refresh remain product decisions. A successful but superseded refresh also advances the timestamp, which can postpone the next focus refresh.