IntegrateWise Universal Tenant Spine Schema v1
Authoritative schema source · reconciled with Book of Record v1.1
AUTHORITATIVE SCHEMA SOURCE — reconciled 2026-07-28
This page remains the authoritative Universal Tenant Spine Schema source. Its interpretation is constrained by the current Book of Record: the Base Spine is mandatory and stable; tenant, domain and provider models are additive; provenance, tenant scope and reconciliation are required.
For V0 runtime, Cloudflare D1 is the tenant Spine system of record. Frontend and AI clients access Spine data only through versioned Platform query and projection contracts.
Core Principle
One Spine. One schema. Every role, department, and industry is a projection over the same core. The mandatory Base Spine remains stable; additive extensions and schema versions evolve through governance. Only what each user sees changes — based on Role × Industry × Department.
The governing principle: The Spine holds the truth. The Projection shapes what each user sees. The schema variation lives entirely in the projection layer — not in the data layer.
Spine as Multi-Store Fabric
| Layer | Store | Purpose |
|---|---|---|
| L1 | PostgreSQL / D1 | Structured operational truth. The SSOT anchor. |
| L2 | Redis / KV | Hot state. Sub-100ms. Working memory. Not truth. |
| L3 | R2 / Object Storage | Blobs linked by reference. Never queried directly. |
| L4 | Conversational Store | Raw channel events. Classify → Extract → Promote. |
| L5 | Vectorize / pgvector | Semantic intelligence. Hybrid cosine + BM25 + RRF. |
| L6 | Agent Memory (Durable Objects) | Durable per-scope state. HITL-gated writes. |
Shared Tenant Spine Domains
| Domain | Core Tables | Owned By |
|---|---|---|
| Identity Spine | tenants, users, teams, roles, permissions, policies | Platform Admin |
| Entity Spine | customers, contacts, accounts, projects, products, assets, vendors, employees | All roles (scoped) |
| Work Spine | tasks, work_items, queues, approvals, assignments, escalations, slas | All roles (scoped) |
| Communication Spine | email_threads, calendar_events, meetings, chat_threads, calls | All roles (scoped) |
| Knowledge Spine | documents, notes, knowledge_base, brainstorm_sessions, learning_artifacts | All roles (scoped) |
| Memory Spine | user_memory, work_memory, org_memory, conversation_memory, agent_memory | Platform (HITL-gated) |
| Capability Spine | connectors, mcp_tools, apis, ai_models, automations, pipelines | Integration Manager |
| Governance Spine | approval_records, audit_log, security_events, compliance_records, policies | Platform Admin |
| Platform Spine | billing_records, deployments, api_keys, observability_events, admin_actions | Platform Admin |
12 Department Projections
Each department is a governed projection over the shared Spine. See individual schema files for complete table definitions, 6-layer maps, KV patterns, R2 paths, conversational store documents, vector collections, agent memory scopes, workbench zone maps, and write paths.
| Department | Spine Domains Used | Schema File |
|---|---|---|
| Account Success | Entity + Work + Communication + Knowledge + Memory | docs/spine/account-success.md |
| Sales | Entity + Work + Communication + Knowledge | docs/spine/sales.md |
| Marketing | Entity + Communication + Knowledge + Work | docs/spine/marketing.md |
| Revenue Operations | Entity + Work + Governance | docs/spine/revops.md |
| Finance | Entity + Work + Governance + Platform | docs/spine/finance.md |
| Operations / Business Ops | Work + Entity + Governance | docs/spine/operations.md |
| Product & Engineering | Work + Capability + Knowledge + Governance | docs/spine/product-engineering.md |
| Support & Service | Entity + Work + Communication + Knowledge | docs/spine/support.md |
| IT & Security | Identity + Entity + Work + Governance | docs/spine/it-security.md |
| HR & People Ops | Identity + Entity + Work + Knowledge | docs/spine/hr-people.md |
| Legal & Compliance | Entity + Work + Governance + Knowledge | docs/spine/legal-compliance.md |
| Founder / Executive Ops | All domains (read-only aggregate) | docs/spine/founder-executive.md |
Industry Extensions
The mandatory Base Spine remains stable across industries; governed industry extensions are additive.
| Industry | Entity Extensions | Signal Extensions |
|---|---|---|
| SaaS | subscription, mrr, churn_risk, expansion_signal | usage_drop, renewal_risk, expansion_ready |
| Aerospace Manufacturing | program, satellite, subsystem, assembly_step, test_result | milestone_slip, quality_hold, supplier_delay |
| Healthcare | patient, provider, appointment, claim, compliance_record | missed_appointment, billing_error, compliance_flag |
| Professional Services | engagement, deliverable, timesheet, invoice, retainer | scope_creep, budget_overrun, delivery_risk |
| Logistics | shipment, route, carrier, warehouse, manifest | delay_risk, customs_hold, capacity_alert |
Write Paths
Channel Event (any source)
-> Conversational Store (append)
-> 8-Stage Pipeline: Ingest -> Parse -> Classify -> Extract -> Enrich -> Route -> Govern -> Promote
-> D1 canonical write (role-scoped tables)
-> KV/cache invalidation (affected keys)
-> Vector re-embedding (affected collections)
-> Twin memory update proposal (if memory-worthy)
User Action (workbench)
-> Governance check
-> Projection Platform API write
-> Webhook / ADK write-back to source system
-> KV/cache invalidation
-> Signal Platform: evaluate if action resolves a signal
Twin Proposal (AI-generated)
-> Governance Platform: create pending approval record
-> Workbench: render approval card to user
-> User approves -> D1 canonical write with approved_by + approval_id
-> User rejects -> audit log write, no Spine write
-> Provenance preserved forever: origin, confidence, approved_by, approved_at
Governance Rules
- No workbench component may read directly from a database. All reads go through the Projection Platform API.
- No AI-proposed write lands in the Spine without HITL approval.
- Provenance is immutable. A Twin-proposed entry that passes approval arrives tagged
origin: twin, confidence: 0.xx. It does not become native truth. - Every operational table carries the Universal Record Envelope: id, tenant_id, workspace_id, status, version, origin, confidence, source_connection_id, provenance, metadata, created_by, updated_by, created_at, updated_at, archived_at.
Canonical Implementation Companion
See docs/SPINE_SCHEMA_V1_ALL_DEPARTMENTS.md for:
- Shared record envelope
- Twelve department projections with complete table definitions
- Platform projections
- Customer Zero seed manifest
- Projection API contract
- Work-Bench wiring rules
- Acceptance criteria
Customer Zero
Tenant: tnt_integratewise_customer_zero
Primary workspace: wsp_integratewise_ops
Industry: b2b_saas_continuity_platform
Governance posture: approval_first
13 workspaces, 10 users, 12 roles, 12-20 connectors, 25 accounts, 60 contacts, 20 leads, 12 deals, 20 projects, 80 tasks, 40 threads, 50 documents, 30 signals, 12 proposals, 8 pending approvals, 30 memory items, 10 deployments, 5 incidents, 100 audit events.