SpineWorkspace Workbench — Canonical Model

The dictated target model for the adaptive (Spine) Workbench: one surface where context is assembled and gathered for the user, organized by four canonical sidebar sections, powered by the Spine schema, projected per role/domain, and worked by Human + Twin + Coworker together. Evidence labels follow _reference_ARCHITECTURE_v3.1.md: LAW, VERIFIED, INTENDED, DRIFT.

1. The One-Surface Law

The Workbench is ONE surface. There are no layers, modes, or alternate UIs. L-labels never appear in user-facing UI.

LAW. Reaffirmed from ARCHITECTURE_LOCK §V and v3.1 Projection Law.

#	Section	Contents	Purpose
1	Today	Personal/day view — what needs to be taken care of today	Daily orientation; the entry point of the User Path
2	Communications	Teams-style messaging: email, chat, calls, meetings, shared documents	Human↔human continuity inside the same surface
3	Organization Memory	Organizational calls, decisions, and documentation for the work and the work environment — a Notion-like knowledge workspace over org memory	Shared institutional knowledge; reads governed org memory
4	Work	Complete business-context views — role/domain projections of Spine data	The operational surfaces where work is done

Current implementation vs model

Section	Status	Where
Today	VERIFIED	`home` + `personal` nav groups (`packages/workbench-config/src/generated/navigation.ts`)
Communications	VERIFIED	`communications` group — Email, Calendar, Meetings, Chat, Calls, Documents, Activity
Organization Memory	INTENDED — GAP	Only personal-scope Knowledge Base/Notes exist under `personal`; an org-scoped Memory section does not yet exist
Work	VERIFIED	`my-work` group, re-keyed per role via `resolveWorkNavigationForRole`

3. Spine Schema Generator

INTENDED. The Spine schema is generated for organizational needs from the organizational lifecycle of events — not hand-authored per customer. The generator derives entity types, relationships, event types, and memory scopes from how the organization actually operates.

Organizational lifecycle events
        ↓
   SPINE SCHEMA GENERATOR
        ↓
Canonical schema (entities · relations · events · memory scopes)
        ↓
Per-role / per-domain PROJECTIONS

Schema generation is a System Path concern. Users never see or configure raw schemas.
Generated schema feeds both the Workbench projections and the AI Operational Sandbox assembly.
Alignment: v3.1 Store ownership (canonical vs operational) and Loader Runtime ingestion.

4. Projections — Same Data, Per-Role Views

LAW (Projection Law). Every user sees the SAME organizational data through their OWN view, scoped by RBAC, role, and domain.

A projection is a view of shared truth — never a new source of truth.
Cross-team and cross-domain collaboration happens by sharing knowledge ON the Spine — not by copying data between teams.
15 external domain workbenches + 3 internal surfaces already encode this: packages/workbench-config/src/domain-workbenches.ts (VERIFIED).
AI enables the work on these projections: workflows, agents, intelligence operate against the projection scope, promoting proposals through governance when they must become canonical.

5. Twin — The User’s Digital Twin

Refinement of v3.1 Twin Law.

Each user receives exactly ONE Twin, allotted to the domain of the user’s role. The Twin does NOT need to cover vast domains — its own user’s domain plus that domain’s agents and domain workspaces are enough. INTENDED
The Twin is the user’s digital assistant/agent for their work: it carries out digital and agentic executions end-to-end.
It operates ONLY on sandbox (operational) data — never canonical Spine. LAW (AI Sandbox Law)

Shared Task Assignment Layer

INTENDED — key new contract. A single task layer spans human and agents:

Task assigned ──→ [ SHARED TASK LAYER ] ──→ human OR agent
                        │
                  Twin orchestrates:
                  takes tasks from the layer,
                  allots subtasks to domain agents,
                  drives them to completion,
                  returns results to the layer

Tasks may be allotted to the user, to agents, or to user+agent jointly.
The Twin is the orchestrator within this layer; it delegates to domain-specific agents.
Every allotment and completion is visible to the user in the Workbench (no hidden execution).
Governed effects still traverse Governance → Execution Fabric. The task layer coordinates; it does not authorize.

Twin Workbench (Agentic Home)

INTENDED. The Twin has its own workspace — a home base for agentic work (conceptually like Open WebUI / LangChain): sessions, tool use, agent roster, running executions — all operating on the sandbox copy of context. The Agent Workspace is SEPARATE from the User Workbench; the two stay consistent through the platform loop, not through shared state.

6. Coworker — Context Companion

Per v3.1 Coworker Law, now made concrete:

Gathers context from the user’s screen — active work surface and interaction with the Workbench. INTENDED
Feeds assembled context to Twin and pipeline executions.
Handles communications in CONSISTENCY with the Twin — one voice to the outside, two roles inside: Coworker = context + communication; Twin = reasoning + delegation. INTENDED
Neither is a second authority. Neither writes canonical truth.

7. The Full Drill-Down Loop

ORGANIZATIONAL NEEDS  (scattered across multiple tools & software)
        │
        ▼
