Unclassified

L1 WORKBENCH

Canonical Reference: CANONICAL_PLATFORM_ARCHITECTURE.md
This document is downstream of the canonical architecture. Refer to the canonical source for current truth.

Status: CURRENT
Scope: Human product grammar, surface doctrine, Context Lenses
Canonical Owner: Product
Last Verified: 2026-07-11
Evidence Basis: docs/CANON.md, docs/architecture/PRODUCT_ARCHITECTURE.md, docs/architecture/WORKBENCH_DOCTRINE.md, docs/platform-specs/03-workspace-runtime.md, Option B evidence
Supersedes: none
Superseded By: none

1. PRODUCT TARGET: ONE L1 WORKBENCH

The human product is a single L1 Workbench.

The human does not leave L1. Intelligence is a silent partner inside L1. Governance appears when policy requires it.

L1 OPERATIONAL WORKBENCH

2. PRODUCT GRAMMAR

CONTEXT LENS
→ ENTITY COLLECTION
→ ENTITY 360
→ ACTIVITY
→ CONTEXTUAL INTELLIGENCE
→ ACTION
→ GOVERNANCE WHEN REQUIRED
→ EXECUTION STATE
→ CONTINUITY

This is the operating grammar. All human operational interaction resolves through this sequence or a contextual subset.

L2/L3 are not separate screens. They are panel states inside L1.

3. CONTEXT LENS DOCTRINE

SAME ENTITY
+
DIFFERENT CONTEXT LENS
=
DIFFERENT OPERATIONAL EMPHASIS

Context Lenses are roles, departments, industries, and capability clusters applied to the same underlying entity.

Examples:

  • Account Success lens
  • Finance lens
  • BizOps lens
  • IT Administration lens

None of these lenses is automatically a separate product boundary. Each is a projection unless separate product evidence authorizes otherwise.

Department surfaces seen in repository code/docs should be documented as Context Lenses unless a repo-check proves product boundary necessity.

4. TWIN INSIDE L1

Twin is not a separate product interface.

┌──────────────────────────────────────────────────────────────────┐
│                      FOUR-BUTTON OODA GRAMMAR                   │
├──────────────────────────────────────────────────────────────────┤
│ OBSERVE  → STORE IN SPINE        (persist truth to Spine)      │
│ ORIENT   → ASK YOUR TWIN         (query Twin for insight)      │
│ DECIDE   → ASSIGN YOUR TWIN      (delegate to Twin for plan)   │
│ ACT      → APPROVE TWIN'S ACTION (human approval gates exec)   │
└──────────────────────────────────────────────────────────────────┘

Twin never gets a direct Act button. Every consequential execution is gated by human approval.

No pop-ups, no chat window, no “How can I help?” greeting.

5. REUSABLE PRODUCT GRAMMAR

Canonical reference patterns from current corpus:

  • Leads and Lead Detail surfaces provide the strongest known entity collection and entity 360 grammar reference. They demonstrate canonical interaction patterns without implying CRM product scope.

  • Entity Collection grammar: filterable, sortable, role/content-lens-aware view of operational entities.

  • Entity 360 grammar: single entity continuation view with activity, intelligence, action, governance, execution state, and continuity.

  • Activity grammar: continuation markers, unresolved state, prior decision awareness, model/context continuation.

  • Intelligence grammar: contextual, not modal. Appears inline when policy, entity state, or user action asks for it.

  • Action grammar: propose, govern, execute, remember.

6. WHAT L1 IS NOT

L1 ≠ CRM
L1 ≠ Chat
L1 ≠ Dashboard
L1 ≠ Admin shell
L1 ≠ Department portal
L1 ≠ L2 chat drawer
L1 ≠ Twin portal
L1 ≠ Report builder

L1 is the operational work surface governed by continuity. It projects capability and continues operational memory.