47 — Product North Star — three zones, one navigation grammar (consolidation)

Consolidation / north-star doc. Governed by 00-ROADMAP.md — defer to it on any conflict. Created 2026-06-28 (owner-raised: "consolidate the ideas… the whole project, the actors and actions… a hub, a kind of settings, a kind of x-ray view… minimum taps, clear intent from the first second"). This doc does not introduce new product capability — it unifies what the numbered docs already decided into one coherent map so future slices have a home to slot into, and we build aligned instead of bolting surfaces on.

Two decisions locked with the owner (2026-06-28):

1. Navigation model = three zones + fractal Portals — Browse (catalog) · Manage (x-ray) · Configure (control room), with one Portal grammar at every altitude (roster → artist → project → track → file all share the same detail + status + actions shell; roster finally gets its Portal).
2. Vehicle = this north-star doc first — align on paper, then build. No code this pass.

All §10 forks now resolved (owner, 2026-06-28) — see §10: zone switcher = tab bar · front door = sibling (not merged) · account = its own corner (bigger "Contact ID" identity phase deferred) · Workspace tenant root confirmed (designed with doc-43/44) · MVP = front door + Browse loop now, Configure as a thin shell (workflow templates first), with Contact ID / attributes / teams-UI / Workspace as named later phases. The model is settled; what remains is building it iOS-first (§11). Owner is sitting with the framing before the first slice.

---

1. Why this doc exists (the tension the owner named)

Today the app runs on two navigation philosophies bolted together, with no layer reconciling them:

• Portals = bottom-up, object-first. Artist / Project / Track detail sheets. You navigate by drilling the tree. Excellent for "I'm looking at this one thing." Roster — the top level — has no Portal yet.
• Manage = top-down, status-first. The mgmt.ctrl eagle-view (doc-42) + analytics (doc-38). Bolted on as a tab.

What's missing is the layer above both: a front door that conveys intent, identity, and capability in the first second — "what is this, who am I here, what can I do, where do I go." You currently land inside the tree and reconstruct the whole from the parts. That is the "too many taps, intent unclear from second one" feeling.

And the deep substrate built over the last weeks — workflow engine (doc-46), configurable attributes (doc-43), teams & permissions (doc-44) — has no surface at all. It is exactly the stuff a control room exposes, and there is no control room.

2. Sonnance in one paragraph

Sonnance is the collaboration OS for music professionals — solo creators, studios, labels, and their collaborators — built around one core loop: upload a recording → review it in context → approve/release it, with everything that orbits that loop (versions, comments/notes, sharing, roles, release readiness, listening insight). It is professional-calm, craft-reverent, B2B-centered (doc-31), iOS-first (doc-19/20), and one app, one dashboard, role-driven — not a different app per actor (doc-20). The north star: collaboration OS → creator business hub (doc-31).

3. The actors

Two orthogonal axes — keep them separate (doc-44 §two-role-axes):

A. Access role — per resource, cascading (the only axis the schema enforces today; src/modules/collaboration/models/role.dto.ts, cascade ArtistSpace → Project → Track):

Role	Can	Note
Owner	everything incl. delete, release	the creator/account holder for that resource
Admin	manage team, approve, configure	trusted operator (studio/label)
Editor	upload, edit, comment, set lighter metadata	the working collaborator
Viewer	view, comment	reviewer / client / featured artist

A user is not "an Owner" globally — they are Owner of their own things and possibly Viewer of someone else's. Role is a property of the (user, resource) edge, not the user (doc-44 §Q6).

B. Business persona — who someone is, what they come for (doc-12/17/31). Drives emphasis, never forks the app:

Persona	Comes for	Primary zone
Solo creative pro	make → review → release my work; the adoption engine	Browse
Studio / label manager	oversee a roster, keep many releases moving	Manage
A&R / exec	data-driven decisions across the catalog, eagle-view	Manage
Collaborator (editor/viewer)	do my part, give feedback, approve my slice	Browse
Guest / fan (future, post-MVP)	hear a shared clip; coarse, link-attributed	a single shared surface (doc-38/39)

4. Actors × actions (what we expect people to do)

The action set the product must serve, mapped to the persona who reaches for it most (■ primary · □ also). Every action already has a backend home — this matrix is for alignment + placement, not new work.

