Projection Contract

Projection is how Spine Fabric becomes visible to humans and AI. The Projection Engine is the sole composition layer that produces projected surfaces. No other component constructs workbench views.

Core Principle

CANONICAL SPINE
      ↓
PROJECTION ENGINE (sole composition layer)
      ↓
SHARED WORKBENCH (sole composed output)
      ↓
USER WORKBENCH + TWIN WORKBENCH

The Projection Engine reads from Spine Fabric, applies governance, and produces a SharedWorkbench shape. Every downstream consumer — web app, mobile, Twin runtime, capability fabric — imports this contract.

Projection Engine

The Projection Engine is the sole component that produces a SharedWorkbench. No other package, service, or route handler may construct this shape.

The gateway (BFF) delegates all composition to ProjectionEngine.compose(). It handles auth, routing, and response formatting — but never assembles entities, relationships, or capabilities directly.

Rules:

• Single source of truth for workbench composition
• Consistent output shape across all consumers
• Versioned contract with breaking-change policy
• No consumer may define its own workbench shape

SharedWorkbench

SharedWorkbench (defined in contracts/shared-workbench/v1.ts) is the sole output type of the Projection Engine. Every downstream consumer imports this contract.

Contains:

• Active work surface (tasks, work items, approvals)
• Entity context (focused entity, relationships, timeline)
• Twin state (passive observation, active proposals)
• Governance state (action availability, approval requirements)
• Capability state (available actions, execution status)
• Memory context (relevant organizational memory)
• Connectivity state (sync health, connector status)

Rules:

• Type-safe contracts across the entire stack
• Optional fields for consumer-specific extensions
• Versioned contract with changelog

Governance at Two Gates

Governance applies at two gates:

1. Composition Gate

Projection Engine evaluates governance for each capability when composing SharedWorkbench. The governance field tells the frontend which actions are allowed, which need approval, and which are denied.

2. Execution Gate

Capability Fabric re-evaluates governance before executing any action. This prevents TOCTOU (time-of-check-time-of-use) issues where policy changes between composition and execution.

Composition gate: cached policy (fast, <30s TTL)
Execution gate: fresh policy (authoritative)

Result: Users see accurate action availability. No surprise denials at execution time.

Projection Path

From the canonical ontology, the projection path is:

CANONICAL SPINE
      ↓
CONTEXT ASSEMBLY
      ↓
PERMISSION / PURPOSE / RELEVANCE / FRESHNESS
      ↓
AI OPERATIONAL SANDBOX
      ↓
TWIN / AGENTS

Rules:

• Canonical Spine is never directly exposed to AI
• Context assembly is bounded by permission, purpose, relevance, freshness
• AI operates only within the operational sandbox
• Twin consumes projected context, not raw Spine

Workbench Regions

The Workbench surface is projected as regions:

Region	Purpose	Content
Today	Immediate priorities	Items due, urgent signals, active work
Communications	Channel coordination	Threads, messages, emails, meetings
Organizational Memory	Knowledge workspace	Notion-like org knowledge, decisions, playbooks
Work	Domain-specific work surfaces	Departmental modules, tasks, approvals

Each region is a projection of shared Business Context. The Workbench is not a second database, a static dashboard, or a departmental copy of truth.

Related

• Spine Schema — what is being projected
• Workbench Canonical Model — the projected surface
• Twin — the AI workspace that consumes projections
• Governance — the policy applied at projection and execution