{"slug":"architecture/SPINE_INTELLIGENCE_AGENT","title":"Spine Intelligence Agent — Specification","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/SPINE_INTELLIGENCE_AGENT.mdx","bytes":26125,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Status:** Canonical architecture specification  \n> **Date:** July 6, 2026  \n> **Authority:** Nirmal (Founder)  \n> **Companion docs:** `SPINE_DOMAIN.md` (three-layer model), `SPINE_MODEL.md` (physical storage), `PROJECTION_MODEL.md` (read views)  \n> **Purpose:** Defines the pipeline that turns domain inputs into a self-describing Spine Domain, emitting all downstream artifacts.\n\n---\n\n## 0. The One-Line Truth\n\n```text\nThe Spine Intelligence Agent never generates SQL first.\nIt builds an internal graph. Everything derives from the graph.\n```\n\n---\n\n## 1. The Pipeline (High Level)\n\n```text\nRepository\nDocumentation\nConnector Metadata\nDatabase Schema\nOpenAPI Specs\nTypeScript Types\nExisting Spine\nBusiness Definitions\n        │\n        ▼\n┌─────────────────────┐\n│ Schema Extraction   │  Parse all inputs. Extract entities, fields, types.\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Ontology Generation │  Build the internal graph: nodes (entities, memories) + edges (relationships).\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Relationship        │  Discover implicit connections. Infer cardinality, directionality,\n│ Discovery           │  dependency chains, and signal propagation paths.\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Entity Normalization│  Collapse synonyms. Resolve aliases. Enforce canonical types.\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Memory Classification│  Separate immutable truth (Spine) from derived opinion (Memory).\n│                      │  Tag each attribute with its layer: canonical, dynamic, projection-only.\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Capability Detection │  Identify what the domain can do. Map capabilities to projections.\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Projection Generation│  Build team-specific views. No duplication. Only declaration.\n└─────────────────────┘\n        │\n        ▼\n┌─────────────────────┐\n│ Code Generation     │  Emit SQL, JSON, TypeScript, and documentation from the graph.\n└─────────────────────┘\n```\n\n---\n\n## 2. Inputs (What the Agent Consumes)\n\nThe agent accepts any combination of these inputs. The more inputs, the richer the graph.\n\n| Input                  | Format                               | What it provides                                              | Example                                                               |\n| ---------------------- | ------------------------------------ | ------------------------------------------------------------- | --------------------------------------------------------------------- |\n| `repository`           | Git repo, code files                 | Existing data models, TypeScript types, API handlers          | `packages/types/src/schema.ts`                                        |\n| `documentation`        | Markdown, PDF, Confluence            | Business definitions, process descriptions, domain language   | Account Success PDF                                                   |\n| `connector_metadata`   | Nango connector manifest, API schema | External system entity types, field mappings, sync rules      | Salesforce connector spec                                             |\n| `database_schema`      | SQL DDL, D1 schema, ER diagram       | Existing tables, columns, indexes, constraints                | `033_spine_accounts_intelligence.sql`                                 |\n| `openapi_specs`        | OpenAPI 3.0 JSON/YAML                | API contract definitions, endpoints, request/response schemas | `/api/v1/accounts` spec                                               |\n| `typescript_types`     | `.ts` files, interfaces, enums       | Type-level entity definitions, runtime validation schemas     | `zod` schemas, `interface` defs                                       |\n| `existing_spine`       | JSON/YAML, SQL                       | Current canonical entities, aliases, domain configs           | `DOMAIN_SPINE_CONFIG`                                                 |\n| `business_definitions` | Natural language, structured docs    | Domain vocabulary, business rules, entity relationships       | \"An Account has many Contacts. A Contact works for one Organization.\" |\n\n---\n\n## 3. Stage 1 — Schema Extraction\n\n### 3.1 Purpose\n\nParse all inputs into a normalized intermediate representation. Do not judge yet. Extract everything.\n\n### 3.2 Output: `ExtractedSchema`\n\n```json\n{\n  \"sources\": [\n    {\n      \"source_id\": \"src_001\",\n      \"type\": \"database_schema\",\n      \"file\": \"033_spine_accounts_intelligence.sql\",\n      \"confidence\": 1.0\n    }\n  ],\n  \"entities\": [\n    {\n      \"entity_id\": \"ext_001\",\n      \"source_ids\": [\"src_001\"],\n      \"name\": \"spine_accounts\",\n      \"kind\": \"table\",\n      \"attributes\": [\n        { \"name\": \"id\", \"type\": \"uuid\", \"nullable\": false, \"is_primary\": true },\n        { \"name\": \"tenant_id\", \"type\": \"uuid\", \"nullable\": false },\n        {\n          \"name\": \"data\",\n          \"type\": \"jsonb\",\n          \"nullable\": false,\n          \"comment\": \"JSONB blob containing name, industry, region, tier, arr_usd...\"\n        }\n      ],\n      \"extracted_from\": \"033_spine_accounts_intelligence.sql\"\n    }\n  ],\n  \"relationships\": [\n    {\n      \"relationship_id\": \"rel_001\",\n      \"source_ids\": [\"src_001\"],\n      \"from_entity\": \"spine_accounts\",\n      \"to_entity\": \"spine_people\",\n      \"type\": \"implicit\",\n      \"evidence\": \"both have tenant_id and scope->account_id\"\n    }\n  ]\n}\n```\n\n### 3.3 Rules\n\n- Preserve provenance. Every extracted entity and relationship carries a `source_id`.\n- Do not normalize yet. Extract raw tables as they are. Extract `data JSONB` fields as pseudo-attributes with comments.\n- Extract implicit relationships from foreign keys, `scope` JSONB references, shared `tenant_id`, and naming conventions.\n- Extract entities from TypeScript types, OpenAPI schemas, and natural language as first-class citizens, not as tables.\n\n---\n\n## 4. Stage 2 — Ontology Generation\n\n### 4.1 Purpose\n\nTransform the extracted schema into a **domain ontology** — a graph of what the domain is actually about, independent of physical representation.\n\n### 4.2 Output: `DomainOntology`\n\n```json\n{\n  \"domain\": \"account_success\",\n  \"version\": \"1.0.0\",\n  \"nodes\": [\n    {\n      \"node_id\": \"node_account\",\n      \"canonical_name\": \"Account\",\n      \"aliases\": [\"spine_accounts\", \"Company\", \"Customer\", \"HubSpot Company\", \"Salesforce Account\"],\n      \"layer\": \"canonical_spine\",\n      \"attributes\": [\n        { \"name\": \"name\", \"type\": \"text\", \"required\": true, \"source\": \"extracted\" },\n        { \"name\": \"industry\", \"type\": \"text\", \"required\": false, \"source\": \"extracted\" },\n        { \"name\": \"region\", \"type\": \"text\", \"required\": false, \"source\": \"extracted\" },\n        { \"name\": \"tier\", \"type\": \"text\", \"required\": false, \"source\": \"inferred\" },\n        { \"name\": \"arr_usd\", \"type\": \"decimal\", \"required\": false, \"source\": \"extracted\" }\n      ],\n      \"provenance\": [\"ext_001\", \"ext_042\"]\n    },\n    {\n      \"node_id\": \"node_health\",\n      \"canonical_name\": \"Health\",\n      \"aliases\": [\"health_score\", \"account_health\"],\n      \"layer\": \"dynamic_memory\",\n      \"attributes\": [\n        { \"name\": \"score\", \"type\": \"decimal\", \"required\": true, \"source\": \"inferred\" },\n        { \"name\": \"score_label\", \"type\": \"text\", \"required\": false, \"source\": \"inferred\" },\n        { \"name\": \"reasoning\", \"type\": \"text\", \"required\": false, \"source\": \"inferred\" },\n        { \"name\": \"confidence\", \"type\": \"decimal\", \"required\": true, \"source\": \"inferred\" }\n      ],\n      \"provenance\": [\"ext_087\"]\n    }\n  ],\n  \"edges\": [\n    {\n      \"edge_id\": \"edge_001\",\n      \"from\": \"node_account\",\n      \"relation_type\": \"has_state\",\n      \"to\": \"node_health\",\n      \"cardinality\": \"1:N\",\n      \"directionality\": \"directed\",\n      \"temporal\": true,\n      \"evidence\": \"health is computed per account over time\"\n    },\n    {\n      \"edge_id\": \"edge_002\",\n      \"from\": \"node_account\",\n      \"relation_type\": \"owns\",\n      \"to\": \"node_contract\",\n      \"cardinality\": \"1:N\",\n      \"directionality\": \"directed\",\n      \"temporal\": false,\n      \"evidence\": \"business rule: an account has one or more contracts\"\n    }\n  ]\n}\n```\n\n### 4.3 Rules\n\n- **Nodes are canonical entities or memory types.** No tables. No JSONB blobs. Real concepts.\n- **Edges are typed and have metadata.** Every edge has cardinality, directionality, temporality, and evidence.\n- **Aliases are first-class.** The ontology captures every name this concept has ever been called. This is how entity resolution works.\n- **Layer assignment is explicit.** Every node is tagged `canonical_spine`, `dynamic_memory`, or `projection`. No ambiguity.\n- **Attributes carry source.** Every attribute knows whether it was extracted from code, inferred from documentation, or derived from business rules.\n\n---\n\n## 5. Stage 3 — Relationship Discovery\n\n### 5.1 Purpose\n\nFind relationships that were not explicitly stated in any input. Infer connections from naming, co-occurrence, business logic, and graph topology.\n\n### 5.2 Discovery methods\n\n| Method               | What it does                          | Example                                                       |\n| -------------------- | ------------------------------------- | ------------------------------------------------------------- |\n| `naming_inference`   | Similar names suggest relationships   | `account_id` in `scope` → `Account`                           |\n| `co_occurrence`      | Entities that appear together in docs | \"Account health\" → Account → Health                           |\n| `business_logic`     | Domain rules imply connections        | \"A renewal is a subscription event\" → Contract → Subscription |\n| `graph_traversal`    | Transitive closure over known edges   | Account → Contract → Subscription → Capability → Integration  |\n| `signal_propagation` | How signals flow across the domain    | Usage → Health → Risk → Playbook                              |\n\n### 5.3 Output: `EnrichedOntology`\n\nSame shape as `DomainOntology`, but with additional edges, edge weights, and confidence scores. Every discovered edge has a `discovery_method` and `confidence` (0.0–1.0).\n\n---\n\n## 6. Stage 4 — Entity Normalization\n\n### 6.1 Purpose\n\nCollapse aliases. Resolve conflicts. Enforce the canonical type system.\n\n### 6.2 Normalization rules\n\n1. **One canonical name per real-world concept.** `spine_accounts`, `Company`, `Customer`, `HubSpot Company`, `Salesforce Account` → `Account`.\n2. **Attribute merge with provenance.** If two sources define `Account` differently, merge attributes and keep both provenance records. Flag conflicts for human review.\n3. **Type coercion.** Normalize types to a canonical type system: `text`, `integer`, `decimal`, `boolean`, `date`, `datetime`, `uuid`, `json`, `enum`.\n4. **Required vs. optional.** An attribute is required only if ALL sources agree it is required. Otherwise, optional.\n5. **Tenant scoping.** Every entity and memory node inherits `tenant_id` as an implicit, non-optional attribute. It is never listed in the ontology but is always present in the emitted SQL.\n\n### 6.3 Output: `NormalizedOntology`\n\nSame shape as `DomainOntology`, but aliases are collapsed, attributes are merged, and every node has a single canonical name.\n\n---\n\n## 7. Stage 5 — Memory Classification\n\n### 7.1 Purpose\n\nFor every attribute and every node, decide: **Spine or Memory?** This is the critical layer-separation gate.\n\n### 7.2 Classification criteria\n\n| Criterion       | Spine                                         | Memory                              |\n| --------------- | --------------------------------------------- | ----------------------------------- |\n| Source          | External system, manual entry, legal document | Derived, computed, AI-generated     |\n| Mutability      | Changes only when the world changes           | Changes when the model changes      |\n| Truth claim     | \"This is what exists\"                         | \"This is what we believe\"           |\n| Versioning      | Append-only, immutable history                | Ephemeral, TTL-driven, overwritable |\n| Human authority | Data entry, system sync                       | AI inference, heuristic, ML model   |\n| Confidence      | 1.0 (assumed)                                 | 0.0–1.0 (explicit)                  |\n\n### 7.3 Classification process\n\n```text\nFor each node in the NormalizedOntology:\n    If all attributes pass Spine criteria → tag 'canonical_spine'\n    If any attribute passes Memory criteria → tag 'dynamic_memory'\n    If the node is a view over other nodes → tag 'projection'\n    If mixed → split the node into a Spine node (immutable attrs) + Memory node (derived attrs)\n```\n\n### 7.4 Example: splitting a mixed node\n\nInput: `spine_platform_metrics` from old schema\n\n- `metric_name` → Spine (it's a real thing being measured)\n- `current_value` → Memory (it's a measurement at a point in time)\n- `health_status` → Memory (it's an interpretation)\n- `business_impact_status` → Memory (it's an assessment)\n\nOutput:\n\n- `spine_metric_definitions` (canonical_spine) — `metric_name`, `unit`, `measurement_frequency`, `data_source`\n- `memory_usage` (dynamic_memory) — `current_value`, `target_value`, `health_status`, `business_impact_status`, `measured_at`\n\n### 7.5 Output: `ClassifiedOntology`\n\nEvery node has a `layer` tag: `canonical_spine`, `dynamic_memory`, or `projection`. Every attribute has a `stability` tag: `immutable` or `ephemeral`.\n\n---\n\n## 8. Stage 6 — Capability Detection\n\n### 8.1 Purpose\n\nIdentify what the domain **can do** — not just what it has. Capabilities map to projections (which team can do what) and to routes (which API endpoints expose what).\n\n### 8.2 Capability model\n\n```json\n{\n  \"capability_id\": \"cap_view_account_health\",\n  \"name\": \"View Account Health\",\n  \"domain\": \"account_success\",\n  \"requires\": [\n    { \"node\": \"node_account\", \"layer\": \"canonical_spine\", \"access\": \"read\" },\n    { \"node\": \"node_health\", \"layer\": \"dynamic_memory\", \"access\": \"read\" }\n  ],\n  \"produces\": [{ \"node\": \"node_health\", \"layer\": \"dynamic_memory\", \"action\": \"generate\" }],\n  \"governance_gate\": \"can_view_health\",\n  \"projections\": [\"projection-account-success\", \"projection-executive\"],\n  \"routes\": [\"GET /api/v1/accounts/{id}/health\"]\n}\n```\n\n### 8.3 Detection rules\n\n- **CRUD over Spine nodes = capabilities.** `create_account`, `read_account`, `update_account`, `delete_account`.\n- **CRUD over Memory nodes = capabilities.** `generate_health`, `refresh_sentiment`, `archive_insight`.\n- **Traversal over edges = capabilities.** `view_account_contacts`, `view_deployment_integrations`.\n- **Multi-node operations = advanced capabilities.** `generate_qbr_package` (Account + Health + Engagement + Timeline + Insights).\n\n### 8.4 Output: `CapabilityCatalog`\n\nA catalog of all capabilities in the domain, linked to required nodes, projections, and routes.\n\n---\n\n## 9. Stage 7 — Projection Generation\n\n### 9.1 Purpose\n\nBuild team-specific views from the ClassifiedOntology + CapabilityCatalog. No duplication. Only declaration.\n\n### 9.2 Projection generation rules\n\n1. **Start with the team.** Define the target persona: role, department, goals, decisions they make.\n2. **Select nodes.** From the ClassifiedOntology, pick Spine nodes + Memory nodes relevant to that persona.\n3. **Filter edges.** From the EnrichedOntology, select only edges connecting included nodes. Prune dangling edges.\n4. **Define depth.** How many hops from the primary entity? `direct` (1 hop) vs. `indirect` (2 hops). For CSM: Account → Person (direct), Account → Contract → Subscription (indirect).\n5. **Field policy.** For each included node, list which fields are visible, searchable, and AI-readable.\n6. **Governance gates.** Map capabilities to `can_act`, `can_approve`, `can_admin`.\n7. **Navigation.** Declare primary and secondary nav items based on included nodes.\n8. **Entity 360.** Define the tabs and metrics for the primary entity's detail view.\n\n### 9.3 Output: `ProjectionConfig`\n\nOne JSON file per projection. See `SPINE_DOMAIN.md` §5.4 for the format.\n\n---\n\n## 10. Stage 8 — Code Generation\n\n### 10.1 Purpose\n\nEmit all downstream artifacts from the graph. Every artifact is a deterministic function of the ClassifiedOntology + CapabilityCatalog + ProjectionConfigs.\n\n### 10.2 Emission map\n\n| Artifact                | Source                          | Format   | Destination                                       |\n| ----------------------- | ------------------------------- | -------- | ------------------------------------------------- |\n| `spine_*.sql`           | `canonical_spine` nodes         | SQL DDL  | `migrations/spine/`                               |\n| `memory_*.sql`          | `dynamic_memory` nodes          | SQL DDL  | `migrations/memory/`                              |\n| `routes.json`           | CapabilityCatalog               | JSON     | `services/gateway/config/routes.json`             |\n| `navigation.json`       | ProjectionConfigs               | JSON     | `apps/web/config/navigation.json`                 |\n| `projection-*.json`     | ProjectionConfigs               | JSON     | `domains/{domain}/projection-*.json`              |\n| `rbac.json`             | CapabilityCatalog + projections | JSON     | `services/governance/config/rbac.json`            |\n| `search.json`           | All nodes + field policies      | JSON     | `services/knowledge/config/search.json`           |\n| `entity360.json`        | ProjectionConfigs               | JSON     | `domains/{domain}/entity360.json`                 |\n| `knowledge-schema.json` | All nodes + relationships       | JSON     | `services/knowledge/config/knowledge-schema.json` |\n| TypeScript types        | All nodes + attributes          | `.ts`    | `packages/types/src/generated/`                   |\n| OpenAPI specs           | CapabilityCatalog + routes      | YAML     | `docs/api/openapi/`                               |\n| Documentation           | Everything                      | Markdown | `docs/generated/`                                 |\n\n### 10.3 Generation rules\n\n1. **SQL is generated, not written.** Every `spine_*.sql` and `memory_*.sql` file is produced by the Code Generation stage from the ClassifiedOntology. No hand-written SQL for new domains.\n2. **JSON is declarative.** Every JSON config file is a projection of the graph. It does not contain business logic — only declarations of what the graph provides.\n3. **TypeScript is synchronized.** Types are generated from the ontology. If the ontology changes, the types are regenerated. No manual type maintenance.\n4. **Documentation is live.** Every generated document carries a `generated_at` timestamp and a `source_hash` of the ontology. Stale docs are detectable.\n5. **Idempotency.** Running the agent twice with the same inputs produces identical outputs. The pipeline is deterministic.\n\n---\n\n## 11. The Internal Graph Format\n\nThe agent uses a standard intermediate graph format for all internal representations. This format is the **source of truth** for all downstream generation.\n\n```json\n{\n  \"graph\": {\n    \"version\": \"1.0.0\",\n    \"domain\": \"account_success\",\n    \"metadata\": {\n      \"generated_at\": \"2026-07-06T00:00:00Z\",\n      \"source_hashes\": [\"sha256:abc123...\"],\n      \"agent_version\": \"spine-intelligence-agent@1.0.0\"\n    },\n    \"nodes\": [\n      {\n        \"id\": \"node_account\",\n        \"type\": \"canonical_spine\",\n        \"name\": \"Account\",\n        \"aliases\": [\"spine_accounts\", \"Company\", \"Customer\"],\n        \"attributes\": [...],\n        \"provenance\": [...]\n      }\n    ],\n    \"edges\": [\n      {\n        \"id\": \"edge_001\",\n        \"from\": \"node_account\",\n        \"relation_type\": \"has_state\",\n        \"to\": \"node_health\",\n        \"metadata\": { \"cardinality\": \"1:N\", \"temporal\": true, \"confidence\": 0.95 }\n      }\n    ],\n    \"capabilities\": [...],\n    \"projections\": [...]\n  }\n}\n```\n\n---\n\n## 12. Continuous Evolution\n\n### 12.1 The Spine becomes self-describing\n\nWhen a new domain is onboarded:\n\n1. Feed the agent domain definitions, APIs, and documentation.\n2. The agent discovers entities, relationships, capabilities, and memory models.\n3. It generates the canonical Spine schema.\n4. It generates projections, navigation, RBAC, routes, Entity360 definitions, search indexes, and documentation.\n5. It emits a CHANGELOG of what changed from the previous run.\n\n### 12.2 Change detection\n\nThe agent compares its output to the previous run:\n\n- **New nodes/edges:** Added to Spine or Memory schema.\n- **Removed nodes/edges:** Flagged for deprecation review. Never auto-delete.\n- **Changed attributes:** Generate migration scripts. Flag for data migration.\n- **New capabilities:** Generate routes and RBAC entries.\n- **New projections:** Generate projection configs and UI declarations.\n\n### 12.3 Human-in-the-loop for destructive changes\n\nThe agent is autonomous for additive changes. Destructive changes (removal, type narrowing, constraint tightening) require human approval via the HITL orchestrator.\n\n---\n\n## 13. Integration with Existing Platform\n\n### 13.1 Where the agent lives\n\n```text\nservices/\n  spine-intelligence-agent/\n    src/\n      pipeline/\n        stage1-extract.ts        -- Schema Extraction\n        stage2-ontology.ts       -- Ontology Generation\n        stage3-relationships.ts  -- Relationship Discovery\n        stage4-normalize.ts      -- Entity Normalization\n        stage5-classify.ts       -- Memory Classification\n        stage6-capabilities.ts   -- Capability Detection\n        stage7-projections.ts    -- Projection Generation\n        stage8-codegen.ts        -- Code Generation\n      graph/\n        graph-model.ts           -- Internal graph format\n        graph-store.ts           -- Durable graph storage (D1)\n      inputs/\n        parsers/                 -- One parser per input type\n      outputs/\n        emitters/                -- One emitter per artifact type\n    config/\n      default-rules.json         -- Classification rules, detection thresholds\n      domain-templates/          -- Seed templates per domain\n```\n\n### 13.2 How it fits into the OODA loop\n\n```text\nObserve:  Ingest new inputs (repo changes, doc updates, schema drift)\nOrient:   Build/refresh the graph (Stages 1–5)\nDecide:   Human approves destructive changes (HITL gate)\nAct:      Emit artifacts (Stage 8), deploy to D1, update configs\nLearn:    Capture signal of what changed, feed into next cycle\n```\n\n### 13.3 Binding to existing services\n\n| Existing Service        | Agent Integration                                                                 |\n| ----------------------- | --------------------------------------------------------------------------------- |\n| `services/pipeline`     | Agent emits `spine_*.sql` + `memory_*.sql`; Pipeline executes migrations          |\n| `services/gateway`      | Agent emits `routes.json` + `rbac.json`; Gateway loads at startup                 |\n| `apps/web`              | Agent emits `navigation.json` + `projection-*.json`; UI consumes at runtime       |\n| `services/knowledge`    | Agent emits `search.json` + `knowledge-schema.json`; Vector search uses schema    |\n| `services/intelligence` | Agent emits capability catalog; Intelligence service routes based on capabilities |\n| `services/continuity`   | Agent emits memory classification rules; Continuity manages TTL lifecycle         |\n\n---\n\n## 14. Source-of-Truth Index\n\n| Concept                      | Authoritative source                                          |\n| ---------------------------- | ------------------------------------------------------------- |\n| Three-layer model            | `docs/architecture/SPINE_DOMAIN.md`                           |\n| Agent pipeline (this doc)    | `docs/architecture/SPINE_INTELLIGENCE_AGENT.md`               |\n| Internal graph format        | `services/spine-intelligence-agent/src/graph/graph-model.ts`  |\n| Graph store                  | `services/spine-intelligence-agent/src/graph/graph-store.ts`  |\n| Pipeline stages              | `services/spine-intelligence-agent/src/pipeline/`             |\n| Input parsers                | `services/spine-intelligence-agent/src/inputs/parsers/`       |\n| Output emitters              | `services/spine-intelligence-agent/src/outputs/emitters/`     |\n| Default classification rules | `services/spine-intelligence-agent/config/default-rules.json` |\n| Domain templates             | `services/spine-intelligence-agent/config/domain-templates/`  |\n| Generated artifacts          | `domains/{domain}/` + `services/*/config/` + `migrations/`    |\n| Physical storage             | `docs/architecture/SPINE_MODEL.md`                            |\n| Projection engine            | `docs/architecture/PROJECTION_MODEL.md`                       |\n| Layer/stage doctrine         | `docs/architecture/USER_SYSTEM_JOURNEY_BLUEPRINT.md`          |\n| Locked decisions             | `AGENTS.md` (DECISIONS 18–23)                                 |\n\n---\n\n_The Spine Intelligence Agent is not a code generator. It is a domain understanding system. SQL is the least interesting thing it produces. The graph is the product. When in doubt — halt, ask Nirmal._\n"}