{"slug":"strategy/business-strategy/ONBOARDING_TO_SYNC_SPECIFICATION","title":"Surface Boundary Note","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/ONBOARDING_TO_SYNC_SPECIFICATION.mdx","bytes":3593,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"## Surface Boundary Note\n\n- The User Workbench is one projection-native surface.\n- Twin is silent and contextual; it is not a sidebar or separate Workbench.\n- Governance is a shared platform module and the hard gate before execution or\n  promotion.\n- Neon is the Canonical Spine/Fortress. D1/KV are bounded Operational Spine\n  state; R2 stores evidence.\n- Flow C remains cognitive staging until governance and human approval promote\n  eligible knowledge or memory candidates.\n- Department, industry and role configure projections and availability; they\n  never create tenant storage partitions.\n\n---\n\n# Onboarding to Sync Specification\n\n## Tenant Onboarding Flow\n\n```\nSignup → Clerk Identity → Tenant Created → Role/Industry/Department Configuration → Connector OAuth\n    ↓\nProjection/Profile Resolution → Tenant Spine Config\n    ↓\nConnector Connected → Flow D Binding → Flow A/B/C Classification → Initial Hydration\n    ↓\nBounded Initial Load → Pipeline → Operational Spine → Promotion → Canonical Spine\n    ↓\nProjection Engine → Workbench → Silent Twin Available\n```\n\n## Step 1: Tenant Creation\n\n- Spine DB auth creates user\n- `provision_tenant_spine` RPC creates tenant record\n- Tenant bucket computed: B0 (no data)\n\n## Step 2: Projection Profile Selection\n\n- User selects department (CS, Sales, BizOps, etc.)\n- Optional: industry selection (SaaS, Healthcare, etc.)\n- Role is resolved from tenant membership and RBAC.\n- `role × industry × department` selects projection definitions, connectors,\n  KPIs, fields and capabilities.\n- The tenant-level entity schema does not change or partition by department.\n\n## Step 3: Connector OAuth\n\n- User selects connector from IntegrationsHub (filtered by domain)\n- OAuth flow: `/api/v1/connectors/:provider/authorize`\n- Callback: tokens encrypted and stored\n- Flow classified: A (structured), B (context), C (AI)\n\n## Step 4: Initial Hydration\n\n### Flow A/B: Creamy Sync\n\n```\ntriggerInitialConnectorHydration(env, tenantId, provider)\n  → Loader extracts 30 days of data\n  → Pipeline queue receives records\n  → 8-stage normalizer processes each\n  → Spine-v2 writes to schema-routed tables\n  → Tenant bucket: B0 → B2 (creamy done)\n```\n\n### Flow C: D1 Buffer\n\n```\ninitializeD1Buffer(tenantId, provider, env)\n  → D1 buffer created for AI source\n  → Triage rules applied\n  → Approved content → Triage Bot review → approved knowledge\n  → Tenant bucket stays at current level\n```\n\n## Step 5: Progressive Hydration (B0 → B7)\n\n| Bucket | Trigger          | What Happens                  |\n| ------ | ---------------- | ----------------------------- |\n| B0→B1  | Domain selected  | Schema resolved               |\n| B1→B2  | Creamy sync done | 30 days of data in Spine      |\n| B2→B3  | Full sync done   | Complete historical data      |\n| B3→B4  | Flow B connected | Context (emails, docs) linked |\n| B4→B5  | Signals active   | Twin triggers start firing    |\n| B5→B6  | Flow C active    | AI memory feeding Entity 360  |\n| B6→B7  | All layers       | Full cognitive capability     |\n\n## Sync Entitlements by Plan\n\n| Plan         | Sync Interval | Max Records/Sync | Connectors | Delta Sync |\n| ------------ | ------------- | ---------------- | ---------- | ---------- |\n| Free         | 24h           | 1,000            | 1          | Yes        |\n| Starter      | 4h            | 5,000            | 3          | Yes        |\n| Professional | 1h            | 25,000           | 10         | Yes        |\n| Enterprise   | 15min         | 100,000          | Unlimited  | Yes        |\n"}