Action	Solo pro	Studio mgr	A&R/exec	Collaborator	Lives in
Create artist/project/track	■	■	□	□	Browse
Upload version	■	□		■	Browse (Track)
Review & approve (the loop)	■	■	□	■	Browse (Track/Project)
Comment / note	■	□	□	■	Browse (any node)
Share (link / collaborator)	■	■	□	□	Browse (Portal)
Navigate / find / x-ray	□	■	■	□	Manage
Bulk act across catalog		■	■		Manage (doc-42)
Configure workflow / readiness	□	■	□		Configure (doc-46)
Define attributes (LEGO)	□	■	□		Configure (doc-43)
Manage teams / roles / permissions	■	■	□		Configure (doc-44)
See listening insight	□	■	■	□	Manage (doc-38)
Account / identity / billing	■	■	■	■	Configure (account)

The matrix surfaces the gap immediately: the entire right-hand cluster (Configure) has no zone today.

5. The three zones (the "three faces" made concrete)

The owner sensed three things — hub · settings · x-ray. They are three zones over the shared object model:

Zone	The question it answers	Direction	What lives here	Feeds from
Browse	"Let me work on / look at this thing."	bottom-up, object-first	the catalog + fractal Portals (roster → artist → project → track → file), the review & approve loop, comments/notes, sharing	doc-23/25/26/29/32/33/36/46-iOS
Manage	"What's the state of everything, across actors?"	top-down, status-first	mgmt.ctrl eagle-view: activity timeline, approvals queue, catalog matrix, release board, bulk write, engagement insight	doc-42 / doc-38 / doc-40
Configure	"How does my studio/workflow/team work?"	the substrate	workflow templates (doc-46), attribute catalogs (doc-43), teams · roles · permissions (doc-44), workspace defaults, account/identity	doc-43 / doc-44 / doc-46 / doc-41

The front door ("what needs me") is not a fourth zone — it is the role-driven landing of the app (doc-37 Home), the orientation skin over the three zones. Open question §10 decides whether it merges with Manage or stays a sibling.

6. The locked navigation model — one grammar at every altitude

The unifying idea that makes three zones feel like one product:

Portal-as-fractal. Every node in the hierarchy — roster, artist, project, track, file — is opened as a Portal with the same shell: identity header · status/readiness · metadata · actions · related items · provenance (doc-36). The only differences are which sections fill in. This is already true for Artist/Project/Track; the model says: make it literal and complete — roster gets its Portal (doc-36 flagged this), and the shell is consistent enough that learning one teaches all.

• Browse = navigating down the fractal (drill the tree).
• Manage = the same grammar inverted — a top-down synthesis across many Portals at once (doc-42 is literally "the Portals' top-down synthesis").
• Configure = the control room that defines what the Portals contain and enforce (attributes they carry, workflow they run, who can do what).

One grammar → minimum new things to learn → "clear intent from the first second" scales as the product grows, because every altitude behaves like the one above it.

7. Design principles (the spine for every future call)

1. Intent-first, not object-first. Lead with "what do you want / what needs you," not "here is a tree." The front door states intent; the tree is reachable, not imposed.
2. One grammar at every altitude. The fractal Portal (§6). New altitude ⇒ same shell, not a new screen language.
3. Progressive disclosure — calm by default, density on demand. Phone = calm stacked cards; wide = dense matrix (doc-42). Higher altitude shows less, louder — digest, not firehose (doc-31/33/38).
4. Configuration is a place, not scattered toggles. The Configure zone is a real destination — the control room — not settings sprinkled into each Portal.
5. One surface, role-driven content. Never fork the app per persona; gate content/affordances by the per-resource role (doc-20/44). Personas change emphasis, not architecture.
6. Minimum taps, obvious next action. Every surface answers "what's the one thing to do here" before it offers ten. Default calm; power on demand.
7. Start almost empty. The minimum that provides basic/common value as a starting point — grow as you work. Surfaces, portals, catalogs, and configuration begin at the preset minimum; empty structure never renders — content appears when it exists, affordances offer what could exist. (Locked by doc-54, 2026-07-04.)
8. Many ways of working. Structure is offered, never demanded. Lenses, templates, saved views, and optional attributes serve the lazy solo artist and the multinational A&R team alike; the product never requires configuration before delivering value. (Locked by doc-54, 2026-07-04.)

8. Reconciliation map (every prior doc → its zone)

