{"slug":"business/EXECUTION_CONSTITUTION","title":"Execution Constitution","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/EXECUTION_CONSTITUTION.mdx","bytes":3339,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: SUPERSEDED / ABSORBED — historical subsystem constitution. Current authority: [`INTEGRATEWISE_ARCHITECTURE.md`](INTEGRATEWISE_ARCHITECTURE.md) v2.2.\nScope: Execution lifecycle, plan compilation, adapter dispatch, rollback, side effects, and sync.\nCanonical Owner: IntegrateWise Platform\nLast Verified: 2026-07-20\n\n---\n\n## 1. Purpose\n\nThis document defines how IntegrateWise executes governed capabilities.\n\nExecution commits canonical state first. Sync is independent.\n\n---\n\n## 2. Lifecycle\n\n```text\nUser Initiates Capability\n        │\n        ▼\nGate 1: Pre-Proposal\n        │\n        ▼\nPending Approval\n        │\n        ▼\nUser Approves\n        │\n        ▼\nGate 2: Execution\n        │\n        ▼\nSpine Sync\n        │\n        ▼\nProjection Refresh\n```\n\n---\n\n## 3. 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---\n\n## 4. Step Contract\n\n```typescript\ninterface ExecutionStep {\n  capability: CapabilityId;\n  adapter: AdapterId;\n  params: Record<string, unknown>;\n  rollback: CapabilityId | null;\n}\n```\n\n---\n\n## 5. 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.\n5. On failure, execute rollback step if defined.\n\n---\n\n## 6. Side Effects\n\n- Timeline entry\n- Notification\n- Evidence record\n- Memory promotion candidate\n\n---\n\n## 7. Sync Behavior\n\n- Sync is asynchronous.\n- Sync failures do not invalidate execution success.\n- Sync status is surfaced explicitly.\n- Retry uses exponential backoff.\n\n---\n\n## 8. Service Ownership (Amendment 7 & 8)\n\n**WorkService** owns human operational work:\n\n- Commands: CreateTask, UpdateTask, AssignWork, CompleteWork, ReopenWork, RouteQueueItem\n- Storage: tasks, work_items, assignments, queues, task_dependencies\n- Events: work.created, work.assigned, work.started, work.completed, work.blocked\n\n**ExecutionService** owns machine execution:\n\n- Storage: capability_invocations, provider dispatch attempts, execution status,\n  provider acceptance, retry state\n- Does not own: tasks, work_items, assignments (those belong to WorkService)\n\n**CapabilityService** owns capability definitions:\n\n- Storage: capability_registry, capability_grants, capability dependencies, capability schemas\n- Does not own: capability_invocations (those belong to ExecutionService)\n\nCapabilityService validates what may execute. ExecutionService records and manages\nthe actual execution. WorkService tracks human work independently.\n\n---\n\n## 9. Invariants\n\n1. Execution never writes directly to external systems before Spine commit.\n2. Every execution plan is immutable after approval.\n3. Every step has a defined rollback path.\n4. Every execution emits an outcome event.\n5. Every event is published through the transactional outbox (Amendment 6).\n6. Every consumer is idempotent via the processed_commands table (Amendment 5).\n7. Provider acceptance is never presented as completed work until reconciliation\n   confirms the expected outcome (Amendment 9).\n"}