Unclassified

IntegrateWise Spine Schema — v1

Status: Canonical Specification
Milestone: Clean State Milestone 1
Date: July 22, 2026
Authority: Nirmal (Founder)

Purpose

This document is the canonical Spine specification.

It defines the logical model only. Physical storage may be PostgreSQL + JSONB + pgvector/Vectorize, but that remains an implementation detail below this layer.

All workbenches, projections, capabilities, connectors, and UI renderers must derive from this specification.

Model

Spine v1
├── Entity Model
├── Relationship Model
├── Operational Memory
├── Continuity
├── Knowledge
├── Events
├── Embeddings
├── Search
├── Governance
└── Workbench Definitions

Storage Model

Logical Spine Schema
│
▼
Storage Providers
├── PostgreSQL
├── JSONB
├── Vector
├── Object Storage
├── Cache
└── Search Index

Default implementation:

PostgreSQL + JSONB
pgvector / Cloudflare Vectorize
Redis Cache
R2 Object Storage

Each canonical entity is composed of:

Entity
├── Structured  → SQL columns
├── Flexible    → JSONB
├── Semantic    → Embedding(s)
└── Operational → Timeline, Signals, Evidence

Entity Envelope

Every canonical entity uses a common envelope:

{
  canonical_id,
  entity_type,
  tenant_id,
  version,
  status,
  scope,
  data,
  relationships,
  metadata,
  provenance,
  timeline
}

canonical_id — stable global identifier
entity_type — one of the canonical root concepts
tenant_id — ownership boundary
version — append-only version
status — draft, active, archived, suppressed
scope — visibility/access context
data — flexible payload
relationships — typed edges
metadata — created/updated tracking
provenance — source system and confidence
timeline — operational history

Root Concepts

The 16 canonical root concepts are stable and must not change in v1:

Root Concept	Prefix	Description
Organization	`org_`	Legal entity owning the tenant
Workspace	`wsp_`	Bounded context inside Organization
Person	`usr_`	First-class human
Team	`team_`	Durable grouping of Persons
Process	`proc_`	Repeatable set of capabilities
Project	`prj_`	Temporary initiative with timeline
Objective	`obj_`	Measurable goal
Outcome	`out_`	Evidence-verified result
Asset	`ast_`	Durable resource
Knowledge	`knw_`	Curated institutional memory
Decision	`dec_`	Governance-approved choice
Policy	`pol_`	Declarative rule
Capability	`cap_`	Declarable action on the fabric
Signal	`sig_`	Derived delta with score
Memory	`mem_`	Captured observation with lifecycle
Conversation	`conv_`	Twin ↔ User dialog

Relationship Model

Relationships are first-class typed edges.

source_id
target_id
relationship_type
valid_from
valid_until
metadata
confidence

Relationships are adaptively valid per tenant, department, industry, and governance policy.

Operational Primitives

Seven operational primitives remain stable:

Tenant
Entity
Relationship
Timeline
Activity
Evidence
Provenance

Events

Events are append-only operational deltas emitted from canonical writes.

created
updated
status_changed
linked
unlinked
promoted
governed
approved
rejected
suppressed

Events drive:

real-time subscriptions
webhook notifications
audit trails
AI observations

Continuity

The Spine persists state beyond session boundaries.

Continuity operations:

spine.context(tenantId)
spine.continuity(sessionId)
spine.remember(memory)
spine.hydrate(entityId)

Continuity enables:

cross-session Twin context
long-running workflows
operational memory
handoff and recovery

Knowledge

Knowledge is derived from Spine, not raw external state.

Promotion gate: evidence → knowledge
Lineage tracking
Deprecation rules
Confidence scoring

Schema AI, ingestion pipelines, and memory consolidation all consume the Spine as the canonical source.

Embeddings

Embeddings are first-class for every canonical entity.

Entity
├── Structured → SQL columns
├── Flexible   → JSONB
├── Semantic   → Embedding(s)
└── Operational→ Timeline, Signals, Evidence

Embedding behavior is governed by field semantics:

include: true/false
model: text-embedding-3-small | ...
scope: public | private | tenant
update: on_write | on_read | scheduled

Default storage target: pgvector or Cloudflare Vectorize.

Search

Search is derived from:

structured fields
JSONB fields
embeddings
relationships
timeline/events

Search indexes are role/projection-aware.

Governance

Governance lives inside the Spine model, not around it.

Policy is a canonical entity
Decision is a canonical entity
Evidence is a canonical entity
Approval, rejection, and suppression are Spine operations
Signals carry confidence and governance state

Two-gate governance applies to:

capabilities
schema changes
connector registrations
promotion from evidence to knowledge

Workbench Definitions

Workbenches are role-specific projections over the same canonical Spine.

Canonical Spine
    │
    ├── Founder Projection
    ├── Sales Projection
    ├── Customer Success Projection
    ├── Marketing Projection
    ├── Finance Projection
    ├── Operations Projection
    └── Engineering Projection

A workbench definition declares:

entities to expose
capabilities available in the workbench
continuity items
widgets
role-specific field visibility

Example:

workbench: sales
entities:
  - account
  - contact
  - opportunity

capabilities:
  - qualify_lead
  - create_opportunity
  - send_email

continuity:
  - conversations
  - meetings

widgets:
  - pipeline
  - forecast

The UI, search, and capabilities all derive from this single source.

Field Semantics

Every field is a governed operational asset.

Field semantics define:

storage
validation
UI presentation
permissions
search behavior
embedding behavior
capability binding
event emission
projection rules

Example:

entity: Account

field: account.name
  storage:
    type: text
    column: name

  ui:
    label: Company Name
    placeholder: Enter company name
    control: text
    required: true

  search:
    indexed: true
    fulltext: true

  embedding:
    include: true

  permissions:
    read:
      - sales
      - founder
    write:
      - sales_manager

  workbenches:
    founder:
      visible: true
      section: overview
    sales:
      visible: true
      section: basic
    finance:
      visible: false

  capabilities:
    requires:
      - crm.account.create
      - crm.account.update

This means:

one definition drives storage, UI, search, embeddings, permissions, capabilities, and projections
adding a field requires updating one place only
all downstream systems discover the change automatically

Adaptive UI

UI rendering is driven by Spine field semantics and workbench projections.

Workbench
    │
    ▼
Projection
    │
    ▼
Field Metadata
    │
    ▼
UI Renderer

The renderer asks:

“How should I display this field?”
“Should this field be visible for this role?”
“What controls does this field require?”

Not hardcoded form assumptions.

Adaptive Capabilities

Capabilities declare required fields, not React forms.

capability: crm.account.create
requires:
  - account.name
  - account.owner
  - account.industry

The UI resolves required fields from the Spine schema and renders the form dynamically.

Canonical Spine Registry

The Spine specification is the authoritative source for:

storage semantics
UI rendering
validation
permissions
search behavior
embeddings
AI context
capability bindings
projection rules
event mappings
synchronization behavior

Everything else consumes that registry.