55 — Workspace tenancy & one person, many hats (envisioning)

Envisioning doc. Governed by 00-ROADMAP.md — defer to it on any conflict. Created 2026-07-04 (owner-raised, doc-54 greenlight round): "workspace needs to be considered as a tenant, so it doesn't directly talk with another one (yes for migrations/move…) but also… a user can have the same user but different workspace as an artist, as a producer, as a booking manager… somehow needs to allow a type of sub-user or subaccount or something for contact consideration and cross reference."Builds on: 47-PRODUCT-NORTH-STAR.md §10.4 (Workspace tenant root — confirmed, designed with doc-43/44) · 21-DATA-ARCHITECTURE-AND-IDENTITY.md (ownership ladder) · 44-RBAC-TEAMS-PERMISSIONS.md (Grant = principal · role · scope) · 53-CONTACTID-RELEASE.md (one card, lensed visibility) · 48-CONFIG-ACROSS-HIERARCHY.md (the interim per-owner Workspace doc that this grows out of). Envisioning altitude — shapes and rules, not schemas.

---

1. The tenancy rule

A Workspace is a tenant. It is the boundary of catalog, configuration (doc-48 cascade root), teams (doc-44), attributes (doc-43), billing (doc-31) — and tenants do not talk to each other directly. No cross-tenant reads, no cross-tenant queries, no accidental bleed.

Sanctioned crossings — exactly three:

1. Migration / move — explicit, owner-initiated: export/import, ownership transfer, moving a subtree (artist → another workspace). Files ride the node (doc-45's invariant), so a move carries the asset cloud; the storage re-key constraint noted there applies here too.
2. The person layer — everything doc-52/53 build lives above tenants: Contact ID, the contacts graph, messaging, Discovery/Events relate persons, not workspaces. Two people in different tenants meet in person-space (a card exchange, an event, a thread) without their catalogs ever touching.
3. Links & guests — doc-26/44 Link/guest principals remain the per-resource crossing: a share link grants exactly one scope into a tenant, nothing more.

This split is what makes "many ways of working" safe: studios get hard isolation; the industry graph (the club, doc-53) still connects everyone.

2. One person, many hats — the options

The owner's case: the same human is an artist in workspace X, a producer in workspace Y, a booking manager in workspace Z — and contacts/cross-references must make sense of that.

Option	Shape	Verdict
A. Separate accounts per role	One login per hat	Rejected — splits the identity and the graph (three cards for one human), password hell, kills the doc-53 "one handshake" vision
B. Sub-accounts ("sub-user") under one login	Switchable child profiles, each a distinct principal	Not recommended — heavy model (principal explosion in doc-44), fragments Contact ID (which of your cards is you?), and everything it buys is achievable with C
C. One identity + workspace memberships with persona facets	One User, one Contact ID; per-workspace membership carries a facet	Recommended — see §3

3. The recommended model — memberships with facets

• One User, one Contact ID. The human is one node in the person layer, always.
• WorkspaceMembership = (user, workspace, role, facets[]) — the doc-44 grant (principal · role · scope=Workspace) plus persona facets (plural — §6 Q2, owner 2026-07-04): artist · producer · booking manager · engineer · … (facet catalog rides doc-43 presets — extendable, never demanded, principle 8). Facets default private on the card (§6 Q1).
• The Contact ID wears the hats: the card can show "Producer at ⟨Y⟩ · Artist at ⟨X⟩" — each hat a facet with its own visibility lens (doc-53 §3.2's per-field opt-in extends naturally to per-facet: me · my contacts · everyone). A hat in a workspace the owner keeps private simply doesn't render.
• Per-context display identity is already precedent (INV-15: Apple lets you change name/photo per invitation reply): a membership MAY carry its own display name/avatar for that workspace's rosters — identity presented ≠ identity stored, owner-controlled.
• Cross-reference semantics: contacts relate persons; provenance ("worked on ⟨project⟩", "met at ⟨event⟩", "hosting") may reference tenant content only through what both sides' lenses allow. The graph never becomes a side-channel into a tenant's catalog.

Why this is the "sub-account" the owner sensed, without the cost: the facet gives the separation of presentation (different hat, different face, different visibility per workspace) while keeping one principal, one graph, one card — the thing sub-accounts would have broken.

4. Consequences for the model (when built)

• The Workspace container (doc-47 §10.4, interim per-owner doc from doc-48) becomes the real tenant root: Workspace + WorkspaceMembership (above). Doc-44's resolver already computes from grants — membership is just the workspace-scope grant, enriched with facet.
• doc-21's ownership ladder gains the explicit tenant rung; "your data lives in your workspaces, your identity lives with you."
• Billing stays per-workspace (doc-31) — hats are free; tenants pay.
• Migration/move = subtree move + grant rewrite + asset re-key (doc-45) — its own later pass.

5. Non-goals (v1)

• No orgs-of-orgs / nested tenants.
• No cross-tenant search or aggregate views (mgmt.ctrl stays within a tenant; the person layer is not a query engine over tenants).
• No facet-level permissions — the role (doc-44) governs access; the facet governs presentation.
• No sub-account principals.

6. Open questions — ALL RESOLVED (owner, 2026-07-04)

1. Default facet visibility on the card: hats visible to contacts by default, or owner-private until opted in (doc-53 §3.1 zero-state says private — confirm it feels right for hats too)?

   Resolved: private by default — a hat renders on the card only after the owner opts it in, consistent with the doc-53 zero-state.

2. Multiple facets in the same workspace (artist and engineer at your own studio) — allow from day one, or one facet per membership v1?

   Resolved: yes, allowed. Concretely: one membership carries facets[] (plural), not a single value — e.g. you're both the artist and the mixing engineer at your own studio: one membership, one role (doc-44 access), two hats (presentation). No second membership, no second principal.

3. Guest → member upgrade path: when a link-guest (doc-26) joins a workspace, their person-layer history (comments as guest) attaches to the membership?

   Resolved: yes — the relation carries over. The guest's history (comments, plays, RSVPs) belongs to the person; joining just upgrades the grant, it never orphans or duplicates the trail (doc-41 audit continuity).

4. Workspace switcher placement: the reserved Home top-left corner (doc-54 §8.2 explicitly held it for this) vs inside the Contact tab. Lean: top-left, when multi-workspace ships — exactly what the corner was reserved for.

   Resolved: the Home top-left corner — confirmed as the workspace switcher's future home, exactly what doc-54 §8.2 reserved it for.