Current

Tenant Lifecycle Schema Register

Status: current derived implementation register
Date: 2026-07-28
Authority chain: ARCHITECTURE_LOCK.md → CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md → SPINE_ENTITY_TABLE_SCHEMA.md → TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md → APP_CATEGORY_ENTITY_DOMAIN_CLASSIFICATION.md → migrations/037_pure_entity_spine_tables.sql + migrations/038_tenant_lifecycle_entity_tables.sql + migrations/039_tenant_network_scope_and_promotion_flow.sql + migrations/040_scope_global_events_provenance_and_evidence.sql + migrations/041_app_category_entity_domain_classification.sql

Purpose

This document corrects the modeling direction explicitly:

tenant-level schema
→ entity-based tables
→ lifecycle/event-driven truth
→ RBAC projections
→ no department-based physical schema

Department, industry, and role can affect what a user sees, but they do not
get their own storage schema families. The physical truth model is tenant
scoped.

Non-negotiable storage rule

The platform uses one shared public schema.
tenant_id is the storage isolation boundary for tenant-owned truth.
workspace_id can narrow context, but it never replaces tenant_id.
Department is a projection/filter attribute only. It is not a partition key.
Every durable entity family belongs to its own table.
Views such as home, inbox, accounts, renewals, roadmap, finance,
and governance are projections over entity, work, event, memory, and
policy tables.
Human approval remains the promotion gate from operational memory and agent
memory into governed Fortress truth.

Canonical grouping keys

For tenant-owned durable rows, use the following grouping logic:

Concern	Canonical key
Tenant boundary	`tenant_id`
Tenant operating account	`tenant_account_id`
Tenant Spine Network	`spine_network_id`
Workspace context	`workspace_id`
Durable identity	`canonical_id`
Version lineage	`version`
External connector binding	`connector_binding_id`
Provider connection lineage	`spine_connection_id`
User/actor responsibility	`owner_user_id`, `assigned_user_id`, `submitted_by_user_id`, or equivalent role field

Important clarification:

Use spine_network_id as the canonical tenant network grouping key.
Use spine_connection_id only as the lineage of one connector/provider connection.
Do not create a separate department schema.
Do not create per-department copies of the same business entity.

Common entity envelope

Every tenant-scoped durable entity table should follow this shape:

Column class	Required	Meaning
`tenant_id`	yes	storage and policy boundary
`tenant_account_id`	yes for new writes	the tenant root account; distinct from a customer/business `account_id`
`spine_network_id`	yes for new writes	the tenant's Spine Network grouping key
`app_category`	yes through entity classification	connector/source category that originated the entity
`business_domain`	yes through entity classification	RBAC classification; never a department table family
`lifecycle_stage`	yes through entity classification	cross-domain signal, playbook and projection routing key
`workspace_id`	recommended	active workspace scope
`<entity>_id`	yes	opaque stable row identity
`canonical_id`	yes	dedupe/merge/projection identity
`version`	yes	mutable truth lineage
`status`	yes	current operating state
`lifecycle_stage`	recommended	the current lifecycle step for that entity family
ownership fields	recommended	user/person responsible for the record
connector lineage	optional but preferred for imported rows	`connector_binding_id`, `spine_connection_id`
provenance	yes	`source_class`, `confidence`, `provenance_jsonb`
metadata	yes	`metadata_jsonb` for additive attributes
timestamps	yes	`created_at`, `updated_at` and entity-specific dates

Tenant lifecycle stages

1. Identity and membership

This stage establishes who the tenant is, which users belong to it, and what
authority they have.

Primary tables:

spine_organizations
spine_users
spine_memberships
spine_user_roles
spine_role_permissions
spine_policies

Primary surfaces:

onboarding
organizations
users
roles
permissions
security
profile

Lifecycle events:

tenant.created
workspace.created
membership.granted
membership.revoked
role.assigned
permission.changed

2. Activation and connector consent

This stage binds the tenant to approved external systems.

Primary tables:

spine_connector_catalog
spine_connectors
spine_activation_runs
spine_mcp_routes
spine_model_registry
approved connector-binding runtime records (connector_binding_id, spine_connection_id)

Primary surfaces:

connector-marketplace
integration-manager
activation-hub
data-sources
integrations
capabilities
platform-health

Lifecycle events:

connector.selected
connector.authorized
connector.binding.validated
schema.discovered
activation.started
activation.completed

3. External intake and communication

This stage captures inbound activity before it becomes work, knowledge, or
memory.

Primary tables:

spine_events
spine_messages
spine_calendar_events
spine_meetings
spine_calls
spine_documents
spine_document_chunks
spine_source_links
spine_evidence

Primary surfaces:

