Concept map

The concept layer: screens grouped by the person's intent, derived from the flows and jobs. Each node is a screen with the job it closes. States (empty / error / loading) are not here, they live in the flows and the matrix; page content and cards are the detail layer. Below: the intent map, the navigation model, and the traceability matrix.

Concept

Screens by intent

Not a hierarchy, a map of screens grouped by what the person is trying to do. Six intents (A to F) derived from the flows and jobs. Each node carries a short job-tag; no X.Y numbers, no states, no content cards, those belong to the detail layer.

flowchart TD
    subgraph GA["A. Get started (acquire + sign up)"]
      gs1["Landing / home
Main, item 1"]
      gs2["Pricing
item 1"]
      gs3["Sign up
item 1"]
      gs4["Log in
supporting"]
    end
    subgraph GB["B. Set up wellbeing (onboarding)"]
      sw1["Company setup
J6"]
      sw2["First program confirm
Main, J6, item 2"]
      sw3["Invite team
Main, item 3"]
    end
    subgraph GC["C. Run wellbeing and read the pulse"]
      rw1["Dashboard
E1, J1, J2"]
      rw2["Team pulse detail
J1, J2, E1"]
      rw3["Threshold alert
J2"]
      rw4["Program library
Main, J6"]
      rw5["Program detail / manage
Main, item 2"]
      rw6["Check-in setup
J2, J4, item 3"]
    end
    subgraph GD["D. Team and check-ins"]
      tc1["Team roster
Main, item 3"]
      tc2["Check-in, employee
J3, J4, E2"]
      tc3["Pre-Q1 disclosure
J3, E2"]
      tc4["Questions
J4"]
      tc5["Check-in complete
J4, E2"]
    end
    subgraph GE["E. Prove it and upgrade (owner)"]
      pu1["Share with owner
J1, J5, S2"]
      pu2["Invite owner + upgrade
S2, item 8"]
      pu3["Owner dashboard
J1, J5, item 8"]
      pu4["Monthly owner digest
S2, item 8"]
    end
    subgraph GF["F. Account and utility"]
      au1["Plan / subscription
item 1, item 8"]
      au2["Privacy center
J3, E2, item 4"]
      au3["Notifications
J4, items 9-10"]
      au4["Account
supporting"]
      au5["System: 404 / 500 / cookie
all"]
    end
    gs3 --> sw1
    sw3 --> rw1
    rw1 --> tc1
    rw6 --> tc2
    tc2 --> tc3
    tc3 --> tc4
    tc4 --> tc5
    rw2 --> pu1
    pu1 --> pu2
    pu2 --> pu3
    rw1 -.-> au1

Concept, not the site map. This consolidates the eleven detailed clusters (0 to 11 in Sitemap) into six human intents. It shows what the product is made of, by intent, and how screens connect along the flows. The full tree with X.Y nodes and content cards is the detail layer.

Movement

Navigation Model

Global navigation is the shortest path for the primary persona to her main job, not "what to put in a menu." Each global item is an entry into a job-cluster. The owner and employee surfaces have no multi-tab nav by design.

Global navigation (operator app)

Global item	Job-cluster behind it	Why global
Dashboard (home)	E1 + J1 + J2: the pulse signal (score + interpretation + next action)	The recurring aha and the reason she logs in. Post-login home
Programs	Main + J6: run wellbeing (library, pick, manage)	The core "what do I run" job, entered repeatedly
Team	Main + item 3: invite + participation (aggregate)	Entered on every new hire, the invite / roster surface
Owner	J1 + J5 + S2 + item 8: prove it works + upgrade	Top-3 operator job by importance and the paid-conversion path
Settings utility	supporting + item 4: Plan, Privacy center, Notifications, Account	Utility cluster, corner entry, not a job tab

Trade-off: "Owner" is only ~monthly-frequency and could be a contextual "Share this result" action instead. It is kept global because the owner dashboard is the paid feature and J1 / J5 / S2 score 3 for Priya. Reversible if usage shows it is rarely a fresh entry.

Depth: taps to the main job for Priya

Path to a job-cluster	Taps	Within 3?
Returning operator, pulse signal + next action (recurring main-job value)	1 (Dashboard is the post-login home)	Yes
Run / adjust a program (Main + J6)	Programs (1), Program detail (2), Check-in setup (3)	Yes, 3 at deepest
Invite team / roster (item 3)	Team (1), roster on the same screen	Yes
Prove it works / invite owner (J1 + J5 + S2)	Owner (1), Invite owner + upgrade (2)	Yes

One intentional exception, not a violation: the first-run guided onboarding is a linear wizard (company setup, first program confirm, invite team). This is sequential flow depth, not navigational depth. It is J6 itself ("tells me exactly what to do and in what order"), budgeted by time (under 5 minutes), runs once, and is not reachable from global nav afterward.

Global / contextual / deep

Global (always visible): the 4 job tabs (Dashboard, Programs, Team, Owner) plus Settings utility. Owner surface = single dashboard; employee surface = no nav.

Contextual (inside a flow): "Share this result with your owner" (on a positive milestone), "Set up check-in" (inside a program), "Resend invite" (inside roster), threshold-alert banner (on the Dashboard when it fires), pre-Q1 privacy disclosure (inside the check-in), upgrade prompt (on a free-tier limit).

Deep (rare): Plan / subscription change, Privacy center detail, Notification cadence, Account, and the one-time onboarding wizard.

Coverage

Traceability Matrix

Screens (rows) by jobs (columns). A tick means the screen participates in closing that job. An empty row is an orphan screen; an empty column is an orphan job. Both are defects, surfaced and resolved below.

Screen	Main	J1	J2	J3	J4	J5	J6	E1	E2	E3	S2
1 Landing	✓
2 Pricing	✓
3 Sign up	✓
4 Log in
5 Company setup	✓						✓
6 First program confirm	✓						✓	✓
7 Invite team	✓				✓		✓
8 Dashboard	✓	✓	✓					✓
9 Team pulse detail		✓	✓					✓
10 Threshold alert detail			✓
11 Program library	✓						✓
12 Program detail / manage	✓						✓
13 Check-in setup			✓		✓			✓
14 Team roster	✓				✓
15 Share with owner		✓				✓					✓
16 Invite owner + upgrade		✓									✓
17 Plan / subscription				✓							✓
18 Privacy center				✓					✓
19 Notifications			✓		✓
20 Account
21 Owner dashboard		✓		✓		✓				✓	✓
22 Monthly owner digest		✓				✓				✓	✓
23 Check-in				✓	✓				✓
24 Pre-Q1 disclosure				✓					✓
25 Questions					✓
26 Check-in complete					✓				✓

Orphan screens (empty rows)

4 Log in
20 Account

Close no job on their own. Resolution: keep, reclassify as supporting infrastructure. They gate every operator job; removing them removes access to all job-closing screens. The one honest exception to "no empty row," not cut.

Orphan jobs (empty columns)

Tell network what works has no MVP screen. Resolution: backlog / [?]. S1 is a [?] hypothesis; the referral surface is parked (Stage 2 cut list bans cash referral, organic operator-to-peer is out of MVP scope). Validate S1 first, then a lightweight share surface post-MVP. Intentional hole.

Thin coverage (not a hole to fill in MVP): E3 (caring leader) is covered only by Owner dashboard / digest as shareable proof, a [?] hypothesis. Hypothesis jobs HJ1 and HJ2 are deliberately parked (HJ2 = backlog item 12 LATER).

Net: one real orphan job (S1, to backlog), zero orphan screens to cut (two supporting-infrastructure rows kept), no MVP job left uncovered.

Coverage

Emotional and social jobs: what supports them

The matrix above carries functional jobs only. An emotional or social job is not closed by a screen: it is closed by a mechanism spread across screens. Putting a tick in the matrix for E1 or E2 would claim a screen owns a feeling. This table names the mechanism instead, and the Detail Layer and Voice read it from here. Source: research/docs/jtbd.md and research/docs/cjm-to-be.md.

Job	Persona	The mechanism that supports it	Where it is visible
E1 feel like a competent people person	Priya, primary	The interpretive layer, cross-cutting: no number is shown without its reading, every setup ends in a confirmation, every operator screen offers one suggested next action	4.0, 4.1, 3.1, 5.2, 6.0, 9.0
E2 feel supported, not monitored	Yemi, primary	The privacy bundle as a visible mechanism, four parts: pre-Q1 disclosure sentence, minimum of 5, no live count during an open cycle, subscription-as-privacy statement	10.1, 0.3, 1.1, 8.2
E3 be seen as a caring leader	Marcus and Priya, secondary	Shareable aggregate proof: the owner dashboard and monthly digest are the artefact a leader can hold up. Deliberately thin, because E3 is still a hypothesis	9.0, 9.2
S1 tell my network what works	Priya	Nothing in the MVP, and that is the decision. S1 is a [?] hypothesis and cash referral is on the Stage 2 cut list	no node
S2 share the result with the owner easily	Priya to Marcus	The operator-to-owner share act, kept distinct from inviting the owner: two labels for two different acts	7.0, 7.1

Consequence for Voice: E2 fixes the one privacy sentence (mechanism, never reassurance), E1 fixes the rule that a score never appears without its reading, and S2 fixes the two distinct labels. All three are rules in voice/docs/voice.md; this is where they get their parent.

Volume

Estimate: MVP and LATER

The one place the volume of the product is narrowed. The parent list is the backlog in research/docs/cjm-to-be.md: items 1 to 10 are MVP, items 11 and 12 are LATER. A node is MVP when an MVP backlog item cannot ship without it, or when it is an auth, legal or system precondition the To-Be path can actually hit. A node is LATER when the first round runs without it. Every node keeps its specification and its grey wireframe either way: the label orders the work, it does not cut the spec.

Group	Nodes	MVP	LATER
Global elements	6	6	0
Pages	48	43	5
Total	54	49	5

The five LATER nodes	Why the To-Be path does not break without it
1.2 About	Trust here is carried by the privacy mechanism shown in the UI, not by a company story. No backlog item needs it.
1.3 Contact / Support	Self-serve by design: the operator starts in an afternoon without talking to anyone. No MVP item depends on it.
1.4 Help / FAQ	The in-product answer to "am I doing this right" is the interpretive layer, which is MVP and cross-cutting. A help library is a second, weaker answer to the same job.
1.5 Category / segment landing	Acquisition breadth. Activation is measured from Pricing and Sign up, not from segment pages.
11.2 Maintenance	An operational state, not a path state. The path can hit 404 and 500; planned maintenance is a deploy practice the MVP does not have yet.

Who reads this: stage 07 (which screens are coloured first and which enter the 3 to 5 sample), stage 08 (roll-out order) and stage 09 (the next node built straight from the system). The label lives once, in ia/_nav.js, and shows as a chip on Structure.