{"slug":"architecture/EXECUTION_FABRIC","title":"Execution Fabric","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/EXECUTION_FABRIC.mdx","bytes":3517,"description":"How capabilities are executed against source systems — the lifecycle from intent to receipt.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nExecution Fabric is how SpineWorkspace executes governed capabilities against source systems. It commits canonical state first. Sync is independent.\n\n## Execution Lifecycle\n\n```text\nUser Initiates Capability\n        ↓\nGate 1: Pre-Proposal\n        ↓\nPending Approval (if required)\n        ↓\nUser Approves\n        ↓\nGate 2: Execution\n        ↓\nSpine Sync\n        ↓\nProjection Refresh\n```\n\n## Execution Plan\n\nEvery execution produces an execution plan:\n\n```typescript\ninterface ExecutionPlan {\n  id: string;\n  tenant: string;\n  proposal: string;\n  confidence: number;\n  evidence: Evidence[];\n  context: ExecutionContext;\n  steps: ExecutionStep[];\n  governance: GovernanceRecord;\n  outcome?: ExecutionOutcome;\n}\n```\n\n## Execution Steps\n\nEach step in the plan represents a single capability invocation:\n\n```typescript\ninterface ExecutionStep {\n  capability: CapabilityId;\n  adapter: AdapterId;\n  params: Record<string, unknown>;\n  rollback: CapabilityId | null;\n}\n```\n\n## Adapter Dispatch\n\n1. Resolve adapter by capability and configured providers\n2. Prefer live adapter when healthy; fallback to mock when unavailable\n3. Execute step with timeout and retry policy\n4. Emit timeline event for every step\n\n## Communication Hierarchy\n\nExecution follows a strict communication hierarchy:\n\n| Priority | Method | Scope |\n|----------|--------|-------|\n| 1 | In-process function call | Same Worker |\n| 2 | Repository access | D1/KV/R2/DO |\n| 3 | Service binding | Same-account Worker |\n| 4 | Queue | Async propagation |\n| 5 | External HTTP | Browser/SaaS boundary only |\n\n**Rule:** Worker-to-Worker HTTP on the same account is an anti-pattern.\n\n## Execution Components\n\n| Component | Purpose |\n|-----------|---------|\n| **Capability Registry** | Catalog of available capabilities |\n| **Capability Execution Engine** | Runs individual capability steps |\n| **Workflow Router / Engine** | Orchestrates multi-step flows |\n| **Context Builder** | Assembles execution context |\n| **Execution Orchestrator** | Coordinates step sequencing |\n| **Metrics and Learning** | Tracks execution quality |\n| **Capability Discovery UI** | Surfaces available capabilities |\n\n## Execution and Governance\n\nExecution applies governance at two points:\n\n1. **Pre-proposal:** Validate that the capability can be invoked\n2. **Pre-execution:** Re-validate governance with fresh policy\n\nThis prevents TOCTOU issues where policy changes between composition and execution.\n\n## Rollback\n\nIf execution fails:\n\n```text\nEXECUTION FAILED\n      ↓\nCHECK ROLLBACK AVAILABILITY\n      ↓\nEXECUTE ROLLBACK (if available)\n      ↓\nEMIT TIMELINE EVENT\n      ↓\nUPDATE WORK STATE\n      ↓\nNOTIFY USER\n```\n\n## Execution Receipt\n\nEvery execution produces a receipt:\n\n- **Capability invoked** — what was attempted\n- **Parameters used** — what was sent\n- **Result received** — what came back\n- **Timeline event emitted** — for audit\n- **Spine updated** — canonical state changed\n- **Projection refreshed** — user sees updated state\n\n## Related\n\n- [Capability Fabric](/architecture/CAPABILITY_FABRIC) — what capabilities are available\n- [Governance](/architecture/GOVERNANCE) — the policy boundary\n- [Reconciliation](/architecture/RECONCILIATION) — how execution results are verified\n- [Spine Schema](/architecture/SPINE_SCHEMA) — what is updated after execution\n"}