activity-feed
email
calendar
meetings
calls
documents-shared

Lifecycle events:

message.ingested
meeting.recorded
call.completed
document.ingested
artifact.linked

4. Triage, continuity, and organizational memory

This stage turns raw activity into governed context.

Primary tables:

spine_timeline_events
spine_signals
spine_memory_items
spine_memory_promotions
spine_agent_context_windows
spine_agent_memory
spine_continuity_runs
spine_continuity_checks
brainstorm_sessions
brainstorm_messages
brainstorm_ideas
brainstorm_canvas_states
brainstorm_decisions
brainstorm_insights
spine_knowledge_items
spine_canvas_documents

Primary surfaces:

triage / chat hub
brainstorming
notes
knowledge
knowledge-base
memory-continuity
organizational memory / company wiki projection

Lifecycle events:

signal.detected
memory.candidate.created
memory.promotion.requested
memory.promoted
brainstorm.session.started
knowledge.promoted

5. Operational work and execution

This is the main user-facing SSOT of day-to-day work.

Primary tables:

spine_work_items
spine_commitments
spine_work_queues
spine_tasks
spine_projects
spine_objectives
spine_outcomes
spine_approvals
spine_decisions
spine_favorites
spine_projection_views

Primary surfaces:

home
inbox
tasks
my-queue
approvals
notifications
recent-work
favorites
projects
task-manager

Lifecycle events:

work.created
work.assigned
work.blocked
approval.requested
approval.granted
outcome.verified

6. Commercial and customer lifecycle

This stage holds customer, pipeline, revenue, billing, and renewal truth.

Primary tables:

spine_accounts
spine_leads
spine_opportunities
spine_subscriptions
spine_invoices
spine_renewals
spine_contracts
spine_budgets
spine_expenses
spine_billing_ledger

Primary surfaces:

accounts
account-master
account-health
at-risk
contacts
renewals
pipeline
deals
forecast
quota
revenue
invoices
invoice-approvals
reports
forecasting
budget
finance-manager

Lifecycle events:

lead.captured
opportunity.opened
opportunity.won
invoice.issued
invoice.paid
renewal.risk.detected
renewal.completed

7. Product, delivery, and operating systems lifecycle

This stage covers product engineering, service delivery, operations, and
systems.

Primary tables:

spine_processes
spine_workflows
spine_tickets
spine_incidents
spine_products
spine_features
spine_releases
spine_sprints
spine_assets
spine_meetings

Primary surfaces:

roadmap
features
bugs
sprints
releases
incidents
feedback
architecture
data-flow
systems
vulnerabilities
certificates
licenses
tickets
sla
sessions

Lifecycle events:

workflow.started
ticket.opened
incident.detected
feature.prioritized
release.shipped
sprint.closed

8. Vendor, procurement, and partner lifecycle

This stage models external spend and supply-side relationships.

Primary tables:

spine_vendors
spine_orders
spine_contracts
spine_expenses
spine_accounts (for partners/clients where needed)

Primary surfaces:

vendors
orders
contracts
spend
savings
spend-insights
partnerships

Lifecycle events:

vendor.added
order.placed
contract.renewal_due
expense.submitted
expense.approved

9. Governance, security, billing, and observability

This stage is the tenant’s hard control plane.

Primary tables:

spine_policies
spine_audit_log
spine_security_events
spine_capabilities
spine_capability_executions
spine_pipeline_runs
spine_observability_signals
spine_deployments
spine_api_keys

Primary surfaces:

governance
observability
audit
billing
deployments
api-keys
security
pipelines
automation
ai-models
mcp-pool

Lifecycle events:

policy.evaluated
execution.authorized
execution.failed
pipeline.completed
security.signal.raised
deployment.promoted

Entity families required by the current view inventory

The current UI inventory implies the following tenant-level entity families.

Already present in the typed Spine

Entity family	Table
Person / stakeholder / employee / contact identity	`spine_persons`
Team	`spine_teams`
Process	`spine_processes`
Project / initiative	`spine_projects`
Objective / OKR	`spine_objectives`
Outcome	`spine_outcomes`
Asset / system / file	`spine_assets`
Signal / insight / risk	`spine_signals`
Conversation	`spine_conversations`
Activity	`spine_activities`
Timeline container	`spine_timelines`
Task	`spine_tasks`
Meeting	`spine_meetings`

Added for tenant lifecycle completeness

