Experiences

A workspace is a whole working environment, not a folder, and the console over it is wide, because the platform is. Rather than show every capability to everyone, or split the product into separate applications with separate bills, the console projects one flat set of capability tabs through a chosen experience. Pick "Data Analyst" and the console foregrounds semantic models, dashboards, and data products; pick "Security" and it foregrounds detections, posture, and the SIEM. The workspace underneath does not change, only the view onto it does.

This is a real product concept in the code, not a marketing device. It is one of the better answers to "isn't a platform this broad overwhelming?", and it is safe because of a single invariant covered below: gate, don't omit.

The six experiences

The console projects its tabs through one of six experiences. Each is a first-class, ordered entry in the experience registry (frontend/src/features/workspace/experiences.ts), keyed by a stable string id:

#	Experience	What it foregrounds
1	Data Engineering	Data, catalog bindings, data modeling, ontology, sources, pipelines, notebooks, the SQL editor, compute, capacity, automations, edge sources, logs, health & drift, data products, and storage
2	Data Analyst	Semantic and ontology models, the SQL editor, dashboards, dimensional design, and data products
3	Data Science	Models, notebooks, ML, cognition, the AI manifold, the workspace mind, knowledge, agents & skills, and health & drift
4	Software Engineering	Notebooks, the SQL editor, agents & skills, coding, repositories, CI/CD, compute, automations, and logs
5	Consulting	The engagement surface: client estate assessment, findings, and deliverables (see Consulting)
6	Security	Detections, SOAR, threat intel, forensics, posture, the SIEM, UEBA & DLP, deception, red/purple team, threat detection, cyber operations, battlefield operations, surveillance, and spectrum operations

The projection is driven by data, not by branching code: every tab in the registry declares which experience(s) it belongs to (experiences: ExperienceId[]), and the switcher filters by that field.

Governance tabs are always on

Ten tabs carry the sentinel ALWAYS_ON ("*") instead of a role list, so they appear in every experience, governance and identity never disappear because someone switched persona:

Overview · Catalog & Lineage · Advisor · External agents · Activity · Feed · Members & Access · Lifecycle · Residency · Settings.

These are not decorative. Members & Access is the authorization surface, Lifecycle and Residency are the portability and data-residency controls, Catalog & Lineage is the provenance record, and Activity is the tamper-evident audit view. A persona switch can never take them off screen.

The mechanism is the stable fact, not the tab count

The registry holds several dozen capability tabs, ten of them always-on. Tabs are added as capabilities ship, so any exact total goes out of date faster than this page does. What stays true is the projection: an experience selects a subset, the always-on ten are in every subset, and a tab the caller's capabilities do not reach is gated rather than quietly dropped.

How the projection actually works

A tab is shown when it is in the active experience (or the user has pinned it) and its backing capability is enabled. Three gates compose, in order:

Figure R1: the projection is a filter over one registry, not a set of separate apps. A tab renders only when its capability is enabled (the backend Capability Control gate) and it is either in the active experience, carries ALWAYS_ON, or is pinned by the user. The governance tabs (green) survive every role switch; the disabled path (red) is the same gate for everyone. The registry is a single flat list, the "apps" are views over it.

Table equivalent

Gate	Where it lives	Rule	Effect when it fails
Capability	A backend Capability Control capability per tab, for example the Discovery & Mapping governance assessment	Is this capability enabled for this workspace?	Tab is not rendered at all
Experience projection	experiences.ts · tabInExperience()	ALWAYS_ON, or active experience ∈ the tab's experiences[]	Tab is hidden from this role's view (still reachable via pin / another role)
Pin	Per-user, best-effort local state	User pinned this tab id	Shown in a leading "Pinned" group even outside the active role

When no experience is selected, projection is bypassed entirely and the console falls back to the legacy full navigation: every capability-enabled tab, ungrouped by role. The experience switcher itself only renders when more than one experience is actually available, an experience with no enabled, non-always-on tab of its own is not offered.

Gate, don't omit: the invariant

