CoreUI

CoreUI is the native workspace interface for CoreCube knowledge. It is different from third-party chat frontends such as OpenWebUI because it uses CoreCube's native product API instead of the OpenAI-compatible chat API.

The enterprise rule is simple: CoreUI authenticates and presents the workspace; CoreCube authorizes knowledge access. CoreUI should never become the authority for what evidence a user may retrieve.

Production Identity And Authorization

In production, a CoreUI user is verified through the shared Foundation or identity provider. CoreUI then obtains a short-lived token for the CoreCube audience and calls CoreCube on behalf of that user. CoreCube validates the token, resolves the user internally, evaluates direct and group-derived scope assignments, and applies compartment and sensitivity rules before retrieval.

Authorization Chain

1. The user signs in to CoreUI through the production identity layer.
2. CoreUI resolves the authenticated user and current session.
3. CoreUI exchanges that identity for a short-lived CoreCube audience token.
4. CoreUI calls GET /v1/coreui/context to get the user's available compartments, sensitivity ceilings, defaults, and permissions.
5. CoreUI uses that context to present valid workspace choices.
6. The user selects a scope, compartment, and sensitivity ceiling for a turn.
7. CoreUI sends the requested scope with POST /v1/coreui/responses.
8. CoreCube validates the token subject and resolves the matching CoreCube user.
9. CoreCube unions the user's direct scope assignments with group-derived scope assignments.
10. CoreCube rejects unavailable scopes, compartments, or sensitivity ceilings.
11. CoreCube retrieves only evidence allowed by the effective scope.
12. CoreCube returns the answer, citations, policy state, and audit metadata for CoreUI to render.

Product Boundaries

Responsibility	Owner
User workspace, conversations, selected scope, evidence rendering, and check-in UI	CoreUI
Token validation, CoreCube user resolution, direct scope assignments, group-derived scope assignments, compartments, sensitivity, retrieval filtering, and citation authority	CoreCube
Login, session authority, audience-token exchange, and shared identity policy	Foundation / identity provider

CoreUI can constrain the UI with the context CoreCube returns, but CoreCube must still re-check every request. This fail-closed pattern matters because a stale browser tab, modified request, or old conversation scope must not bypass current CoreCube policy.

Local Development

Local development can use a static setup token to bootstrap and test the CoreUI/CoreCube connection. That setup is useful for local Docker Compose and developer machines, but it is not the production trust model.

Production deployments should use short-lived, audience-scoped CoreCube tokens issued by the shared identity layer. The token should identify the acting user, the CoreCube audience, the calling product, the workspace or session context, the correlation ID, and an expiry.

Related Setup

For URL, port, Docker Compose, and reverse-proxy patterns, see CoreUI API connection topologies.