Canon
Spine Schema & Business Context Standard
Architectural standard for tenant org, departmental, and domain-based schema design: Account as universal anchor, cross-domain interaction contracts, and fixed base with adaptive growth.
1. Executive Summary
This standard defines the rules, invariants, and architectural contracts for creating and evolving the IntegrateWise Business Context Spine Schema.
The fundamental requirements are:
- Tenant Organization Standard: Multi-tenant isolation at the root; tenant-level governance and departmental sub-scopes.
- Domain-Based Architecture: Strict functional domain boundaries (Revenue/Sales, Customer Success, Customer Support, Product & Engineering, Finance & Billing, Communications, AI & Execution).
- The Universal Anchor: The Account is the fixed, immutable gravitational center connecting all domains. Domains do not connect via ad-hoc spaghetti links; they link through the Account hub.
- Inter-Domain Interaction Contracts: Formally defined interaction and event propagation rules across domains (e.g. Support ticket escalations cascading into CS churn risk and Revenue renewal forecasts).
- Fixed Base + Adaptive Adaptations: The base schema is invariant and fixed. Connectors and tools dynamically introduce domain extensions, custom fields, and new KPIs without ever mutating, breaking, or invalidating the base schema contracts.
2. Structural Hierarchy: Tenant, Department, Domain
TENANT ORG (Root Partition)
│
┌─────────────────────────┴─────────────────────────┐
▼ ▼
DEPARTMENT: REVENUE DEPARTMENT: PRODUCT
(Sales, RevOps, Pipeline) (Eng, Roadmap, Releases)
│ │
└─────────────────────────┬─────────────────────────┘
▼
UNIVERSAL ANCHOR: ACCOUNT
(Gravitational Center)
│
┌───────────┬───────────┬──────┴────┬───────────┬───────────┐
▼ ▼ ▼ ▼ ▼ ▼
REVENUE CS SUPPORT PRODUCT FINANCE COMMS
(Deals) (Health) (Tickets) (Issues) (Invoices) (Slack)
2.1 Tenant Organization Boundary
- Every record in the Spine is scoped to an immutable
tenant_id. - Tenant boundaries are strictly isolated: no cross-tenant query, cross-tenant foreign key, or cross-tenant vector search is permitted.
2.2 Departmental Scopes & Lenses
Departments represent the functional operating units within an organization:
- Revenue / Sales: Focuses on pipelines, deal stages, quotas, close dates, win/loss.
- Customer Success: Focuses on onboarding milestones, adoption, product utilization, health score, churn risks.
- Customer Support: Focuses on incident response, ticket SLAs, escalation paths, bug verifications.
- Product & Engineering: Focuses on user feedback, feature requests, backlog prioritization, release deployments.
- Finance & Billing: Focuses on ARR/MRR, contract terms, billing cycles, invoice status, collections.
- Executive & Operations: Focuses on blended KPIs, organizational efficiency, capital allocation.
Departments do not own private databases. They operate on projections composed over the shared Business Context Spine.
3. The Universal Anchor: Account
3.1 Why Account is the Universal Center
In B2B business operations, every transaction, communication, problem, and dollar ultimately relates to an Account (Customer or Prospect).
If systems link to each other peer-to-peer (e.g. Zendesk linking directly to Jira, Jira to Stripe, Stripe to Salesforce), the result is an unmaintainable $N \times M$ integration tangle.
In IntegrateWise, all domains link to the Account anchor:
ACCOUNT
┌──────────────────┼──────────────────┐
▼ ▼ ▼
CRM / SALES CUSTOMER SUCCESS SUPPORT
• Deals • Health Score • Tickets
• Contacts • Milestones • Incidents
• Opportunities • Risk Signals • Escalations
▲ ▲ ▲
│ │ │
└──────────────────┼──────────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
PRODUCT & ENG FINANCE & BILLING COMMS & CONTEXT
• Feature Requests • Subscriptions • Email Threads
• Bug Reports • Invoices • Slack Channels
• Adoption Metrics • ARR / MRR • Call Transcripts
3.2 Invariant Base Account Schema
The base Account schema is fixed and immutable across all tenants:
| Field | Type | Invariant Rule | Description |
|---|---|---|---|
id | UUID | Immutable Primary Key | Canonical Spine entity ID |
tenant_id | UUID | Immutable Partition Key | Tenant organization boundary |
name | String | Required | Legal or operating account name |
domain | String | Required for Deduplication | Primary web domain (e.g. acme.com) |
lifecycle_stage | Enum | Required State Machine | lead | opportunity | customer | churned | partner |
external_ids | Record<string, string> | Fixed System Mapping | Pointers to source tools (salesforce_id, hubspot_id, zendesk_id, stripe_id, etc.) |
kpis | BaseAccountKPIs | Guaranteed Computation | arr, mrr, health_score, open_tickets_count, active_users |
relations | BaseDomainRelations | Standard Foreign Refs | Arrays of IDs referencing deals, tickets, invoices, contacts, and issues |
extensions | Record<string, DomainExtension> | Adaptive Extension Bag | Namespace-isolated slot for dynamic connector fields |
3.3 Exhaustive Multi-Domain KPI Inventory
The Account Base Schema and the Enterprise KPI Catalog enforce 70+ governed business metrics across 6 functional dimensions at the Account anchor:
- Revenue & Commercial:
arr,mrr,contract_value(TCV),pipeline_open_value,win_probability,expansion_potential_value,days_to_renewal,sales_cycle_days,pipeline_velocity,average_deal_size.
- Customer Success & Health:
health_score(0-100),health_category(champion/healthy/at_risk/critical),health_trend,churn_risk_score,gross_churn_rate,net_churn_rate,logo_retention_rate,time_to_first_onboarding_milestone,csat_score.
- Customer Support & Service:
open_tickets_count,unresolved_critical_incidents(P0/P1),avg_resolution_time_hrs,first_response_sla_breached_count,customer_effort_score,first_contact_resolution_rate,ticket_reopen_rate.
- Product Usage & Adoption:
active_users_30d(MAU),active_users_7d(WAU),dau_to_mau_ratio,license_utilization_rate,product_adoption_rate,key_workflow_completions_30d,time_to_adopt_new_feature_days.
- Finance & Commercial Billing:
payment_status,overdue_invoice_count,total_overdue_amount,days_sales_outstanding(DSO),payment_method_valid,gross_margin_percent,quick_ratio,deferred_revenue.
- Engagement & Contextual Memory:
net_promoter_score,last_activity_date,days_since_last_interaction,meeting_count_30d,slack_message_volume_30d,executive_sponsor_engaged,champion_identified,sentiment_score_30d.
4. Inter-Domain Interaction Contracts
Domains do not operate in silos. An event in one domain cascades context into other domains through the Account hub.
4.1 Canonical Interaction Flow: Support to Renewal Cascade
1. SUPPORT DOMAIN:
High-priority ticket logged (Zendesk)
Ticket status = "Open" for 14 days
│
▼
2. ACCOUNT ANCHOR:
Account.open_tickets_count increments
Account.support_sla_breached = true
Account.health_score recalculates (drops from 85 -> 48)
│
├─────────────────────────────────────────┐
▼ ▼
3. CUSTOMER SUCCESS DOMAIN: 4. REVENUE DOMAIN:
Emits Signal: "CS_CHURN_RISK_HIGH" Emits Signal: "RENEWAL_SLIPPAGE_RISK"
Creates Task: "CSM Executive Reachout" Updates Forecast: Deal probability drops 20%
4.2 Interaction Rules Matrix
| Triggering Domain | Event / Trigger | Account-Level Action | Cascading Domain Impact |
|---|---|---|---|
| Customer Support | P0 Ticket Opened | Increments unresolved_critical_incidents | CS: Flags churn warning; Comms: Alerts Slack channel |
| Product & Engineering | Feature Shipped | Updates shipped_requested_features | CS: Notifies waiting contacts; Support: Closes backlog tickets |
| Finance & Billing | Invoice Overdue > 30d | Sets payment_status = "overdue" | Revenue: Blocks expansion quotes; CS: Alerts CSM |
| Customer Success | Product Usage Drops 30% | Decrements health_score | Revenue: Flags renewal risk; AI: Drafts recovery proposal |
| Communications | Executive Sponsor Leaves | Sets executive_sponsor_id = null | CS: Triggers stakeholder re-mapping workflow |
5. Fixed Base + Adaptive Adaptations (Schema Growth)
5.1 The Principle of Schema Growth vs Schema Freeze
- Schema Freeze is rigid and fails because every business has unique tools, custom CRM fields, and industry-specific metrics.
- Schema Drift is chaotic and fails because uncontrolled custom fields break standardized queries, projections, and AI models.
- IntegrateWise Solution: Fixed Base + Adaptive Extensions.
┌─────────────────────────────────────────────────────────────────┐
│ FIXED BASE SCHEMA (INVARIANT) │
│ • Account Name, Domain, Lifecycle, Owner │
│ • Standard External IDs (CRM, Support, Billing) │
│ • Core Enterprise KPIs (ARR, Health Score, Ticket Count) │
│ • Canonical Domain Relations (Deals, Tickets, Invoices) │
└───────────────────────────────┬─────────────────────────────────┘
│
▼ Adaptive Extensions (Namespace-Isolated)
┌───────────────────────────────┴─────────────────────────────────┐
│ ADAPTIVE CONNECTOR & DOMAIN EXTENSIONS │
│ • "gong:call_intelligence": { sentiment: 0.82, competitors: [] }│
│ • "mixpanel:usage_telemetry": { weekly_queries: 420 } │
│ • "salesforce:custom_fields": { custom_tier__c: "Platinum" } │
└─────────────────────────────────────────────────────────────────┘
5.2 Extension Invariants
- Namespace Isolation: Every extension must be namespaced by connector or domain (e.g.
gong:call_summary,hubspot:custom_properties). - Non-Colliding Keys: An extension can NEVER overwrite, mask, or redefine a fixed base field. Attempting to do so triggers a validation rejection.
- Additive-Only: Adding an extension must not invalidate existing queries or cached projections.
- Metadata & Provenance: Every extension field carries provenance metadata (source connector, timestamp, confidence score, raw payload reference).
6. Implementation Checklist
- Base Account Schema: Typed immutable core fields with cross-system external ID maps.
- Domain Schemas: Base definitions for Revenue, CS, Support, Product, Finance, Communications, AI.
- Inter-Domain Interaction Registry: Formal event and signal routing across domains via Account.
- Adaptive Schema Manager: Runtime validator ensuring base schema invariance during connector discovery.
- Vitest Test Suite: Unit tests verifying invariance, cross-domain cascading, and non-colliding extensions.