{"slug":"architecture/SPINE_ENTITY_TABLE_SCHEMA","title":"Spine Entity Table Schema","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/SPINE_ENTITY_TABLE_SCHEMA.mdx","bytes":10941,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** additive implementation guide for the pure entity-table Spine  \n**Date:** 2026-07-28  \n**Authority chain:** `ARCHITECTURE_LOCK.md` → `CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md` → `CANONICAL_SPINE_SCHEMA_FOUNDATION.md` → `TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md`\n\n## Purpose\n\nThis document closes the gap between:\n\n- the canonical `spine_entities` identity kernel;\n- the strongly typed entity-domain rule requested for IntegrateWise; and\n- the Workbench requirement that RBAC projections read from durable entity\n  tables rather than inventing sidebar-shaped truth tables.\n\nThe rule is now explicit:\n\n```text\none shared public schema\n→ tenant-scoped rows\n→ one durable entity family per table\n→ RBAC projections compose those tables\n```\n\nThe tenant-level lifecycle extension register is:\n\n- [TENANT_LIFECYCLE_SCHEMA_REGISTER.md](/Users/nirmal/Github/integratewise-live/docs/architecture/TENANT_LIFECYCLE_SCHEMA_REGISTER.md)\n- [TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md](/Users/nirmal/Github/integratewise-live/docs/architecture/TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md)\n- [APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md](/Users/nirmal/Github/integratewise-live/docs/architecture/APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md)\n\n## Canonical storage rule\n\n- Every durable entity family belongs to its own table.\n- `tenant_id` is mandatory on tenant-owned rows.\n- `tenant_account_id` and `spine_network_id` are mandatory on new\n  tenant-owned writes. They identify the tenant operating account and its\n  IW-Spine-Network.\n- every entity scope binding carries a versioned `app_category`,\n  `business_domain` and `lifecycle_stage` classification; domain is RBAC, not\n  a department-specific schema boundary.\n- `workspace_id` may narrow context, but never replaces `tenant_id`.\n- department is a projection attribute, not a physical schema boundary.\n- `spine_entities.id` / the domain entity identifier is the stable continuity\n  anchor. `canonical_id` remains the provider-neutral dedupe, merge, lineage\n  and projection identity where a typed entity family uses it.\n- `connector_binding_id` and `spine_connection_id` preserve the lineage of a\n  particular provider connection. `spine_network_id` groups the whole tenant\n  network; a connection ID cannot replace it.\n- Projections are read contracts. They never become truth tables.\n\n## User SSOT\n\nThe user does not come to IntegrateWise to inspect raw storage categories like\n`teams`, `projects`, `assets`, and `signals` as isolated nouns.\n\nThe user comes to:\n\n- manage work;\n- move business objectives through state;\n- understand what needs attention now;\n- approve, delegate, complete, or unblock actions; and\n- see the business context required to do that work well.\n\nSo the user-facing source of truth is split deliberately:\n\n| Concern                           | SSOT                                                                           | Why it exists                                                                        |\n| --------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |\n| Identity of the user              | `spine_users` + `spine_memberships`                                            | who the user is, which tenant/workspace they belong to, and what authority they have |\n| Operational work of the user      | `spine_work_items` + work dependencies + approvals + notifications + decisions | the primary action ledger for what the user is here to do                            |\n| Business context behind that work | typed entity tables + relationships + knowledge + promoted memory + evidence   | the facts, records, and continuity that explain the work                             |\n\nProduct rule:\n\n```text\nuser opens Workbench\n→ sees work, priorities, approvals, blockers, conversations, and outcomes\n→ opens supporting entity context only when it helps complete the work\n```\n\nThat means `spine_persons`, `spine_projects`, `spine_assets`, `spine_teams`,\nand similar tables are supporting truth families. They are not the primary\nreason the user opens the product.\n\n## Typed entity tables\n\nThe live additive migration is:\n\n- [037_pure_entity_spine_tables.sql](/Users/nirmal/Github/integratewise-live/migrations/037_pure_entity_spine_tables.sql)\n- [038_tenant_lifecycle_entity_tables.sql](/Users/nirmal/Github/integratewise-live/migrations/038_tenant_lifecycle_entity_tables.sql)\n- [039_tenant_network_scope_and_promotion_flow.sql](/Users/nirmal/Github/integratewise-live/migrations/039_tenant_network_scope_and_promotion_flow.sql)\n- [040_scope_global_events_provenance_and_evidence.sql](/Users/nirmal/Github/integratewise-live/migrations/040_scope_global_events_provenance_and_evidence.sql)\n- [041_app_category_entity_domain_classification.sql](/Users/nirmal/Github/integratewise-live/migrations/041_app_category_entity_domain_classification.sql)\n\nIt introduces these typed entity tables:\n\n| Entity family | Table                 | Purpose                                                 |\n| ------------- | --------------------- | ------------------------------------------------------- |\n| Person        | `spine_persons`       | Durable person/contact/employee/customer identity       |\n| Team          | `spine_teams`         | Organizational and working groups                       |\n| Process       | `spine_processes`     | Repeatable operational flows                            |\n| Project       | `spine_projects`      | Time-bounded initiatives and workstreams                |\n| Objective     | `spine_objectives`    | Goals and measurable targets                            |\n| Outcome       | `spine_outcomes`      | Verified results and completions                        |\n| Asset         | `spine_assets`        | Durable resources, files, systems, artifacts            |\n| Signal        | `spine_signals`       | Scored or detected meaningful deltas                    |\n| Conversation  | `spine_conversations` | Durable communication threads                           |\n| Activity      | `spine_activities`    | Atomic work/activity records                            |\n| Timeline      | `spine_timelines`     | Subject-centric event history containers                |\n| Task          | `spine_tasks`         | Day-to-day actionable work                              |\n| Meeting       | `spine_meetings`      | Scheduled or completed meeting records                  |\n| Account       | `spine_accounts`      | Customer, client, partner, or commercial account truth  |\n| Lead          | `spine_leads`         | Early-stage commercial interest and qualification state |\n| Opportunity   | `spine_opportunities` | Deals, pipeline, and forecastable commercial motion     |\n| Campaign      | `spine_campaigns`     | GTM campaigns and attributed spend/revenue context      |\n| Workflow      | `spine_workflows`     | Durable operational and automation definitions          |\n| Ticket        | `spine_tickets`       | Service/support issue records                           |\n| Incident      | `spine_incidents`     | Operational or system incident records                  |\n| Subscription  | `spine_subscriptions` | Recurring commercial contract instances                 |\n| Invoice       | `spine_invoices`      | Billing documents and revenue recognition state         |\n| Renewal       | `spine_renewals`      | Renewal-specific risk, stage, and forecast records      |\n| Vendor        | `spine_vendors`       | Procurement and external supplier records               |\n| Contract      | `spine_contracts`     | Commercial and procurement agreement truth              |\n| Order         | `spine_orders`        | Purchase and fulfillment records                        |\n| Product       | `spine_products`      | Product or SKU catalog truth                            |\n| Feature       | `spine_features`      | Roadmap / delivery feature records                      |\n| Release       | `spine_releases`      | Release train and shipment truth                        |\n| Sprint        | `spine_sprints`       | Time-boxed engineering delivery windows                 |\n| Budget        | `spine_budgets`       | Finance planning and variance records                   |\n| Expense       | `spine_expenses`      | Spend and reimbursement records                         |\n\n## Existing platform tables that remain part of the canonical model\n\nThese already existed in the consolidated Fortress migration and remain valid:\n\n| Concern                        | Existing table(s)                                                                                      |\n| ------------------------------ | ------------------------------------------------------------------------------------------------------ |\n| Tenant / organization identity | `spine_organizations`, `spine_workspaces`, `spine_users`, `spine_memberships`                          |\n| Relationships                  | `spine_relationships`, `spine_relationship_versions`                                                   |\n| Provenance / evidence          | `spine_provenance`, `spine_evidence_links`                                                             |\n| Governance / decisions         | `spine_decisions`, `governance_policies`, approvals/tokens/audit tables                                |\n| Knowledge / memory             | `knowledge_documents`, `knowledge_chunks`, `memory_items`, `memory_versions`, `memory_promotion_queue` |\n| Connector network              | connector catalog, installations, connections, schemas, sync, MCP binding tables                       |\n\n## Kernel and typed-domain boundary\n\n`spine_entities` is not an untyped replacement for all domain data and is not\nlegacy infrastructure. It is the canonical identity, classification, version\nand continuity kernel. A typed entity table owns the strongly typed current\nstate for a stable business entity family and links back to that kernel.\n\nUse this rule going forward:\n\n- a durable entity has a kernel identity plus a typed-domain home when its\n  lifecycle merits strongly typed fields and constraints;\n- provider-specific identifiers remain in source/provenance mapping, not in a\n  provider-named business table;\n- projections join the kernel, typed entities, relationships, work and\n  governance state, then apply RBAC. They never bypass the kernel with a raw\n  table read.\n\n## Workbench rule\n\nThe Workbench stays projection-based:\n\n```text\ntyped entity tables\n+ relationships\n+ knowledge / memory\n+ governance state\n+ connector/network availability\n→ Projection Engine\n→ RBAC-scoped Workbench views, pages, tables, and canvases\n```\n\nThere is no canonical `home`, `inbox`, `view-1`, or `finance-manager` truth\ntable. Those surfaces stay projections over typed entities.\n"}