Execution Fabric

Execution Fabric is how SpineWorkspace executes governed capabilities against source systems. It commits canonical state first. Sync is independent.

Execution Lifecycle

User Initiates Capability
        ↓
Gate 1: Pre-Proposal
        ↓
Pending Approval (if required)
        ↓
User Approves
        ↓
Gate 2: Execution
        ↓
Spine Sync
        ↓
Projection Refresh

Execution Plan

Every execution produces an execution plan:

interface ExecutionPlan {
  id: string;
  tenant: string;
  proposal: string;
  confidence: number;
  evidence: Evidence[];
  context: ExecutionContext;
  steps: ExecutionStep[];
  governance: GovernanceRecord;
  outcome?: ExecutionOutcome;
}

Execution Steps

Each step in the plan represents a single capability invocation:

interface ExecutionStep {
  capability: CapabilityId;
  adapter: AdapterId;
  params: Record<string, unknown>;
  rollback: CapabilityId | null;
}

Adapter Dispatch

1. Resolve adapter by capability and configured providers
2. Prefer live adapter when healthy; fallback to mock when unavailable
3. Execute step with timeout and retry policy
4. Emit timeline event for every step

Communication Hierarchy

Execution follows a strict communication hierarchy:

Priority	Method	Scope
1	In-process function call	Same Worker
2	Repository access	D1/KV/R2/DO
3	Service binding	Same-account Worker
4	Queue	Async propagation
5	External HTTP	Browser/SaaS boundary only

Rule: Worker-to-Worker HTTP on the same account is an anti-pattern.

Execution Components

Component	Purpose
Capability Registry	Catalog of available capabilities
Capability Execution Engine	Runs individual capability steps
Workflow Router / Engine	Orchestrates multi-step flows
Context Builder	Assembles execution context
Execution Orchestrator	Coordinates step sequencing
Metrics and Learning	Tracks execution quality
Capability Discovery UI	Surfaces available capabilities

Execution and Governance

Execution applies governance at two points:

1. Pre-proposal: Validate that the capability can be invoked
2. Pre-execution: Re-validate governance with fresh policy

This prevents TOCTOU issues where policy changes between composition and execution.

Rollback

If execution fails:

EXECUTION FAILED
      ↓
CHECK ROLLBACK AVAILABILITY
      ↓
EXECUTE ROLLBACK (if available)
      ↓
EMIT TIMELINE EVENT
      ↓
UPDATE WORK STATE
      ↓
NOTIFY USER

Execution Receipt

Every execution produces a receipt:

• Capability invoked — what was attempted
• Parameters used — what was sent
• Result received — what came back
• Timeline event emitted — for audit
• Spine updated — canonical state changed
• Projection refreshed — user sees updated state

Related

• Capability Fabric — what capabilities are available
• Governance — the policy boundary
• Reconciliation — how execution results are verified
• Spine Schema — what is updated after execution