Workspaces

The two role workspaces, their shell, and the workflows they run.

Overview

The KAP web app is organized into role workspaces — a focused surface per job-to-be-done. There are two, both under /w/<slug>/…:

Slug Name Focus
data-explorer Data Explorer Prepare campaign evidence for integrity review.
integrity Integrity Engineer Triage evidence and drive governed integrity action.

Each workspace is the same shell wrapping a different set of modules and a different default AI engine. The persona requirements behind them (e.g. FR-APP-15, persona-tailored chat) live in the Product Requirements & Roadmap handbook.

The shell

WorkspaceShell (components/workspaces/workspace-shell.tsx) composes three regions around the module page:

  • Left sidebar (components/sidebar.tsx) — the workspace switcher plus the module nav, grouped by workflow stage (see below).
  • Context bar (workspace-context-bar.tsx) — the current scope (organization / campaign) and the Assistant toggle (⌘J).
  • Docked Assistant panel (workspace-assistant-panel.tsx) — an always-available slide-over; on mobile it’s the BubbleChat launcher. The Assistant is a tool that overlays every module, not a nav destination.

Workflow groups

Modules are grouped into workflow stages (WorkspaceNavigationGroup): scope → prepare → review → act → assist. Each workspace uses the stages that fit its job:

  • Data Explorer: Organizations · Campaigns (scope) → Evidence · Notes · Storage · Assets · Classes (prepare).
  • Integrity Engineer: Campaigns (scope) → Candidates · Investigate · Assets · Storage · Worklist · Evidence Explorer (review) → Actions · Campaign History (act).

The same ModuleId can read differently per workspace — insights is Notes in Data Explorer and Candidates in Integrity.

The scope model

Work narrows through a nested scope carried in the URL and WorkspaceProvider (lib/workspaces/context.tsx):

organization  →  campaign (dataset)  →  candidate
  • Data Explorer scopes to org / dataset / campaign; Integrity adds candidate (WORKSPACE_ALLOWED_SCOPE_KEYS) — ?finding= is still accepted for one release (W3, docs/proposals/ 20260828_the_workflow_between_the_two_workspaces.md, D1): a tagged image awaiting engineering attention is a candidate, not yet a finding.
  • Each module declares — via the context policy — whether the context bar shows an org/campaign selector, a read-only summary, or nothing.
  • The workspace switcher preserves compatible scope when you move between workspaces (getWorkspaceSwitchTarget), so an org/campaign carries across.

The end-to-end workflow

The two workspaces are a relay: Data Explorer prepares the evidence an Integrity Engineer acts on. The hand-off itself is a real state, not just a diagram: every campaign carries a lifecycle (indexing → ready_for_review → in_review → closed, W7), and the campaign card in both workspaces shows it as a badge.

  • Data Explorer — scope an org/campaign, browse Evidence (imagery, annotations, modality coverage), curate Notes, and review Assets (the geo-linked evidence per asset), then Send for review on the campaign card to move it from indexing to ready_for_review.
  • Integrity Engineer — the Campaigns queue splits Awaiting an engineer from Still being prepared by that same state. Choose a Campaign and see its summary, work the Candidates queue, Investigate a finding against its physical evidence and decide it (confirm / dismiss), review Assets (findings + decide per asset) or the Evidence Explorer (map, gallery, and the full ranked candidate list for that campaign), create follow-up Actions, and read the Campaign History — now a real timeline of who sent or returned the campaign, and why, not a single snapshot. Return for more evidence (with a required reason) sends it back to indexing; in_review and closed are reserved states with no UI action yet.

The Assistant per workspace

The docked Assistant is scoped to the current org / campaign / candidate and uses the workspace’s defaultEngine (Integrity defaults to kawa); the engine maps to system_type on the chat request — see Web ↔︎ AI Integration and CONTRACT-CDC-001.

Note

How a module registers into this shell — the registry, per-workspace config, sidebar building, and role/data gating — is the Workspace Modules contract.