{"slug":"canonical/06-CONNECTOR-SCHEMA-CAPABILITY-CONTINUITY-6.1","title":"Connector Schema & Capability Continuity 6.1","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/06-CONNECTOR-SCHEMA-CAPABILITY-CONTINUITY-6.1.md","bytes":4391,"description":"Dynamic schema discovery, versioned mapping plane, and capability projection over external connectors.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n## Universal Connector Mapping Specification\n\n**Status:** Canonical downstream implementation specification\n\n## 1. Purpose\n\nThe connector architecture needs a distinct semantic mapping plane.\n\nThe connector answers:\n\n> How do I communicate with the provider?\n\nThe mapping answers:\n\n> What does this provider object and field mean to the business?\n\nThe Spine answers:\n\n> What is the canonical business state?\n\nCapability Fabric answers:\n\n> What can a human or AI do with that state?\n\nContinuity answers:\n\n> What happened and what must remain known for the next worker?\n\n---\n\n## 2. Universal Connector Contract\n\nEvery connector contributes:\n\n```text\nProvider\n  ├── category\n  ├── authentication\n  ├── connection\n  ├── source objects\n  ├── source fields\n  ├── events\n  ├── sync\n  ├── capabilities\n  └── health\n```\n\nEvery connector must expose:\n\n```text\nconnection_status\nhealth\nscopes\nobjects\nfields\nevents\nsync_policy\nmapping_profile\ncapability_profile\nprovenance_policy\nrevocation\n```\n\n---\n\n## 3. 12-Stage Semantic Install\n\n```text\n1. Discover provider\n2. Discover objects\n3. Discover fields/events\n4. Classify source objects\n5. Match canonical objects\n6. Match canonical fields\n7. Define transformations\n8. Resolve identity/relationships\n9. Test sample records\n10. Activate sync + write policy\n11. Hydrate + verify\n12. Activate projection/capabilities\n```\n\nNo connector is considered fully active before hydration and verification.\n\n---\n\n## 4. Provider Object Classes\n\n```text\nIDENTITY\nBUSINESS_ENTITY\nACTIVITY\nCOMMUNICATION\nDOCUMENT\nTRANSACTION\nFINANCIAL\nWORK_ITEM\nPRODUCT\nENGINEERING\nANALYTICS\nPLATFORM\n```\n\nProvider-specific objects are classified before mapping.\n\n---\n\n## 5. Mapping Precedence\n\n```text\nTenant source-of-authority\n        ↓\nObject mapping\n        ↓\nField mapping\n        ↓\nTransformation\n        ↓\nIdentity resolution\n        ↓\nRelationship resolution\n        ↓\nConflict policy\n        ↓\nProvenance\n        ↓\nGoverned promotion\n```\n\n---\n\n## 6. Conflict States\n\nCanonical fields can have:\n\n```text\nresolved\nsource_conflict\nstale\nunverified\nmissing\ninvalid\npending_promotion\n```\n\nThe system must not silently choose a value where a tenant policy requires resolution.\n\n---\n\n## 7. Capability Generation\n\nOnce an object mapping is activated, the connector may contribute capabilities.\n\nExample:\n\n```text\nSalesforce Account\n    ↓\nAccount canonical object\n    ↓\nAccount projection\n    ↓\nCapabilities:\n    retrieve_account\n    prepare_account_brief\n    update_account\n    create_followup\n    schedule_review\n```\n\nThe connector does not own the business capability. Capability Fabric registers the provider route behind the capability.\n\n---\n\n## 8. KPI Activation\n\nMappings can declare KPI contributions.\n\nExample:\n\n```text\nStripe.Subscription\n    ↓\nSubscription.mrr\n    ↓\nMRR KPI\n    ↓\nRevenue projection\n\nSalesforce.Opportunity.Amount\n    ↓\nOpportunity.amount\n    ↓\nPipeline KPI\n    ↓\nForecast projection\n```\n\n---\n\n## 9. Signal Activation\n\nMappings can also provide signal inputs.\n\nExample:\n\n```text\nZendesk Ticket.sla_due_at\nTicket.status\nTicket.priority\n       ↓\nSLA state\n       ↓\nsla_breach signal\n       ↓\nSupport Work\n```\n\n---\n\n## 10. Connector Revocation\n\nRevocation must stop authorized access and execution without deleting the organization's historical canonical record.\n\nAfter revocation:\n\n```text\nConnection\n→ revoked\n→ sync stops\n→ capabilities depending on route become unavailable\n→ cached credentials invalidated\n→ existing canonical state retained according to retention policy\n→ freshness degrades visibly\n→ projections expose stale state where relevant\n→ audit retained\n```\n\n---\n\n## 11. Connector Independence\n\nA model change must not change the Spine.\n\nA connector replacement must not change canonical business meaning.\n\nA capability route change must not change the Work identity.\n\nA UI projection change must not change canonical truth.\n\nThis gives:\n\n```text\nProvider independence\nModel independence\nUI independence\nAgent independence\nExecution-route independence\n```\n\nwhile retaining organizational continuity.\n"}