Entity family	Table
Account / client / customer / company record	`spine_accounts`
Lead	`spine_leads`
Opportunity / deal	`spine_opportunities`
Campaign	`spine_campaigns`
Workflow / automation definition	`spine_workflows`
Ticket / case	`spine_tickets`
Incident	`spine_incidents`
Subscription	`spine_subscriptions`
Invoice	`spine_invoices`
Renewal	`spine_renewals`
Vendor	`spine_vendors`
Contract	`spine_contracts`
Order / purchase	`spine_orders`
Product / SKU / offering	`spine_products`
Feature	`spine_features`
Release	`spine_releases`
Sprint	`spine_sprints`
Budget	`spine_budgets`
Expense	`spine_expenses`

Projection rule

The frontend does not own truth tables for each sidebar item. It renders RBAC
and context scoped projections over these families.

Projection inputs:

tenant identity and membership
allowed entity families
current work items and approvals
related messages, meetings, docs, and evidence
continuity and memory
allowed capabilities
current governance posture

Projection outputs:

tables
record pages
editable canvases
timelines
Twin-ready contextual payloads

The product runtime contract is still projection-first:

Gateway event / query
→ tenant + RBAC resolution
→ projection composition
→ frontend workbench state
→ user action
→ governed command
→ backend write / execution
→ projection invalidation and rehydrate

Promotion boundary

Draft operational-memory and agent-memory records can originate in the Product
surface, but persistent truth promotion still follows:

Workbench draft / agent output
→ Triage classification
→ human review / approval
→ governed Spine write
→ projection rehydrate

This preserves the rule that AI proposes and humans approve.

Source reconciliation notes

While reviewing the imported view inventory, two inconsistencies matter:

domain-route-manifest.ts includes cs-accounts-hub, while
domain-view-registry.tsx currently exposes csm-accounts-hub.
global navigation uses triage, while the backend surface map still uses
chat for the brainstorming/triage surface family.

These are naming inconsistencies, not reasons to create new tables. The schema
should stay semantic and tenant-level.

Appendix A — current view inventory grouped into tenant lifecycle meaning

Global tenant surfaces

Identity / control:
home, organizations, users, roles, permissions, security,
audit, billing, deployments, api-keys
Work:
inbox, tasks, my-queue, approvals, notifications,
recent-work, favorites
Communications:
activity-feed, email, calendar, meetings, triage, calls,
documents-shared
Personal / memory:
notes, drafts, brainstorming, my-files
Platform:
integration-manager, connector-marketplace, activation-hub,
capability-manager, mcp-pool, ai-models, knowledge,
memory-continuity, automation, pipelines, governance,
observability

Account-success views

Commercial + customer success lifecycle:

dashboard
cs-today
cs-accounts-hub / csm-accounts-hub
cs-account-detail
cs-contacts
cs-meetings
intelligence-center
accounts
account-master
account-health
at-risk
contacts
account-team
people-team
renewals
success-plans
risk-matrix
risk-register
engagement-log
meetings
initiatives
strategic-objectives
stakeholder-outcomes
business-context
projects
tasks
task-manager
documents
capabilities
platform-health
value-streams
insights
company-growth
strategic-account-success
calendar

BizOps views

Cross-tenant command, planning, operations, and integration lifecycle:

dashboard
bizops-today
command-center
operations-center
strategic-hub
strategy-leadership
sales-hub
founder-ops
ceo
coo
cio-cto
business-intelligence
human-resources
legal-compliance
knowledge-management
partnerships
crm
accounts
clients
tasks
calendar
documents
workflows
integrations
metrics
analytics
governance
cockpit
data-sources
iq-hub

Finance views

dashboard
revenue
expenses
invoices
invoice-approvals
reports
forecasting
budget

IT admin views

dashboard
systems
incidents
vulnerabilities
certificates
licenses
admin
settings
data-flow

Marketing views

dashboard
campaigns
leads
email
social
blog
website
forms
attribution
analytics
content

Personal views

dashboard
home
today
founder-today
founder-projects
founder-decisions
knowledge
bookmarks
focus
wealth
wellness
learning
relationships
whats-new
brainstorming
profile
insights

Procurement views

dashboard
vendors
orders
contracts
renewals
spend
savings
spend-insights

Product-engineering views

dashboard
roadmap
features
bugs
sprints
tasks
releases
incidents
feedback
analytics
architecture
data-flow
projects

RevOps views

dashboard
pipeline
forecast
quota
cohorts
team
metrics
analytics
pending-review
decision-log

SalesOps views

dashboard
pipeline
deals
contacts
activities
sequences
analytics
sales-hub
clients
client-detail

Service views

dashboard
tickets
customers
knowledge
csat
sla
analytics
sessions

Student-teacher views

dashboard
students
courses
assignments
gradebook
at-risk

Bottom line

The schema root is not department.

The schema root is:

tenant
→ entity family
→ lifecycle state
→ event history
→ governed projection