Canon

Connector Schema & Capability Continuity 6.1

Dynamic schema discovery, versioned mapping plane, and capability projection over external connectors.

Universal Connector Mapping Specification

Status: Canonical downstream implementation specification

1. Purpose

The connector architecture needs a distinct semantic mapping plane.

The connector answers:

How do I communicate with the provider?

The mapping answers:

What does this provider object and field mean to the business?

The Spine answers:

What is the canonical business state?

Capability Fabric answers:

What can a human or AI do with that state?

Continuity answers:

What happened and what must remain known for the next worker?

2. Universal Connector Contract

Every connector contributes:

Provider
  ├── category
  ├── authentication
  ├── connection
  ├── source objects
  ├── source fields
  ├── events
  ├── sync
  ├── capabilities
  └── health

Every connector must expose:

connection_status
health
scopes
objects
fields
events
sync_policy
mapping_profile
capability_profile
provenance_policy
revocation

3. 12-Stage Semantic Install

1. Discover provider
2. Discover objects
3. Discover fields/events
4. Classify source objects
5. Match canonical objects
6. Match canonical fields
7. Define transformations
8. Resolve identity/relationships
9. Test sample records
10. Activate sync + write policy
11. Hydrate + verify
12. Activate projection/capabilities

No connector is considered fully active before hydration and verification.

4. Provider Object Classes

IDENTITY
BUSINESS_ENTITY
ACTIVITY
COMMUNICATION
DOCUMENT
TRANSACTION
FINANCIAL
WORK_ITEM
PRODUCT
ENGINEERING
ANALYTICS
PLATFORM

Provider-specific objects are classified before mapping.

5. Mapping Precedence

Tenant source-of-authority
        ↓
Object mapping
        ↓
Field mapping
        ↓
Transformation
        ↓
Identity resolution
        ↓
Relationship resolution
        ↓
Conflict policy
        ↓
Provenance
        ↓
Governed promotion

6. Conflict States

Canonical fields can have:

resolved
source_conflict
stale
unverified
missing
invalid
pending_promotion

The system must not silently choose a value where a tenant policy requires resolution.

7. Capability Generation

Once an object mapping is activated, the connector may contribute capabilities.

Example:

Salesforce Account
    ↓
Account canonical object
    ↓
Account projection
    ↓
Capabilities:
    retrieve_account
    prepare_account_brief
    update_account
    create_followup
    schedule_review

The connector does not own the business capability. Capability Fabric registers the provider route behind the capability.

8. KPI Activation

Mappings can declare KPI contributions.

Example:

Stripe.Subscription
    ↓
Subscription.mrr
    ↓
MRR KPI
    ↓
Revenue projection

Salesforce.Opportunity.Amount
    ↓
Opportunity.amount
    ↓
Pipeline KPI
    ↓
Forecast projection

9. Signal Activation

Mappings can also provide signal inputs.

Example:

Zendesk Ticket.sla_due_at
Ticket.status
Ticket.priority
       ↓
SLA state
       ↓
sla_breach signal
       ↓
Support Work

10. Connector Revocation

Revocation must stop authorized access and execution without deleting the organization's historical canonical record.

After revocation:

Connection
→ revoked
→ sync stops
→ capabilities depending on route become unavailable
→ cached credentials invalidated
→ existing canonical state retained according to retention policy
→ freshness degrades visibly
→ projections expose stale state where relevant
→ audit retained

11. Connector Independence

A model change must not change the Spine.

A connector replacement must not change canonical business meaning.

A capability route change must not change the Work identity.

A UI projection change must not change canonical truth.

This gives:

Provider independence
Model independence
UI independence
Agent independence
Execution-route independence

while retaining organizational continuity.