{"slug":"architecture/SPINE_DOMAIN","title":"Spine Domain — Platform-Level Three-Layer Model","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/SPINE_DOMAIN.mdx","bytes":31490,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Status:** Canonical architecture doctrine (supersedes previous SPINE_DOMAIN.md for scope)  \n> **Date:** July 6, 2026  \n> **Authority:** Nirmal (Founder)  \n> **Companion docs:** `SPINE_INTELLIGENCE_AGENT.md` (generation pipeline), `SPINE_MODEL.md` (physical storage), `PROJECTION_MODEL.md` (read views)  \n> **Platform specs:** 35-document hierarchy (Notion Document Hub) — 02 Operational Spine, 21 Business Ontology, 12 Entity Framework  \n> **Supersedes:** CRM-centric schema generation, domain-only models. When this doc contradicts a domain-specific approach, this doc wins.\n\n---\n\n## 0. The One-Line Truth\n\n```text\nThe Spine is the platform-level domain. Every business domain (Account Success, Sales, Finance, HR, Engineering) is a projection of the same Spine.\nThe agent builds the platform graph first. Domain artifacts are emissions from the platform graph, not separate schemas.\n```\n\n---\n\n## 1. The Platform-Level Entity Model\n\nThe platform defines **16 root concepts** (Business Ontology, Doc 21) + **7 operational primitives** (Operational Spine, Doc 02). Every concrete entity in every business domain inherits from one of these roots.\n\n### 1.1 The 16 Root Concepts (Business Ontology)\n\n| Root Concept   | Prefix  | What it is                          | Concrete types that inherit                                                       |\n| -------------- | ------- | ----------------------------------- | --------------------------------------------------------------------------------- |\n| `Organization` | `org_`  | Legal entity owning the tenant      | Tenant, Company, Division                                                         |\n| `Workspace`    | `wsp_`  | Bounded context inside Organization | Department, Team Workspace, Project Space                                         |\n| `Person`       | `usr_`  | First-class human                   | User, Contact, Lead, Stakeholder, Employee, CSM, AE                               |\n| `Team`         | `team_` | Durable grouping of Persons         | Sales Team, CS Team, Engineering Squad                                            |\n| `Process`      | `proc_` | Repeatable set of capabilities      | Sales Motion, Renewal Cycle, Incident Response, Onboarding Flow                   |\n| `Project`      | `prj_`  | Temporary initiative with timeline  | Sprint, Campaign, Launch, Migration, Implementation                               |\n| `Objective`    | `obj_`  | Measurable goal                     | KPI, OKR, North Star Metric, Strategic Objective                                  |\n| `Outcome`      | `out_`  | Evidence-verified result            | Closed Deal, Resolved Ticket, Published Article, Deployed Release, Renewal        |\n| `Asset`        | `ast_`  | Durable resource                    | Document, Code Repository, Design File, Data Source, Contract, Subscription       |\n| `Knowledge`    | `knw_`  | Curated institutional memory        | Playbook, Runbook, SOP, Template, Approved Pattern, Business Context              |\n| `Decision`     | `dec_`  | Governance-approved choice          | Approval, Rejection, Override, Prioritization Choice, Governance Token            |\n| `Policy`       | `pol_`  | Declarative rule                    | Confidence Policy, Data Scoping Policy, Approval Policy, Retention Policy         |\n| `Capability`   | `cap_`  | Declarable action on the fabric     | Draft Outreach, Sync Connector, Generate Report, Send Notification                |\n| `Signal`       | `sig_`  | Derived delta with score            | Health Alert, Risk Trigger, Anomaly Detection, Usage Spike                        |\n| `Memory`       | `mem_`  | Captured observation with lifecycle | Twin Memory, Intake, Triage, Evolution, Queue, Approved Memory, Knowledge Article |\n| `Conversation` | `conv_` | Twin ↔ User dialog                  | Chat Session, Brainstorming Session, QBR Meeting                                  |\n\n### 1.2 The 7 Operational Primitives (Operational Spine)\n\nThese are the runtime entities that make the Spine operational. They exist in every tenant, regardless of business domain.\n\n| Primitive       | Prefix | What it is                                       | Source                 |\n| --------------- | ------ | ------------------------------------------------ | ---------------------- |\n| `Tenant`        | `tnt_` | The top-level isolation boundary                 | Operational Spine (02) |\n| `Entity` (base) | `ent_` | Base type for all concrete entities              | Operational Spine (02) |\n| `Relationship`  | `rel_` | Directed, typed edge between entities            | Operational Spine (02) |\n| `Timeline`      | `tl_`  | Event-sourced append-only history                | Operational Spine (02) |\n| `Activity`      | `act_` | Unit of work within a Timeline                   | Operational Spine (02) |\n| `Evidence`      | `evd_` | Citation for any claim                           | Operational Spine (02) |\n| `Provenance`    | —      | Metadata on every row (actor, source, timestamp) | Operational Spine (02) |\n\n### 1.3 Domain-Specific Inheritance (Entity Framework)\n\nConcrete business types inherit from root concepts:\n\n```text\nEntity (base: id, version, lifecycle, provenance)\n├── AggregateEntity (typed by purpose)\n│     ├── CRMAccount     → inherits from Asset + Organization\n│     ├── CRMLead        → inherits from Person + Outcome\n│     ├── CRMOpportunity → inherits from Process + Outcome\n│     ├── Ticket         → inherits from Process + Outcome\n│     ├── Invoice        → inherits from Asset + Outcome\n│     ├── Contract       → inherits from Asset + Decision\n│     ├── Subscription   → inherits from Asset + Process\n│     ├── Product        → inherits from Asset + Knowledge\n│     ├── Deployment     → inherits from Asset + Project\n│     ├── Integration    → inherits from Capability + Process\n│     ├── Environment    → inherits from Asset + Workspace\n│     ├── Meeting        → inherits from Conversation + Process\n│     ├── Task           → inherits from Process + Outcome\n│     ├── Initiative     → inherits from Project + Objective\n│     ├── SuccessPlan    → inherits from Project + Knowledge\n│     └── ... (domain-extensible)\n└── ReferenceEntity\n      ├── User           → inherits from Person\n      ├── Product        → inherits from Asset + Knowledge\n      └── ...\n```\n\n### 1.4 Canonical entity families for a person and an organization\n\nThe Spine uses the same roots for both individuals and companies. The\ndifference is the projection, not the truth. A person’s daily life is represented\nby their identity, work, activities, relationships and memory graph. An\norganization or startup is the same model at a larger scale: it adds structure\naround teams, operations, product, revenue and governance.\n\nThese are the minimum entity families that should exist in the canonical\nmodel.\n\n#### Person / daily-life-work family\n\n| Family                  | Common concrete types                                 | What it captures                                         |\n| ----------------------- | ----------------------------------------------------- | -------------------------------------------------------- |\n| Identity and access     | Person, User, Workspace, Membership, Role, Permission | who the person is and what they can access               |\n| Daily work              | Task, Project, Objective, Outcome, Reminder           | work the person is doing and what is due                 |\n| Communications          | Conversation, Meeting, Message, Call, Email           | interaction history and context                          |\n| Knowledge and content   | Document, Note, Knowledge, File, Attachment           | durable content and reference material                   |\n| Calendar and scheduling | CalendarEvent, Meeting, Availability                  | time-based commitments and planning                      |\n| Network and context     | Contact, Relationship, Team, Organization             | people and groups around the person                      |\n| Activity and continuity | Activity, Timeline, Signal, Memory, Evidence          | what happened, what mattered, and why                    |\n| Personal operations     | Goal, Favorite, Preference, Expense                   | recurring personal/work preferences and management state |\n\n#### Organization / startup family\n\n| Family                   | Common concrete types                                                 | What it captures                                       |\n| ------------------------ | --------------------------------------------------------------------- | ------------------------------------------------------ |\n| Core structure           | Organization, Workspace, Department, Team, Membership                 | the legal and operating structure                      |\n| People and authority     | Person, Employee, Role, Permission, Policy                            | who works here and what they may do                    |\n| Execution                | Project, Process, Task, Objective, Outcome                            | what the organization is trying to achieve             |\n| Decision and governance  | Decision, Approval, Audit, Governance Token                           | who approved what and under which rule                 |\n| Product and delivery     | Product, Release, Deployment, Incident, Roadmap                       | what is shipped and how it behaves in production       |\n| Revenue and customer ops | Lead, Opportunity, Customer, Contract, Subscription, Invoice, Payment | commercial lifecycle and commercial truth              |\n| Connectivity             | Connector, Integration, Connection, Webhook, SyncJob                  | how the organization connects to external systems      |\n| Knowledge and continuity | Knowledge, Memory, Signal, Evidence, Timeline                         | learned context, institutional memory and traceability |\n| Communications           | Conversation, Meeting, Document, Note, Call, Email                    | operating communication and artifacts                  |\n\n#### Activities and events\n\nNot every event becomes a standalone truth object. In the Spine model:\n\n- `Activity` is the atomic unit of work or occurrence.\n- `Timeline` is the append-only history of those activities.\n- `Event` is usually the external or observed change that enters the Timeline.\n- `Signal` is the scored interpretation that emerges from the activity or event.\n- `Outcome` is the verified result after the activity is resolved.\n\nOnly durable business objects become canonical entities. Short-lived activity\nshould usually land as a Timeline entry, Evidence, Signal, or Memory unless the\ndomain needs a named durable object such as a Meeting, Task, Deployment or\nIncident.\n\n---\n\n## 2. The Three-Layer Model (Platform-Level)\n\n```text\n┌─────────────────────────────────────────────────────────────────────────────┐\n│                          PROJECTIONS (Domain Views)                        │\n│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │\n│  │ Account  │  │ Sales    │  │ Eng.     │  │ Finance  │  │ HR       │     │\n│  │ Success  │  │          │  │          │  │          │  │          │     │\n│  │          │  │ Pipeline │  │ Sprint   │  │ Revenue  │  │ Onboard  │     │\n│  │ Health   │  │ Deals    │  │ Tasks    │  │ Forecast │  │ Reviews  │     │\n│  │ Renewal  │  │ Forecast │  │ Blockers │  │ Budget   │  │ Teams    │     │\n│  │ QBR      │  │ Meetings │  │ PRs      │  │ Invoices │  │ Org      │     │\n│  │ Tasks    │  │ Contacts │  │ Standups │  │ Metrics  │  │ Payroll  │     │\n│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │\n│                              No duplicated tables                            │\n├─────────────────────────────────────────────────────────────────────────────┤\n│                        DYNAMIC MEMORY (AI-Created)                         │\n│  L1 Twin Memory  L2 Intake  L3 Triage  L4 Evolution  L5 Queue               │\n│  L6 Approval  L7 Org Memory  L8 Knowledge  Health  Risk  Sentiment        │\n│  Signals  Usage  Architecture  Tech Debt  Business Context  Engagement    │\n│  Stakeholder Intel  Recommendations  Insights  Evidence  Timeline  Forecast│\n│  These evolve continuously. They are derived from the Spine + external      │\n│  signals. They are not source of truth. They are opinion.                │\n├─────────────────────────────────────────────────────────────────────────────┤\n│                      CANONICAL SPINE (Immutable Business Truth)            │\n│  Organization  Person  Team  Process  Project  Objective  Outcome  Asset   │\n│  Knowledge  Decision  Policy  Capability  Signal  Memory  Conversation   │\n│  Tenant  Workspace  Entity  Relationship  Timeline  Activity  Evidence     │\n│  These rarely change structurally. They are the business truth.              │\n│  Every domain reads from the same Spine. The Projection Engine assembles     │\n│  domain-specific views.                                                      │\n└─────────────────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 3. Layer 1 — Canonical Spine (Platform-Level)\n\n### 3.1 What belongs here\n\nOnly entities that represent **real-world things** the platform operates on. These are the 16 root concepts + 7 operational primitives. Every concrete business type (CRMAccount, Ticket, Contract, etc.) inherits from one of these roots.\n\n### 3.2 Platform-level Spine rules\n\n1. **One canonical record per real-world thing.** A Salesforce Contact + a HubSpot Contact + a Jira Reporter = one `Person`.\n2. **Root concepts are universal.** `Person` in Account Success is the same `Person` in Sales and HR.\n3. **Domain types inherit from roots.** `CRMAccount` inherits from `Asset` + `Organization`. `Ticket` inherits from `Process` + `Outcome`.\n4. **Spine relationships are typed edges.** Not JSONB blobs. `Person` → `belongs_to` → `Team`. `Team` → `part_of` → `Organization`. `Process` → `uses` → `Capability` → `produces` → `Outcome`.\n5. **Spine entities are versioned.** Append-only. Every change is a new Timeline entry.\n6. **Spine entities are tenant-scoped.** Every table has `tenant_id`. Cross-tenant queries are impossible.\n7. **Spine writes are deterministic.** The Pipeline (`services/pipeline`) is the sole writer. No AI writes directly to the Spine.\n8. **Provenance is required.** Every row carries `provenance[]`: at least one of `{ actor, source_connector, evidence_ref, derived_signal }`.\n\n### 3.3 Canonical Spine Schema pattern\n\n```sql\n-- spine_persons (example; all Spine tables follow this pattern)\nCREATE TABLE IF NOT EXISTS spine_persons (\n    id              TEXT PRIMARY KEY,           -- UUID assigned by pipeline\n    tenant_id       TEXT NOT NULL,\n    canonical_id    TEXT NOT NULL,              -- stable identity; survives merges\n    version         INTEGER NOT NULL DEFAULT 1,  -- append-only versioning\n\n    -- Immutable business truth (typed columns, no JSONB)\n    name            TEXT NOT NULL,\n    email           TEXT,\n    role            TEXT,\n    department      TEXT,\n    seniority       TEXT,\n    is_primary_contact INTEGER DEFAULT 0,\n\n    -- System\n    provenance      JSON NOT NULL DEFAULT '{}', -- { source, record_id, actor }\n    created_at      INTEGER,                    -- Unix timestamp\n    updated_at      INTEGER                     -- Unix timestamp\n);\nCREATE INDEX IF NOT EXISTS idx_spine_persons_tenant_canonical\n    ON spine_persons(tenant_id, canonical_id);\nCREATE INDEX IF NOT EXISTS idx_spine_persons_tenant_version\n    ON spine_persons(tenant_id, canonical_id, version);\n```\n\n### 3.4 The typed edge graph (spine_relationships)\n\n```sql\nCREATE TABLE IF NOT EXISTS spine_relationships (\n    id              TEXT PRIMARY KEY,\n    tenant_id       TEXT NOT NULL,\n    from_canonical_id   TEXT NOT NULL,\n    from_type       TEXT NOT NULL,\n    relation_type   TEXT NOT NULL,          -- 'owns', 'belongs_to', 'depends_on', 'references', 'derived_from', 'supersedes', 'contested_by', 'uses', 'produces', 'has_state', 'part_of', 'measured_by', 'governs', 'constrained_by', 'informs', 'reinforces', 'generates', 'promotes_to'\n    to_canonical_id     TEXT NOT NULL,\n    to_type         TEXT NOT NULL,\n    metadata        JSON NOT NULL DEFAULT '{}', -- { weight, confidence, start_date, end_date }\n    valid_from      INTEGER,\n    valid_until     INTEGER,                -- NULL = current\n    created_at      INTEGER\n);\nCREATE INDEX IF NOT EXISTS idx_spine_rel_from\n    ON spine_relationships(tenant_id, from_type, from_canonical_id)\n    WHERE valid_until IS NULL;\nCREATE INDEX IF NOT EXISTS idx_spine_rel_to\n    ON spine_relationships(tenant_id, to_type, to_canonical_id)\n    WHERE valid_until IS NULL;\nCREATE INDEX IF NOT EXISTS idx_spine_rel_type\n    ON spine_relationships(tenant_id, relation_type)\n    WHERE valid_until IS NULL;\n```\n\n---\n\n## 4. Layer 2 — Dynamic Memory (Platform-Level)\n\n### 4.1 The 8-layer memory pipeline (Memory System, Doc 07)\n\n| Layer | Memory Type              | What it is                                                    | TTL        | Source                  |\n| ----- | ------------------------ | ------------------------------------------------------------- | ---------- | ----------------------- |\n| L1    | `twin_memory`            | Conversational working memory                                 | Session    | Twin Runtime            |\n| L2    | `memory_intake`          | Raw observations, immutable                                   | 24h        | Twin, Connector, Manual |\n| L3    | `memory_triage`          | Classification (fact/decision/observation/relationship/noise) | 7d         | Triage Bot              |\n| L4    | `memory_evolution`       | Pattern detection, cluster, dedupe                            | 14d        | Evolution Engine        |\n| L5    | `memory_promotion_queue` | Staging surface for human approval                            | 30d        | Promotion Queue         |\n| L6    | `memory_approval`        | Governance-approved or rejected memory                        | Persistent | Human Approval          |\n| L7    | `memory_organizational`  | Durable, indexed, queryable                                   | Persistent | L6 promotion            |\n| L8    | `memory_knowledge`       | SOPs, playbooks, runbooks                                     | Persistent | L7 + human authored     |\n\n### 4.2 Domain-specific memory types (derived from platform signals)\n\n| Memory                    | What it is                         | TTL        | Derived from                         |\n| ------------------------- | ---------------------------------- | ---------- | ------------------------------------ |\n| `memory_health`           | Account/entity health score        | 7d         | Usage, support, engagement, NPS      |\n| `memory_risk`             | Risk score + reasoning             | 14d        | Contract, usage, stakeholder changes |\n| `memory_sentiment`        | Emotional tone                     | 7d         | Transcripts, emails, support         |\n| `memory_signals`          | Detected anomalies                 | 1d         | Telemetry, webhooks, deltas          |\n| `memory_usage`            | Aggregated consumption             | 30d        | Telemetry, API logs                  |\n| `memory_architecture`     | Architecture posture               | 90d        | API inventory, topology              |\n| `memory_technical_debt`   | Technical liabilities              | 30d        | Tickets, post-mortems                |\n| `memory_business_context` | Synthesized business understanding | 30d        | Public data, earnings, news          |\n| `memory_engagement`       | Relationship history               | 30d        | Meetings, emails, calls              |\n| `memory_stakeholder`      | Stakeholder intelligence           | 14d        | Org chart, engagement                |\n| `memory_recommendations`  | Suggested actions                  | 7d         | Health + Risk + Engagement           |\n| `memory_insights`         | Generated findings                 | 7d         | Cross-signal synthesis               |\n| `memory_evidence`         | Supporting data for claims         | Persistent | Links, metrics, quotes               |\n| `memory_timeline`         | Projected events                   | 90d        | Contracts, renewals, initiatives     |\n| `memory_forecast`         | Predicted revenue/churn            | 30d        | ML models, historical patterns       |\n\n### 4.3 Memory rules (platform-level)\n\n1. **Memory is opinion, not truth.** Every memory has `confidence` (0.0–1.0) and `generated_by`.\n2. **Memory is ephemeral (except L6-L8).** Most memories have a TTL. Continuity Layer manages lifecycle.\n3. **Memory links to the Spine.** Every memory references a `canonical_id` + `entity_type` in the Spine.\n4. **Memory is graph-native.** The same `spine_relationships` pattern works for Memory edges.\n5. **Memory is event-sourced.** Every memory has an `episode_id` linking to the OODA cycle.\n6. **Memory is projection-friendly.** Memory is designed to be sliced by team, role, and time horizon.\n\n---\n\n## 5. Layer 3 — Projections (Domain-Specific Views)\n\n### 5.1 What a projection is\n\nA projection is a **declared view** over the Spine + Dynamic Memory. It is not a table. It is a configuration that tells the Projection Engine which entities, which memories, and which relationships to assemble for a given domain, team, role, and context.\n\n### 5.2 The projection principle\n\n```text\nNo domain has its own database. No domain has its own schema.\nEvery domain sees the same Spine. The Projection Engine assembles their view.\nAccount Success, Sales, Engineering, Finance, HR — all read from the same Spine.\n```\n\n### 5.3 Canonical projections for all business domains\n\n| Projection        | Consumer                  | Spine roots                                                                    | Memory types                                                  | Key relationships                                  |\n| ----------------- | ------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------- | -------------------------------------------------- |\n| `account-success` | CSM, Account Manager      | Person, Asset (Contract, Subscription), Process (Task), Conversation (Meeting) | Health, Risk, Engagement, Timeline, Insights, Recommendations | Person↔Asset, Process↔Person, Conversation↔Person  |\n| `sales`           | AE, SDR, Sales Manager    | Person, Process (Opportunity), Outcome (Deal), Asset (Contract)                | Forecast, Pipeline, Engagement, Insights                      | Person↔Process, Process↔Outcome, Asset↔Outcome     |\n| `engineering`     | IC, Engineering Manager   | Person, Project (Sprint), Asset (Code), Process (Task), Knowledge              | Architecture, Usage, Technical Debt, Signals                  | Person↔Project, Project↔Asset, Asset↔Process       |\n| `executive`       | VP, CRO, CFO              | Organization, Asset, Process, Outcome                                          | Health, Risk, Forecast, Revenue, Business Context             | Organization↔Asset↔Process↔Outcome                 |\n| `finance`         | Finance Manager, CFO      | Asset (Invoice, Contract), Outcome (Revenue), Decision, Policy                 | Forecast, Budget, Metrics, Compliance                         | Asset↔Outcome, Decision↔Policy, Asset↔Decision     |\n| `hr`              | HRBP, CHRO                | Person, Team, Process (Onboarding), Knowledge (SOP), Decision                  | Engagement, Metrics, Timeline, Insights                       | Person↔Team, Team↔Process, Process↔Knowledge       |\n| `support`         | Support Engineer, Manager | Person, Asset (Product, Deployment), Process (Ticket), Outcome (Resolution)    | Cases, Errors, Incidents, SLA, Usage                          | Person↔Asset, Asset↔Process, Process↔Outcome       |\n| `implementation`  | Onboarding Manager        | Person, Project, Process (Task), Objective                                     | Milestones, Timeline, Signals, Business Context               | Project↔Process, Process↔Person, Project↔Objective |\n| `marketing`       | Marketing Manager         | Person, Project (Campaign), Asset (Content), Outcome (Lead)                    | Engagement, Insights, Metrics, Timeline                       | Project↔Asset, Asset↔Outcome, Project↔Person       |\n| `operations`      | Ops Manager               | Process, Policy, Decision, Knowledge, Outcome                                  | Metrics, Compliance, Timeline, Insights                       | Process↔Policy, Decision↔Policy, Knowledge↔Process |\n\n---\n\n## 6. Cross-Layer Rules\n\n### 6.1 Write path\n\n```text\nConnector / Webhook / MCP / API / Manual\n        ↓  (Loader → Normalizer → Entity Resolution)\nPipeline (Spine Writer)  ──writes──▶  Canonical Spine (append-only)\n        ↓  (Signal loop: Think → HITL → Act → Pipeline)\nIntelligence Agent  ──generates──▶  Dynamic Memory (ephemeral, opinionated)\n        ↓  (read-only assembly at query time)\nProjection Engine  ──assembles──▶  Projections (views, never stored)\n```\n\n### 6.2 Read path\n\n```text\nUser / Twin / API\n        ↓\nProjection Engine  ──reads──▶  Canonical Spine (stable truth)\n                      ──reads──▶  Dynamic Memory (current opinion)\n                      ──reads──▶  spine_relationships (typed graph)\n        ↓\nAssembly  ──returns──▶  TypedProjectionResult (JSON, never SQL directly to UI)\n```\n\n### 6.3 The No-Duplication Contract\n\n- **No domain has its own table.** If Account Success and Sales both need `Person`, they read from the same `spine_persons` table.\n- **No memory is duplicated per domain.** If CSM and Sales both need `Health`, they read the same `memory_health` record.\n- **No projection is materialized.** Projections are computed at query time.\n\n---\n\n## 7. From Domain-Specific to Platform-Level\n\n### Old Account Success model → New platform model\n\n| Old domain-specific          | New platform-level                                              | Mapping                                               |\n| ---------------------------- | --------------------------------------------------------------- | ----------------------------------------------------- |\n| `spine_accounts`             | `spine_organizations` + `spine_assets` (Contract, Subscription) | Account = Organization + Asset                        |\n| `spine_people`               | `spine_persons`                                                 | Same entity, now universal                            |\n| `spine_business_context`     | `memory_business_context`                                       | Memory layer, opinion                                 |\n| `spine_strategic_objectives` | `spine_objectives`                                              | Objective root concept                                |\n| `spine_capabilities`         | `memory_architecture`                                           | Memory layer, assessed                                |\n| `spine_api_portfolio`        | `spine_integrations` (Capability + Asset)                       | Integration inherits from Capability + Asset          |\n| `spine_platform_metrics`     | `memory_usage` + `memory_signals`                               | Derived metrics, not raw facts                        |\n| `spine_initiatives`          | `spine_projects`                                                | Project root concept                                  |\n| `spine_technical_debt`       | `memory_technical_debt`                                         | Memory layer, opinionated                             |\n| `spine_stakeholder_outcomes` | `memory_stakeholder`                                            | Memory layer, derived                                 |\n| `spine_engagements`          | `memory_engagement` + `spine_conversations`                     | Conversation is real; engagement depth is derived     |\n| `spine_success_plans`        | Projection + `spine_objectives` + `spine_projects`              | Plan = projection of objectives + projects + timeline |\n| `spine_insights`             | `memory_insights`                                               | Memory layer, ephemeral                               |\n\n---\n\n## 8. Source-of-Truth Index\n\n| Concept                      | Authoritative source                            |\n| ---------------------------- | ----------------------------------------------- |\n| Three-layer model (this doc) | `docs/architecture/SPINE_DOMAIN.md`             |\n| 16 root concepts             | `docs/platform-specs/21-business-ontology.md`   |\n| Operational Spine            | `docs/platform-specs/02-operational-spine.md`   |\n| Entity Framework             | `docs/platform-specs/12-entity-framework.md`    |\n| Capability Fabric            | `docs/platform-specs/05-capability-fabric.md`   |\n| Memory System                | `docs/platform-specs/07-memory-system.md`       |\n| Twin Runtime                 | `docs/platform-specs/06-twin-runtime.md`        |\n| Connector Framework          | `docs/platform-specs/08-connector-framework.md` |\n| Governance Engine            | `docs/platform-specs/09-governance-engine.md`   |\n| Signal Engine                | `docs/platform-specs/10-signal-engine.md`       |\n| Workflow Engine              | `docs/platform-specs/11-workflow-engine.md`     |\n| Agent pipeline               | `docs/architecture/SPINE_INTELLIGENCE_AGENT.md` |\n| Physical storage             | `docs/architecture/SPINE_MODEL.md`              |\n| Projection engine            | `docs/architecture/PROJECTION_MODEL.md`         |\n| 35-document hierarchy        | Notion Document Hub                             |\n\n---\n\n_The Spine is the platform. Domains are views. The graph is the product. When in doubt — halt, ask Nirmal._\n"}