Access Without Pretending the Launcher Owns Everything

A request is not yet access

Clicking an access request should not make an application card pretend the job is done. Polinaria Home can collect the request and record policy, but its database is not proof of access elsewhere. A card becomes available only after the identity control plane confirms the baseline entitlement.

Keep the launcher deliberately narrow

That separation prevents the friendly launcher from becoming an accidental source of excessive authority. Home sends a narrowly scoped application-and-action request. The identity service resolves the private role mapping, while the destination application still decides what the signed-in person may do within its own boundary. Catalog data shown to ordinary users omits privileged project and role identifiers.

Who decides what

Home coordinates the request. Identity confirms the entitlement. The destination still owns its in-product decisions.

flowchart TD
    Home[Home access request] --> Identity[Identity control plane]
    Identity --> Confirm[Confirmed baseline entitlement]
    Confirm --> Card[Home marks app available]
    Card --> App[Application checks local permissions]

Fail honestly at authority boundaries

The integration is designed to fail honestly. Before changing identity or access, Home verifies a versioned capability contract and correlates the request across the boundary. Missing, partial, mismatched, denied, or timed-out capabilities do not become optimistic success. They remain visible as retryable or incompatible states, preserving the difference between “we intended to grant access” and “the other system confirmed it.”

Administrative changes also leave an append-only trail, and consequential actions require explicit confirmation. This design gives Home a useful human role—welcome people, explain what exists, and coordinate access—without collapsing identity, authorization, application policy, and user experience into one unreviewable service.