This doc invents nothing; it places what exists. On any conflict, 00-ROADMAP wins.

Zone / layer	Docs that live here
Front door (role-driven landing)	37 (Home triage), 20 (one dashboard, role-driven)
Browse (fractal Portals + the loop)	23 (IA), 25 (CRUD), 26 (identity/sharing/lenses), 29 (version approval), 32 (approval-as-dimension), 33 (notes), 36 (interaction/peek-then-go, Roster Portal), 28 (variant chips), 30 (playback), 39 (sample sharing), 34 (image delivery), 45 (release assets)
Manage (x-ray / eagle)	42 (mgmt.ctrl), 38 (analytics engine), 40 (sort/filter/search), 35 (realtime)
Configure (control room)	46 (workflow templates), 43 (attributes / LEGO), 44 (teams/roles/permissions), 41 (records: audit/state/status), account/identity
Cross-cutting foundation	21 (data/identity), 22 (design system), 31 (product vision/brand), 44 (authz), 41 (records)
Origin / reference	12 / 17 (actors + "Lego OS" + the original /manage — revived by 42/43; this doc is their modern synthesis)

9. What actually changes vs today (it's small, on purpose)

This is a reframing, not a rewrite. Most of it already exists.

• Exists: Browse (Portals for Artist/Project/Track + the review loop) · Manage (mgmt.ctrl + analytics, backend live) · the per-resource role model (doc-44 backend).
• Net-new surfaces this model calls for (sequenced post-doc, iOS-first):
  1. The three-zone shell — a clear, low-tap way to switch Browse / Manage / Configure (zone switcher; §10 decides the mechanism).
  2. The Configure zone — the missing control room: surfaces doc-46 templates, doc-43 attributes, doc-44 teams/roles, account. This is the real gap.
  3. The Roster Portal — completes the fractal (doc-36 already flagged it).
  4. The front door polish — doc-37 Home as the role-driven landing that orients in one second.

10. Resolved decisions (owner, 2026-06-28)

All five §10 forks are now decided — the model has converged:

1. Zone switcher = tab bar. Browse / Manage / Configure as tabs (+ the front door) — fewest taps, always visible. Not a hub-landing or a promoted drawer.
2. Front door = sibling, not merged. The "what needs me" landing (doc-37) stays a sibling above the three zones — it answers a different question ("needs me") than Manage ("state of everything"). So the iOS shell is: a role-driven landing → into Browse / Manage / Configure.

   Updated by [doc-50] (2026-06-29): the center of gravity is now action-first — Home is promoted from sibling to protagonist (the default gravity well: what-needs-you + a light cross-catalog work-board, doc-46). Browse/Portals (doc-49) become the substrate you land on when you act, not the daily entry. The three-zone tab shell stays; Home just leads.

3. Account/identity = its own corner, not inside Configure. A conventional profile corner. Bigger phase flagged: "Contact ID" — a richer identity layer (the owner's larger identity vision) — deferred, tackled in its own pass. Configure stays workspace configuration (workflow/attributes/teams), kept distinct from personal account.

   Updated by [doc-53] (2026-07-03): that deferred "Contact ID" identity phase is now elevated to a Release headline feature (stakeholder-confirmed) — spec in 53-CONTACTID-RELEASE.md. Account = own corner stands; Contact ID is that corner grown into a surface. Updated by doc-54 (2026-07-04): the "own corner" is realized as a real 5th tab — the Contact tab (extreme right; naming open, owner to pick): Contact ID + account/user config + the Discovery entry (top-right of the view). Absorbs the AppMenuDrawer avatar sheet.

4. Workspace becomes a first-class container — confirmed. A real Workspace tenant root above ArtistSpace (which is the de-facto tenant today). Configure operates per-Workspace. The actual model + migration is designed with doc-43/44 (they both already want this root); doc-47 just locks the intent.
5. MVP subset = ship the loop now, keep the future phases honest. First slices = front door + Browse (the Review & Approve loop, the live MVP) · Manage as already built · Configure as a thin shell (workflow template authoring first — doc-46's named next step). Attributes (doc-43), full teams/roles UI (doc-44), the Workspace container, and Contact ID are explicit later phases, not dropped — the architecture has slots for them from day one.

Net: the north-star is settled. What remains is building it, iOS-first, in the §11 order — when the owner is ready (they're sitting with the framing first).

11. Sequencing

This doc is alignment, not a build. The model is settled (§10); slices land iOS-first and incrementally, each slotting into a zone:

1. Confirm the model + §10 forks ✅ done 2026-06-28 (this doc).
2. Tab-bar shell + front door ✅ BUILT 2026-06-28 (xcodebuild green) — signed-in root = a 4-tab TabView (Home / Browse / Manage / Configure), Home = the role-driven sibling landing (doc-37). Shared browseDestinations modifier gives every zone the same drill grammar (§6); Configure ships as an honest thin shell (Teams live, rest Soon). Additive — Home left intact.
   • slice 1b — declutter + cross-tab routing ✅ BUILT 2026-06-28 (xcodebuild green) — Home trimmed to the front door (quick-tile launcher removed; drawer reduced to account corner + Shared/ Recents overflow). New AppRouter (observable, owns zone + Browse path) enables switch-tab + deep-link in one gesture; first use = create-artist hops to Browse and opens the new artist. See CHANGELOG.
3. Configure zone shell — ✅ shell BUILT (slice 1) · ✅ workflow template authoring BUILT 2026-06-28 (xcodebuild green) — Configure ▸ Workflow lists templates (default + mine), creates from the default, and edits (rename · required toggles · add/delete custom steps · save · delete · duplicate) over /workflow/templates CRUD; first Configure citizen live. Next citizens: teams/roles (doc-44), then attributes (doc-43, premium). Follow-up: instantiate-a-template picker on the project (pairs the authoring with the doc-46 Project-Portal pipeline).
4. Roster Portal — complete the fractal (doc-36).
5. Web parity — bring the web app to the same three-zone model after iOS (doc-20).

Named later phases (slots reserved, not built now): the Workspace tenant root (with doc-43/44) · "Contact ID" — the richer personal-identity layer in its own corner → elevated to Release headline 2026-07-03, specified in 53-CONTACTID-RELEASE.md · Discovery / Events — the second Release headline feature → 52-DISCOVERY-EVENTS.md · full attributes (doc-43) + teams/roles UI (doc-44).

Nothing here reorders the MVP (the Review & Approve loop stays first, doc-19); it gives that loop a coherent home and a place for everything that follows.

Field feedback — Home / front door (owner, 2026-06-28, to plan before building)

After living with the new tab shell, the owner flagged that Home isn't always the right landing:

• The front door currently leads with pending approvals + open notes — but when actively working inside an artist/project, that digest isn't what's wanted; the user had to switch to a specific tab to get back to their work. → Home may need to be context-aware (resume where I was / recent workspace), not only the global attention digest. Possibly the app should remember the last zone/context rather than always landing on Home.
• Home scroll behaviour felt off (no/short scroll) — verify the DashboardView scroll + empty/short content layout once the section set is finalized.

Deferred by owner ("tackle after the plan is better implemented") — capture now, design before building. Lives here (front door is part of the nav model) and informs a future doc-37 revision.

Resolved by doc-54 (2026-07-04): both items designed — Home v2 is a non-scrollable one-screen layout (the scroll oddity disappears by design) and gains a context-aware Resume tile (last portal/track/zone). This is the doc-37 revision this note anticipated.

12. Cross-references

• One-dashboard / role-driven: 20-UI-SIMPLIFICATION.md
• Front door (Home triage): 37-HOME-DASHBOARD.md
• X-ray / eagle-view: 42-MANAGEMENT-CTRL.md · engine 38-ANALYTICS-INSIGHTS.md
• Control-room substrate: workflow 46-WORKFLOW-ENGINE.md · attributes 43-CONFIGURABLE-ATTRIBUTES.md · authz 44-RBAC-TEAMS-PERMISSIONS.md · records 41-RECORDS-AUDIT-STATE-STATUS.md
• Navigation grammar / Portals / Roster Portal: 26-IDENTITY-SHARING-NAVIGATION.md · 36-INTERACTION-PATTERNS.md · 23-IOS-PHASE2-IA.md
• Brand / business frame: 31-PRODUCT-VISION-360.md
• Origin (actors / Lego OS / /manage): 12-ACTORS-WORKFLOWS.md · 17-UX-ARCHITECTURE-ACTOR-DRIVEN.md
• Design system: 22-IOS-DESIGN-SYSTEM.md