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