The property that makes all of this safe: the union of every experience's tabs, plus the always-on set, equals the full flat tab set. Organizing the console can never make a capability unreachable, a tab hidden from one role is always reachable from another role, from a pin, or from the legacy full nav. Nothing is deleted by a persona; it is only foregrounded or backgrounded.

This is enforced by a test, not by convention (experiences.test.ts and WorkspaceConsoleNav.test.tsx). That is the difference between a navigation convenience and a governance guarantee: a future tab that belongs to no experience and is not always-on would fail the test rather than silently vanish from the product.

Frontend and backend: the same tab, two halves

The experience is a frontend projection; what a tab does is backend capability. They meet at the capability id each tab carries.

• Frontend (the projection). experiences.ts holds the registry of six experiences and the tabInExperience() predicate; WorkspaceConsoleNav.tsx holds the 56-tab registry and workspaceConsoleSections(), which runs the three gates above; useWorkspaceExperience.ts tracks the active experience and computes which experiences are even offered; WorkspaceExperienceSwitcher.tsx is the rail.
• Backend (what the tab reaches). Each tab names a Capability Control capability (for example the Consulting tab's governance-assessment capability) and a workstream. The capability gate is the authoritative control, the projection only decides foreground vs. background, while the capability decides reachable at all. This is why "gate, don't omit" is honest: hiding a tab in a role view is cosmetic; the real boundary is the backend capability plus the workspace identity and authorization that every tab's service enforces on each call.

So an analyst who pins the Security posture tab still only sees what the posture capability and their grants permit, the pin changed the rail, not the policy.

The same model in a clean room

A clean room is the workspace experience "only CLEAN": its console is built from the same tab registry, not a fork (frontend/src/features/cleanroom/cleanroomConsoleNav.ts calls the identical workspaceConsoleSections() with a /cleanroom/{roomId} base path). Role experiences project exactly as they do in a workspace.

On top of that shared projection, the clean room appends six room-governance tabs that are always on because they are the room's guarantees:

Parties · Privacy budget · Egress & DLP · Graph governance · Runs · Audit.

A persona switch can never hide the room's isolation controls, the same "gate, don't omit" property, extended to the guardrails that make mutual-distrust collaboration safe. An experience with no tab of its own in a room (Consulting, for instance) is simply not offered in that room's switcher, so the switcher only ever offers reachable views.

Your chosen experience does not follow you between machines

The projection, the capability gating, the pinned-tab handling, the clean-room reuse, and the "gate, don't omit" test are all real, shipping, tested code. The one placeholder: the active experience is remembered per-workspace in browser-local state only (workbench.experience.{workspaceId}), a cross-device backend sync is explicitly recorded as owed follow-up, not built. Your chosen role does not yet follow you to another machine.

The edge operator experience

The six-experience tabbed console is a cell (core) surface. It is the React workspace console served by a full cell. The edge is a different shape of deployment, so the edge operator experience is not the tabbed persona console:

• The Edge Agent operator works a command-and-agent surface, the edge command reference not a browser rail of several dozen tabs. A field device proves who it is, reports what it sees, and executes what it is told.
• The governance is the same model, enforced at the edge. The capability gate, the workspace identity and delegation, and the classification ceiling that bound what a tab may do on the core are the same controls the Edge Agent applies locally and offline. "Gate, don't omit" holds because the gate, capability plus identity plus classification, travels; only the rail is a cell-side convenience.
• Where a cell is deployed at the edge site (a sovereign, air-gapped stack at the device), it serves that same console locally, so the persona projection is available on-device with no cloud in the loop, the console is a property of the cell, and a cell can run at the edge.

The takeaway: the experience is how a person reads one governed workspace; the edge changes the surface the operator touches, never the governance behind it.

Related topics

• The workspace and clean-room boundaries the console projects over: The two work boundaries.
• The Consulting experience in full, the estate assessment behind that one tab: Consulting.
• One product, two runtimes, and why the edge is not a degraded client: Core and edge.
• The identity and authorization every tab's backend enforces: Security · Identity.