SOURCE TOOLS converge into
SPINE FABRIC           (contextual layer for business continuity)
        │
        ├──────────────► serves HUMAN  → projections → USER WORKBENCH
        │
        └───(sandbox only)──► serves AI  → TWIN WORKBENCH (agentic home)
                                │              │
                                │        shared TASK LAYER
                                │        (human ⇄ agents, Twin orchestrates)
                                ▼
                          WORK EXECUTED & COMPLETED
                                │
                                ▼
                     results WRITE BACK to SOURCE TOOLS
                     via workflows — driven by AI, not manual repetition
                                │
                                ▼
                    PLATFORM UNDERNEATH carries everything:
                    auth · packages · MCP connectors · infrastructure
                    pipeline · loop · communication layer · ADK · orchestrator
                    (communication enablers; can talk to other platforms too)

Key distinctions:

Distinction	Rule
Canonical Spine	Humans reach it through projections; AI NEVER touches it — sandbox only
User Workbench vs Agent Workspace	Two separate surfaces, kept consistent by the platform loop
Task execution	AI-driven write-back into source tools via workflows — humans stop doing monotonous sync work
Platform	Enabler only. It never becomes a second Workbench (Platform Law)

8. Layer Model

Organization layer — decides goals and needs.
Cascade layer — goals/needs transfer to humans by domain, role, responsibility.
Human layer — works tasks/goals aligned to organizational and business needs.
AI layer (per-user instance) — ONE Twin per user, scoped to the user’s role domain; domain agents + domain workspaces attached; no vast cross-domain coverage required.
Surfaces layer — User Workbench (projections) separate from Agent Workspace (Twin home).
Platform layer — pipeline, loop, communication layer, MCP, ADK, orchestrator: communication channels and enablers underneath everything.

9. Boundary Laws (restated for this model)

AI Sandbox Law — AI reads sandbox, never canonical Spine.
Governance Law — confidence never grants authority; consequential mutation passes Governance before Execution Fabric.
Projection Law — projections are views, not sources.
Platform Law — the substrate enables; it does not become another Workbench.
Continuity Law — bounded continuity across people, tools, AI hosts, domains.

10. Gap Register — Dictated Model vs Current Code

#	Model element	State	Next step
G1	Organization Memory sidebar section (org-scoped knowledge workspace)	INTENDED — GAP	Promote personal Knowledge Base patterns into an org-memory-backed section reading approved org_memory only
G2	Spine Schema Generator from org lifecycle events	INTENDED	Spec + service boundary in Pipeline plane
G3	Shared Task Assignment Layer (human ⇄ agents)	INTENDED	Extend Task Management MCP contracts with assignee-kind (human/agent/joint) + Twin orchestration hooks
G4	Twin Workbench as separate agentic home	PARTIAL — Twin runtime exists (`services/iw-agent-runtime`)	Productize session/tool/agent-roster surface
G5	One-Twin-per-user scoped to role domain	PARTIAL — Twin binding exists	Enforce 1:1 user:Twin allotment with domain scoping in runtime config
G6	Coworker screen-context gathering + unified comms with Twin	INTENDED	New Coworker capability in runtime; comms consistency contract
G7	AI-driven write-back of completed work into source tools	PARTIAL — reconciliation loop exists in doctrine	Wire workflow-based writeback into Execution Fabric outcomes

00 · Founder Canon

PART I — Top Product View

PART II — Work Model

PART III — AI & Agent Execution

PART IV — Platform Execution

PART V — Capability & Governance

PART VI — Spine, Data & Continuity

PART VII — Closure

PART VIII — Implementation

PART IX — Operating / Governance

PART X — Canonical Map

Platform & Architecture (Legacy)

End-State Reference (Legacy)

Workbench Canonical Model

SpineWorkspace Workbench — Canonical Model

1. The One-Surface Law

2. Left Sidebar — Four Canonical Sections

Current implementation vs model

3. Spine Schema Generator

4. Projections — Same Data, Per-Role Views

5. Twin — The User’s Digital Twin

Shared Task Assignment Layer

Twin Workbench (Agentic Home)

6. Coworker — Context Companion

7. The Full Drill-Down Loop

8. Layer Model

9. Boundary Laws (restated for this model)

10. Gap Register — Dictated Model vs Current Code

​SpineWorkspace Workbench — Canonical Model

​1. The One-Surface Law

​2. Left Sidebar — Four Canonical Sections

​Current implementation vs model

​3. Spine Schema Generator

​4. Projections — Same Data, Per-Role Views

​5. Twin — The User’s Digital Twin

​Shared Task Assignment Layer

​Twin Workbench (Agentic Home)

​6. Coworker — Context Companion

​7. The Full Drill-Down Loop

​8. Layer Model

​9. Boundary Laws (restated for this model)

​10. Gap Register — Dictated Model vs Current Code

SpineWorkspace Workbench — Canonical Model

1. The One-Surface Law

2. Left Sidebar — Four Canonical Sections

Current implementation vs model

3. Spine Schema Generator

4. Projections — Same Data, Per-Role Views

5. Twin — The User’s Digital Twin

Shared Task Assignment Layer

Twin Workbench (Agentic Home)

6. Coworker — Context Companion

7. The Full Drill-Down Loop

8. Layer Model

9. Boundary Laws (restated for this model)

10. Gap Register — Dictated Model vs Current Code