{"slug":"business/22-capability-fabric","title":"Capability Fabric","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/22-capability-fabric.mdx","bytes":3005,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nThe Capability Fabric translates available provider capabilities and platform features into actionable, governed, context-aware operations inside the Workbench.\n\nFor the canonical contract, see `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md` and `docs/architecture/CAPABILITY_FABRIC.md`.\n\n## Purpose\n\nThe Capability Fabric answers one question: what can be done, for this context, by this user, under this policy, using currently available connections?\n\nIt does not decide whether work should happen. It defines what is possible.\n\n## Capability resolution\n\nCapability resolution depends on:\n\n- active context type and entity relationships\n- user role and authority scope\n- organization policy\n- provider health and capability availability\n- required fields and current provider state\n- tenant feature policy\n\nWhen a required provider becomes unavailable, the Capability Fabric must disable related actions in the Workbench and explain why. Hidden capabilities are worse than disabled capabilities with explanations.\n\n## Unified capability abstraction\n\nThe fabric converts diverse provider capabilities into standard platform intents. A CRM record update, an email send, a ticket transition, and an internal workflow trigger may all surface as unified platform actions after capability resolution.\n\nThis is intentional. It keeps the Workbench coherent across providers without hiding provider-specific behavior entirely. Technical adapter details remain hidden unless deep troubleshooting requires them.\n\n## Execution lifecycle\n\nWhen a user initiates a capability:\n\n1. Capability Fabric resolves the applicable capabibility contract.\n2. Pre-Proposal Governance evaluates authority, scope, and policy.\n3. Plan Builder converts intent into an ExecutionPlan when needed.\n4. Post-Proposal Governance evaluates risk, evidence, confidence, and approval requirement.\n5. The Workbench previews the governed plan.\n6. The user approves when required.\n7. Hermes dispatches execution through the resolved runtime adapter.\n8. Sync reconciles the result.\n9. Promotion evaluates whether the result becomes canonical Spine truth.\n\n## Partner expectations\n\nPartners extending IntegrateWise capabilities should:\n\n- expose capability metadata, not just endpoints.\n- declare supported inputs, outputs, authority requirements, and evidence requirements.\n- define risk and governance policy for each capability shape.\n- support idempotency and retry without duplicating provider writes.\n- cleanly fail when context or authority is insufficient.\n\nDo not provide raw provider endpoints as one generic action surface. The Capability Fabric exists because generic surfaces are dangerous and confusing to operators.\n\n## Observability\n\nCapability Fabric activity should be observable in:\n\n- capability availability and health indicators\n- proposal creation and approval outcomes\n- execution plan states\n- sync and promotion outcomes\n- audit events that preserve actor, evidence, authority, and execution lineage\n"}