Documentation source

DOC'S Workspace Catalog

The three scoped workspaces inside the DOC'S tenant — Research, Operations, and Intake & Protocol — and how operators and owners navigate between them.

## Overview

DOC'S (tenant slug: `docs`) uses the Sprinter Platform workspace system to scope focus without fragmenting data. Workspaces are **focus boundaries, not data silos** (ADR-0008): all entity records (patients, visits, feedback, payments) live at the tenant level and are visible across workspaces. What changes per workspace is the nav rail, the default views, and the agent context surfaced to users.

Three workspace rows are seeded by `scripts/seed-docs-workspaces.ts`. Two additional "virtual" contexts — the DOC'S Operator home and DOC'S Owner home — are tenant-level nav configurations rather than separate workspace rows.

For platform mechanics (URL routing, scope resolver, workspace memberships), see the [Workspaces platform doc](/docs/features/workspaces).

---

## The Three Seeded Workspaces

| Workspace             | Slug              | Icon          | Accent  | Primary persona         |
| --------------------- | ----------------- | ------------- | ------- | ----------------------- |
| **Research**          | `research`        | microscope    | indigo  | Clinical reviewer / Doc |
| **Operations**        | `operations`      | calendar-days | amber   | Nolan (operator)        |
| **Intake & Protocol** | `intake-protocol` | stethoscope   | emerald | Nolan + Doc             |

Source: `DOCS_WORKSPACE_SEEDS` in `scripts/seed-docs-workspaces.ts:124`.

---

## Workspace Details

### Research

**JTBD:** Modality library, claims queue, and evidence dossiers. Used by the clinical reviewer to evaluate evidence for each modality, triage unsubstantiated claims, surface evidence gaps in the protocol library, and build or update modality dossiers.

- **Primary persona:** Doc (clinical authority) and any clinical reviewer with workspace access.
- **Nav rail items:** Modalities, Sources, Claims Queue, Evidence Gaps, Modality Dossier, Library.
- **Featured entity types:** `modality`, `source-item`, `evidence-claim`.
- **Featured views:** `claims-queue`, `evidence-gaps`, `modality-dossier`, `research-library`.
- **Default agents in scope:** Research agent (evidence lookup via Exa, `webSearch` tool). Claims and dossier synthesis agents.
- **Pinned record:** none (research is exploratory, not patient-centric).

**Day-in-the-life:** Doc opens the Research workspace to review new claims submitted by the agent, triage gaps in the evidence base for a new modality being considered (e.g., HBOT for a sleep health lane), and approve updates to the protocol library before they flow to the Intake & Protocol workspace.

---

### Operations

**JTBD:** Today's visits, scheduling, modality utilization, and the patient feedback inbox. Nolan's daily floor command center — every patient interaction happens in this context.

