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