- **Primary persona:** [Nolan the DOC'S Operator](/docs/personas/docs-operator-nolan).
- **Pinned record:** `patient` (accessible via `?patient=<slug>` URL param — find-or-create surfaced at the top of every view).
- **Nav rail items:**

| Label                | Kind | Target                                                          |
| -------------------- | ---- | --------------------------------------------------------------- |
| Wellness OS          | link | `/p/${DOCS_WELLNESS_PAGE_SLUG}` (operator wellness custom page) |
| Command Center       | view | `operations-command-center`                                     |
| Today's Visits       | view | `todays-visits`                                                 |
| Schedule             | view | `ops-schedule`                                                  |
| Active Patients      | view | `active-patients`                                               |
| Pending Feedback     | view | `pending-feedback`                                              |
| Concerning           | view | `concerning-feedback`                                           |
| Modality Utilization | view | `modality-utilization`                                          |

- **Featured entity types:** `visit`, `patient`, `feedback`.
- **Default agents in scope:** Protocol builder agent (protocol recommendations, optimization suggestions). Visit log and flagging happen here.
- **Acuity sync surface:** Today's Visits is the primary surface where Acuity-synced appointments appear. The "Patients needing review" view (`docs-acuity-patients-needs-review`) surfaces auto-created patients that the linker could not match with high confidence.

**Day-in-the-life (Nolan):** Opens Operations at the start of the day. Today's Visits shows appointments synced from Acuity — each entry shows the patient name, protocol lane, visit number, and feeling trend from prior visits. Taps a patient → patient record opens with the day's modality plan, last-3-visits chart, and the active protocol. Runs through the modality cards during the visit, logs a 30-second feeling note, closes the visit. End-of-day uses Command Center (visits today, flagged patients, follow-up call list).

Source: `operations` entry in `NAV_OVERLAY_DEFINITIONS` at `scripts/seed-docs-workspace-nav.ts:101`.

---

### Intake & Protocol

**JTBD:** New patient intake forms, therapy plans, protocol library, and screening rules. Where a new patient's clinical journey is initialized and where protocols are authored and maintained.

- **Primary personas:** Nolan (runs intake with new patients) and Doc (approves protocol library updates, reviews therapy plans).
- **Pinned record:** `patient` (accessible via `?patient=<slug>` URL param — enables looking up a patient while building their therapy plan).
- **Nav rail items:**

| Label              | Kind | Target                  |
| ------------------ | ---- | ----------------------- |
| New Patient Intake | view | `new-patient-intake`    |
| Therapy Plans      | view | `therapy-plans`         |
| Plan Builder       | view | `therapy-plan-builder`  |
| Active Patient     | view | `active-patient-detail` |
| Protocol Library   | view | `protocol-library`      |
| Protocol Ops       | link | `/p/protocol-ops`       |
| Screening Rules    | view | `screening-rules`       |

- **Featured entity types:** `intake`, `therapy-plan`, `patient`, `protocol`.
- **Default agents in scope:** Protocol builder agent (`docs-protocol-builder`, 35-tool agent). Also the linker and backfill actions for Acuity (both scoped to `workspace_slugs: ["operator"]` in action metadata).
- **Screening gate:** Patients with `screening_disposition: "defer"` or `plan_status: "safety_hold"` surface as flagged. Contraindications and modality conflicts surface in this workspace before a patient is placed in a chamber.

**Day-in-the-life:** A new patient books via Acuity. By the time they arrive, the Acuity webhook has created a stub visit and the linker has auto-created a patient record. Nolan opens Intake & Protocol → New Patient Intake, which is pre-populated with whatever the Acuity booking form captured. The intake form captures medical history, goals, screening questions, and contraindication flags. The protocol builder agent synthesizes a recommended protocol. Nolan reviews it with the patient, confirms, and saves the therapy plan. The patient's next visit in Operations already shows the confirmed protocol.

Source: `intakeProtocol` entry in `NAV_OVERLAY_DEFINITIONS` at `scripts/seed-docs-workspace-nav.ts:163`.

---

## DOC'S Operator and Owner Contexts (Tenant-Level)

Two additional "home" contexts are tenant-level nav configurations rather than seeded workspace rows. They appear in the workspace switcher as the tenant-default surfaces.

| Context            | Who   | Description                                                                                                                                           |
| ------------------ | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **DOC'S Operator** | Nolan | Default dashboard view when no workspace is selected. Today's queue (Acuity-synced), flagged follow-ups, clinical alerts.                             |
| **DOC'S Owner**    | Doc   | Strategic cohort trends (Wall PD officers, athletic recovery, chronic pain), flagged patient review, protocol library approval, agent context tuning. |

These are not separate `workspaces` table rows. They are driven by the tenant's `nav_config` and the `DOCS_WELLNESS_PAGE_SLUG` custom page. See `scripts/dial-in-docs-demo.js` and `features/custom/lib/docs-wellness-page-source.ts`.

---

## Cross-Workspace Navigation

### Nolan's typical day

Nolan primarily operates in **Operations**, with occasional dips into **Intake & Protocol** for new patients.

```
Start of day
  └─ Operations → Today's Visits (check Acuity queue)
        ↓ patient walks in
  └─ Operations → patient record (view plan, run modalities, log feeling)
        ↓ new patient (rare — Acuity pre-fills most data)
  └─ Intake & Protocol → New Patient Intake (run intake, get protocol)
        ↓ end of day
  └─ Operations → Command Center (visits today, flagged, follow-ups)
```

Switch workspace by clicking the workspace selector in the sidebar rail. URL changes from `/t/docs/w/operations/...` to `/t/docs/w/intake-protocol/...` — per-tab independence is free (ADR-0008).

### Doc's typical week

Doc primarily operates in **Research** and the **DOC'S Owner** tenant-level context.

```
Weekly protocol review
  └─ Research → Claims Queue (triage agent-submitted claims)
  └─ Research → Evidence Gaps (identify modalities needing more support)
  └─ DOC'S Owner context → Flagged patients (review operator-flagged cases)
        ↓ protocol update needed
  └─ Intake & Protocol → Protocol Library (approve library changes)
```

---

## Adding a New Workspace

To add a fourth workspace for a new clinical focus (e.g., a dedicated Counter Mode workspace for part-time front desk staff):

### Option A: Admin UI (preferred)

1. Log in as a `tenant_admin` user on the DOC'S tenant.
2. Navigate to Admin → Workspaces → New Workspace.
3. Set slug, name, description, icon, and accent color.
4. Add members via Admin → Workspaces → [workspace] → Members.
5. Configure the nav overlay via Admin → Workspaces → [workspace] → Nav.

This creates a `workspaces` row with a `workspace_memberships` row for each invited member, per the admin UI flow established in PR #988 / ADR-0013.

### Option B: Seed script extension

For reproducible environments (sandbox, staging, demo resets), extend `DOCS_WORKSPACE_SEEDS` in `scripts/seed-docs-workspaces.ts` and add a corresponding entry in `NAV_OVERLAY_DEFINITIONS` in `scripts/seed-docs-workspace-nav.ts`.

Then run the orchestrator:

```bash
env $(grep -E '^(NEXT_PUBLIC_SUPABASE_URL|SUPABASE_SECRET_KEY|SUPABASE_SERVICE_ROLE_KEY)=' .env.local | xargs) \
  DOCS_TENANT_ID=<uuid> npx tsx scripts/seed-docs-sandbox-launch.ts
```

> **Note:** Workspace slugs in seed scripts are the source of truth. If an admin renames a workspace in the UI, the seed will revert the slug on the next run. Either update the seed or stop running the seed against that environment.

---

## Workspace Memberships

All workspaces use the `tenant_admin` role at the workspace level (ADR-0013 D8 — same role used at the tenant tier for workspace admins). Membership is managed via `workspace_memberships(user_id, workspace_id, tenant_id, role_id)`.

For the sandbox, seed invitees via `DOCS_INVITEE_EMAILS` env var:

```bash
DOCS_INVITEE_EMAILS="nolan@docs.example,tyler@sprinterconsulting.com" \
  npx tsx scripts/seed-docs-workspaces.ts
```

Invitees must already be tenant members (`user_tenants` row) — the seed skips users without tenant membership rather than silently auto-adding them. See `ensureWorkspaceAdminMembership` in `scripts/seed-docs-workspaces.ts:295`.

---

## Related Docs

- [DOC360](/docs/features/doc360) — clinical entity graph, modalities, agent roster, demo patients
- [Acuity Scheduling Integration](/docs/integrations/acuity) — how Acuity appointments flow into the Operations workspace
- [Workspaces (platform)](/docs/features/workspaces) — URL routing, scope resolver, authorization, admin UI
- [Multi-Tenant](/docs/features/multi-tenant) — tenant context, RLS, tenant vs workspace scoping
- [Nolan the DOC'S Operator](/docs/personas/docs-operator-nolan) — operator JTBD, surface map, Acuity/amble boundary

## Overview DOC'S (tenant slug: `docs`) uses the Sprinter Platform workspace system to scope focus without fragmenting data. Workspaces are **focus boundaries, not data silos** (ADR-0008): all entity records (patients, visits, feedback, payments) live at the tenant level and are visible across workspaces. What changes per workspace is the nav rail, the default views, and the agent context surfaced to users. Three workspace rows are seeded by `scripts/seed-docs-workspaces.ts`. Two additional "virtual" contexts — the DOC'S Operator home and DOC'S Owner home — are tenant-level nav configurations rather than separate workspace rows. For platform mechanics (URL routing, scope resolver, workspace memberships), see the [Workspaces platform doc](/docs/features/workspaces). --- ## The Three Seeded Workspaces | Workspace | Slug | Icon | Accent | Primary persona | | --------------------- | ----------------- | ------------- | ------- | ----------------------- | | **Research** | `research` | microscope | indigo | Clinical reviewer / Doc | | **Operations** | `operations` | calendar-days | amber | Nolan (operator) | | **Intake & Protocol** | `intake-protocol` | stethoscope | emerald | Nolan + Doc | Source: `DOCS_WORKSPACE_SEEDS` in `scripts/seed-docs-workspaces.ts:124`. --- ## Workspace Details ### Research **JTBD:** Modality library, claims queue, and evidence dossiers. Used by the clinical reviewer to evaluate evidence for each modality, triage unsubstantiated claims, surface evidence gaps in the protocol library, and build or update modality dossiers. - **Primary persona:** Doc (clinical authority) and any clinical reviewer with workspace access. - **Nav rail items:** Modalities, Sources, Claims Queue, Evidence Gaps, Modality Dossier, Library. - **Featured entity types:** `modality`, `source-item`, `evidence-claim`. - **Featured views:** `claims-queue`, `evidence-gaps`, `modality-dossier`, `research-library`. - **Default agents in scope:** Research agent (evidence lookup via Exa, `webSearch` tool). Claims and dossier synthesis agents. - **Pinned record:** none (research is exploratory, not patient-centric). **Day-in-the-life:** Doc opens the Research workspace to review new claims submitted by the agent, triage gaps in the evidence base for a new modality being considered (e.g., HBOT for a sleep health lane), and approve updates to the protocol library before they flow to the Intake & Protocol workspace. --- ### Operations **JTBD:** Today's visits, scheduling, modality utilization, and the patient feedback inbox. Nolan's daily floor command center — every patient interaction happens in this context. - **Primary persona:** [Nolan the DOC'S Operator](/docs/personas/docs-operator-nolan). - **Pinned record:** `patient` (accessible via `?patient=<slug>` URL param — find-or-create surfaced at the top of every view). - **Nav rail items:** | Label | Kind | Target | | -------------------- | ---- | --------------------------------------------------------------- | | Wellness OS | link | `/p/${DOCS_WELLNESS_PAGE_SLUG}` (operator wellness custom page) | | Command Center | view | `operations-command-center` | | Today's Visits | view | `todays-visits` | | Schedule | view | `ops-schedule` | | Active Patients | view | `active-patients` | | Pending Feedback | view | `pending-feedback` | | Concerning | view | `concerning-feedback` | | Modality Utilization | view | `modality-utilization` | - **Featured entity types:** `visit`, `patient`, `feedback`. - **Default agents in scope:** Protocol builder agent (protocol recommendations, optimization suggestions). Visit log and flagging happen here. - **Acuity sync surface:** Today's Visits is the primary surface where Acuity-synced appointments appear. The "Patients needing review" view (`docs-acuity-patients-needs-review`) surfaces auto-created patients that the linker could not match with high confidence. **Day-in-the-life (Nolan):** Opens Operations at the start of the day. Today's Visits shows appointments synced from Acuity — each entry shows the patient name, protocol lane, visit number, and feeling trend from prior visits. Taps a patient → patient record opens with the day's modality plan, last-3-visits chart, and the active protocol. Runs through the modality cards during the visit, logs a 30-second feeling note, closes the visit. End-of-day uses Command Center (visits today, flagged patients, follow-up call list). Source: `operations` entry in `NAV_OVERLAY_DEFINITIONS` at `scripts/seed-docs-workspace-nav.ts:101`. --- ### Intake & Protocol **JTBD:** New patient intake forms, therapy plans, protocol library, and screening rules. Where a new patient's clinical journey is initialized and where protocols are authored and maintained. - **Primary personas:** Nolan (runs intake with new patients) and Doc (approves protocol library updates, reviews therapy plans). - **Pinned record:** `patient` (accessible via `?patient=<slug>` URL param — enables looking up a patient while building their therapy plan). - **Nav rail items:** | Label | Kind | Target | | ------------------ | ---- | ----------------------- | | New Patient Intake | view | `new-patient-intake` | | Therapy Plans | view | `therapy-plans` | | Plan Builder | view | `therapy-plan-builder` | | Active Patient | view | `active-patient-detail` | | Protocol Library | view | `protocol-library` | | Protocol Ops | link | `/p/protocol-ops` | | Screening Rules | view | `screening-rules` | - **Featured entity types:** `intake`, `therapy-plan`, `patient`, `protocol`. - **Default agents in scope:** Protocol builder agent (`docs-protocol-builder`, 35-tool agent). Also the linker and backfill actions for Acuity (both scoped to `workspace_slugs: ["operator"]` in action metadata). - **Screening gate:** Patients with `screening_disposition: "defer"` or `plan_status: "safety_hold"` surface as flagged. Contraindications and modality conflicts surface in this workspace before a patient is placed in a chamber. **Day-in-the-life:** A new patient books via Acuity. By the time they arrive, the Acuity webhook has created a stub visit and the linker has auto-created a patient record. Nolan opens Intake & Protocol → New Patient Intake, which is pre-populated with whatever the Acuity booking form captured. The intake form captures medical history, goals, screening questions, and contraindication flags. The protocol builder agent synthesizes a recommended protocol. Nolan reviews it with the patient, confirms, and saves the therapy plan. The patient's next visit in Operations already shows the confirmed protocol. Source: `intakeProtocol` entry in `NAV_OVERLAY_DEFINITIONS` at `scripts/seed-docs-workspace-nav.ts:163`. --- ## DOC'S Operator and Owner Contexts (Tenant-Level) Two additional "home" contexts are tenant-level nav configurations rather than seeded workspace rows. They appear in the workspace switcher as the tenant-default surfaces. | Context | Who | Description | | ------------------ | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **DOC'S Operator** | Nolan | Default dashboard view when no workspace is selected. Today's queue (Acuity-synced), flagged follow-ups, clinical alerts. | | **DOC'S Owner** | Doc | Strategic cohort trends (Wall PD officers, athletic recovery, chronic pain), flagged patient review, protocol library approval, agent context tuning. | These are not separate `workspaces` table rows. They are driven by the tenant's `nav_config` and the `DOCS_WELLNESS_PAGE_SLUG` custom page. See `scripts/dial-in-docs-demo.js` and `features/custom/lib/docs-wellness-page-source.ts`. --- ## Cross-Workspace Navigation ### Nolan's typical day Nolan primarily operates in **Operations**, with occasional dips into **Intake & Protocol** for new patients. ``` Start of day └─ Operations → Today's Visits (check Acuity queue) ↓ patient walks in └─ Operations → patient record (view plan, run modalities, log feeling) ↓ new patient (rare — Acuity pre-fills most data) └─ Intake & Protocol → New Patient Intake (run intake, get protocol) ↓ end of day └─ Operations → Command Center (visits today, flagged, follow-ups) ``` Switch workspace by clicking the workspace selector in the sidebar rail. URL changes from `/t/docs/w/operations/...` to `/t/docs/w/intake-protocol/...` — per-tab independence is free (ADR-0008). ### Doc's typical week Doc primarily operates in **Research** and the **DOC'S Owner** tenant-level context. ``` Weekly protocol review └─ Research → Claims Queue (triage agent-submitted claims) └─ Research → Evidence Gaps (identify modalities needing more support) └─ DOC'S Owner context → Flagged patients (review operator-flagged cases) ↓ protocol update needed └─ Intake & Protocol → Protocol Library (approve library changes) ``` --- ## Adding a New Workspace To add a fourth workspace for a new clinical focus (e.g., a dedicated Counter Mode workspace for part-time front desk staff): ### Option A: Admin UI (preferred) 1. Log in as a `tenant_admin` user on the DOC'S tenant. 2. Navigate to Admin → Workspaces → New Workspace. 3. Set slug, name, description, icon, and accent color. 4. Add members via Admin → Workspaces → [workspace] → Members. 5. Configure the nav overlay via Admin → Workspaces → [workspace] → Nav. This creates a `workspaces` row with a `workspace_memberships` row for each invited member, per the admin UI flow established in PR #988 / ADR-0013. ### Option B: Seed script extension For reproducible environments (sandbox, staging, demo resets), extend `DOCS_WORKSPACE_SEEDS` in `scripts/seed-docs-workspaces.ts` and add a corresponding entry in `NAV_OVERLAY_DEFINITIONS` in `scripts/seed-docs-workspace-nav.ts`. Then run the orchestrator: ```bash env $(grep -E '^(NEXT_PUBLIC_SUPABASE_URL|SUPABASE_SECRET_KEY|SUPABASE_SERVICE_ROLE_KEY)=' .env.local | xargs) \ DOCS_TENANT_ID=<uuid> npx tsx scripts/seed-docs-sandbox-launch.ts ``` > **Note:** Workspace slugs in seed scripts are the source of truth. If an admin renames a workspace in the UI, the seed will revert the slug on the next run. Either update the seed or stop running the seed against that environment. --- ## Workspace Memberships All workspaces use the `tenant_admin` role at the workspace level (ADR-0013 D8 — same role used at the tenant tier for workspace admins). Membership is managed via `workspace_memberships(user_id, workspace_id, tenant_id, role_id)`. For the sandbox, seed invitees via `DOCS_INVITEE_EMAILS` env var: ```bash DOCS_INVITEE_EMAILS="nolan@docs.example,tyler@sprinterconsulting.com" \ npx tsx scripts/seed-docs-workspaces.ts ``` Invitees must already be tenant members (`user_tenants` row) — the seed skips users without tenant membership rather than silently auto-adding them. See `ensureWorkspaceAdminMembership` in `scripts/seed-docs-workspaces.ts:295`. --- ## Related Docs - [DOC360](/docs/features/doc360) — clinical entity graph, modalities, agent roster, demo patients - [Acuity Scheduling Integration](/docs/integrations/acuity) — how Acuity appointments flow into the Operations workspace - [Workspaces (platform)](/docs/features/workspaces) — URL routing, scope resolver, authorization, admin UI - [Multi-Tenant](/docs/features/multi-tenant) — tenant context, RLS, tenant vs workspace scoping - [Nolan the DOC'S Operator](/docs/personas/docs-operator-nolan) — operator JTBD, surface map, Acuity/amble boundary