modscape 1.3.0 → 2.0.1

package/README.ja.md

@@ -92,6 +92,7 @@ YAMLのルートレベル構造は以下の通りです：
 domains      – 関連テーブルをまとめるビジュアルコンテナ
 tables       – 3階層メタデータを持つエンティティ定義
 relationships – テーブル間のERカーディナリティ
+lineage      – データの流れ / 変換パス
 annotations  – キャンバス上のスティッキーノート・吹き出し
 layout       – 全座標データ（tables/domains の中に x/y を書いてはいけない）
 ```
@@ -104,7 +105,7 @@ domains:
     name: "主要売上"
     description: "営業チームのトランザクションデータ。"  # 任意
     color: "rgba(59, 130, 246, 0.1)"  # 背景色
-    tables: [orders, dim_customers]
+    tables: [orders, dim_customers]   # 論理的な所属リスト
     isLocked: false  # true にするとキャンバスでの誤ドラッグを防止
 ```
 
@@ -130,11 +131,6 @@ tables:
       businessDefinitions:
         revenue: "割引・返品後の純売上"
 
-    lineage:  # mart/集計テーブルのみに定義
-      upstream:
-        - fct_sales
-        - dim_dates
-
     implementation:  # 任意 – AIコード生成へのヒント
       materialization: incremental  # table | view | incremental | ephemeral
       incremental_strategy: merge   # merge | append | delete+insert
@@ -165,23 +161,22 @@ tables:
           type: "BIGINT"
           constraints: [NOT NULL]
 
-    sampleData:  # 2次元配列。先頭行 = カラムID
-      - [order_id, amount, status]
+    sampleData:  # 実数値の2次元配列
       - [1001, 50.0, "COMPLETED"]
       - [1002, 120.5, "PENDING"]
 ```
 
-**テーブルタイプと `appearance.type` の使い分け：**
+### Data Lineage（データリネージ）
+
+ルートレベルの `lineage` セクションでテーブル間のデータの流れ（どのソースからどの集計テーブルが作られるか）を定義します。リネージモードではアニメーション付きの点線矢印として表示されます。
 
-| type | 用途 |
-|------|------|
-| `fact` | 取引・イベント・測定値 |
-| `dimension` | エンティティ・マスタ・参照リスト |
-| `mart` | 集計・消費者向けテーブル（`lineage.upstream` を必ず定義） |
-| `hub` | Data Vault のビジネスキー |
-| `link` | Data Vault のハブ間結合・トランザクション |
-| `satellite` | Data Vault のハブに紐づく履歴属性 |
-| `table` | 汎用 |
+```yaml
+lineage:
+  - from: fct_orders    # ソーステーブル ID
+    to: mart_revenue    # 派生テーブル ID
+  - from: dim_dates
+    to: mart_revenue
+```
 
 ### Relationships（リレーションシップ）
 
@@ -196,7 +191,7 @@ relationships:
     type: one-to-many  # one-to-one | one-to-many | many-to-one | many-to-many
 ```
 
-> **データリネージ**は `lineage.upstream` で定義し、リネージモードでアニメーション矢印として表示されます。`relationships` に重複して記載しないでください。
+> **ER関係** vs **リネージ**: 構造的な結合（外部キーなど）には `relationships` を、データの加工・変換の流れには `lineage` を使用してください。両方に同じ接続を記述しないでください。
 
 ### Annotations（アノテーション）
 
@@ -270,7 +265,6 @@ modscape export ./models -o docs/ARCHITECTURE.md
 
 Modscape は以下の素晴らしいオープンソースプロジェクトによって支えられています：
 
-- [React Flow](https://reactflow.dev/) - インタラクティブなグラフ UI フレームワーク。
 - [CodeMirror 6](https://codemirror.net/) - 次世代のウェブベース・コードエディタ。
 - [Dagre](https://github.com/dagrejs/dagre) - 階層型グラフ・レイアウトエンジン。
 - [Lucide React](https://lucide.dev/) - シンプルで美しいアイコンセット。

package/README.md

@@ -95,6 +95,7 @@ Modscape uses a schema designed for data analysis contexts. The full YAML struct
 domains      – visual containers grouping related tables
 tables       – entity definitions with tri-layer metadata
 relationships – ER cardinality between tables
+lineage      – data flow / transformation paths
 annotations  – sticky notes / callouts on the canvas
 layout       – ALL coordinate data (never put x/y inside tables or domains)
 ```
@@ -107,7 +108,7 @@ domains:
     name: "Core Sales"
     description: "Transactional data for the sales team."  # optional
     color: "rgba(59, 130, 246, 0.1)"  # background fill
-    tables: [orders, dim_customers]
+    tables: [orders, dim_customers]   # logical membership
     isLocked: false  # prevent accidental drag when true
 ```
 
@@ -133,11 +134,6 @@ tables:
       businessDefinitions:
         revenue: "Net revenue after discounts"
 
-    lineage:  # for mart/aggregated tables only
-      upstream:
-        - fct_sales
-        - dim_dates
-
     implementation:  # optional – hints for AI code generation
       materialization: incremental  # table | view | incremental | ephemeral
       incremental_strategy: merge   # merge | append | delete+insert
@@ -168,12 +164,23 @@ tables:
           type: "BIGINT"
           constraints: [NOT NULL]
 
-    sampleData:  # 2D array; first row = column IDs
-      - [order_id, amount, status]
+    sampleData:  # 2D array of realistic values
       - [1001, 50.0, "COMPLETED"]
       - [1002, 120.5, "PENDING"]
 ```
 
+### Data Lineage
+
+Top-level `lineage` section declares data flow between tables (which source tables feed which derived tables). This is rendered as dashed arrows in **Lineage Mode**.
+
+```yaml
+lineage:
+  - from: fct_orders    # source table ID
+    to: mart_revenue    # derived table ID
+  - from: dim_dates
+    to: mart_revenue
+```
+
 ### Relationships
 
 ```yaml
@@ -187,7 +194,7 @@ relationships:
     type: one-to-many  # one-to-one | one-to-many | many-to-one | many-to-many
 ```
 
-> **Data Lineage** connections are driven by `lineage.upstream` and rendered as animated arrows in Lineage Mode. Do **not** duplicate them as `relationships` entries.
+> **ER Relationships** vs **Lineage**: Use `relationships` for structural joins (FKs) and `lineage` for data flow (transformations). Do not duplicate them.
 
 ### Annotations
 
@@ -261,7 +268,6 @@ modscape export ./models -o docs/ARCHITECTURE.md
 
 Modscape is made possible by these incredible open-source projects:
 
-- [React Flow](https://reactflow.dev/) - Interactive node-based UI framework.
 - [CodeMirror 6](https://codemirror.net/) - Next-generation code editor for the web.
 - [Dagre](https://github.com/dagrejs/dagre) - Directed graph layout engine.
 - [Lucide React](https://lucide.dev/) - Beautifully simple pixel-perfect icons.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "modscape",
-  "version": "1.3.0",
+  "version": "2.0.1",
   "description": "Modscape: A YAML-driven data modeling visualizer CLI",
   "repository": {
     "type": "git",
@@ -29,6 +29,7 @@
     "@inquirer/prompts": "^8.3.0",
     "chokidar": "^5.0.0",
     "commander": "^14.0.3",
+    "dagre": "^0.8.5",
     "express": "^5.2.1",
     "js-yaml": "^4.1.1",
     "open": "^11.0.0",

package/src/export.js

@@ -67,16 +67,13 @@ function generateMermaidLineage(schema) {
   let mermaid = 'graph TD\n';
   let hasLineage = false;
 
-  schema.tables.forEach(table => {
-    if (table.lineage?.upstream && table.lineage.upstream.length > 0) {
-      hasLineage = true;
-      const targetName = sanitize(table.name);
-      table.lineage.upstream.forEach(upId => {
-        const sourceTable = schema.tables.find(t => t.id === upId);
-        const sourceName = sanitize(sourceTable?.name || upId);
-        mermaid += `    ${sourceName} --> ${targetName}\n`;
-      });
-    }
+  (schema.lineage || []).forEach(edge => {
+    hasLineage = true;
+    const sourceTable = schema.tables.find(t => t.id === edge.from);
+    const targetTable = schema.tables.find(t => t.id === edge.to);
+    const sourceName = sanitize(sourceTable?.name || edge.from);
+    const targetName = sanitize(targetTable?.name || edge.to);
+    mermaid += `    ${sourceName} --> ${targetName}\n`;
   });
 
   return hasLineage ? mermaid : null;
@@ -197,10 +194,11 @@ export function generateMarkdown(schema, modelName) {
     }
 
     // Lineage
-    if (table.lineage?.upstream?.length > 0) {
-      const upstreamNames = table.lineage.upstream.map(upId => {
-        const t = schema.tables.find(t => t.id === upId);
-        return t ? t.name : upId;
+    const upstreamEdges = (schema.lineage || []).filter(e => e.to === table.id);
+    if (upstreamEdges.length > 0) {
+      const upstreamNames = upstreamEdges.map(e => {
+        const t = schema.tables.find(t => t.id === e.from);
+        return t ? t.name : e.from;
       });
       md += `**Upstream**: ${upstreamNames.map(n => `\`${n}\``).join(' → ')}\n\n`;
     }

package/src/import-dbt.js

@@ -34,6 +34,7 @@ export async function importDbt(projectDir, options) {
     console.log(`  🔍 Parsing dbt manifest: ${manifestPath}`);
 
     const tables = [];
+    const lineage = [];
     const domainsMap = new Map();
     const tableSplitKeyMap = new Map();
 
@@ -66,7 +67,6 @@ export async function importDbt(projectDir, options) {
         appearance: { type: 'table' },
         conceptual: { description: node.description || '' },
         columns,
-        lineage: { upstream: [] }
       };
 
       tables.push(tableEntry);
@@ -92,13 +92,12 @@ export async function importDbt(projectDir, options) {
     }
 
     // lineage
-    for (const [uniqueId, node] of Object.entries(allNodes)) {
+    for (const [, node] of Object.entries(allNodes)) {
       if (!['model', 'seed', 'snapshot', 'source'].includes(node.resource_type)) continue;
-      const tableEntry = tables.find(t => t.id === node.unique_id);
-      if (tableEntry && node.depends_on?.nodes) {
+      if (node.depends_on?.nodes) {
         for (const upstreamId of node.depends_on.nodes) {
           if (allNodes[upstreamId]) {
-            tableEntry.lineage.upstream.push(upstreamId);
+            lineage.push({ from: upstreamId, to: node.unique_id });
           }
         }
       }
@@ -122,11 +121,10 @@ export async function importDbt(projectDir, options) {
         const tableIds = new Set(splitTables.map(t => t.id));
         let internal = 0;
         let external = 0;
-        for (const table of splitTables) {
-          for (const upstreamId of table.lineage?.upstream || []) {
-            if (tableIds.has(upstreamId)) internal++;
-            else external++;
-          }
+        for (const edge of lineage) {
+          if (!tableIds.has(edge.to)) continue;
+          if (tableIds.has(edge.from)) internal++;
+          else external++;
         }
         const total = internal + external;
         const rate = total > 0 ? Math.round(internal / total * 100) : 100;
@@ -145,9 +143,12 @@ export async function importDbt(projectDir, options) {
             tables: d.tables.filter(tid => splitTables.some(t => t.id === tid))
           }));
 
+        const splitTableIds = new Set(splitTables.map(t => t.id));
+        const splitLineage = lineage.filter(e => splitTableIds.has(e.from) || splitTableIds.has(e.to));
         const outputModel = {
           tables: splitTables,
           relationships: [],
+          lineage: splitLineage,
           domains: splitDomains
         };
 
@@ -167,6 +168,7 @@ export async function importDbt(projectDir, options) {
       const outputModel = {
         tables,
         relationships: [],
+        lineage,
         domains: Array.from(domainsMap.values())
       };
 

package/src/index.js

@@ -10,6 +10,7 @@ import { exportModel } from './export.js';
 import { createModel } from './create.js';
 import { importDbt } from './import-dbt.js';
 import { syncDbt } from './sync-dbt.js';
+import { applyLayout } from './layout.js';
 import { createRequire } from 'module';
   import { mergeModels } from './merge.js';
   
@@ -104,4 +105,13 @@ program
     mergeModels(paths, options);
   });
 
+program
+  .command('layout')
+  .description('Perform automatic layout calculation and update the YAML file')
+  .argument('<path>', 'path to the YAML model file')
+  .option('-o, --output <path>', 'output file path (defaults to overwriting input)')
+  .action((path, options) => {
+    applyLayout(path, options);
+  });
+
 program.parse();

package/src/layout.js

@@ -0,0 +1,151 @@
+import fs from 'fs';
+import path from 'path';
+import yaml from 'js-yaml';
+import dagre from 'dagre';
+
+/**
+ * CLI-based layout engine for Modscape.
+ * Replicates the logic from the visualizer to ensure consistency.
+ */
+export function applyLayout(inputPath, options = {}) {
+  const absolutePath = path.resolve(process.cwd(), inputPath);
+  if (!fs.existsSync(absolutePath)) {
+    console.error(`  ❌ File not found: ${inputPath}`);
+    return;
+  }
+
+  const raw = fs.readFileSync(absolutePath, 'utf8');
+  let schema;
+  try {
+    schema = yaml.load(raw);
+  } catch (e) {
+    console.error(`  ❌ Failed to parse YAML: ${e.message}`);
+    return;
+  }
+
+  if (!schema || !schema.tables) {
+    console.error('  ❌ Invalid schema: No tables found.');
+    return;
+  }
+
+  console.log(`  🏗️  Calculating layout for ${schema.tables.length} tables...`);
+
+  // Initialize Dagre Graph
+  const g = new dagre.graphlib.Graph({ compound: true });
+  g.setGraph({
+    rankdir: 'LR',
+    nodesep: 80,
+    ranksep: 200,
+    marginx: 80,
+    marginy: 80,
+  });
+  g.setDefaultEdgeLabel(() => ({}));
+
+  // 1. Add Tables
+  schema.tables.forEach((table) => {
+    // Standard table size in canvas units
+    g.setNode(table.id, { width: 280, height: 160 });
+  });
+
+  // 2. Add Lineage Edges
+  if (schema.lineage) {
+    schema.lineage.forEach((edge) => {
+      if (g.hasNode(edge.from) && g.hasNode(edge.to)) {
+        g.setEdge(edge.from, edge.to);
+      }
+    });
+  }
+
+  // 3. Add ER Relationships
+  if (schema.relationships) {
+    schema.relationships.forEach((rel) => {
+      if (g.hasNode(rel.from.table) && g.hasNode(rel.to.table)) {
+        g.setEdge(rel.from.table, rel.to.table);
+      }
+    });
+  }
+
+  // 4. Setup Domains
+  const domainTableMap = new Map();
+  if (schema.domains) {
+    schema.domains.forEach((domain) => {
+      g.setNode(domain.id, { label: domain.name, cluster: true });
+      domain.tables.forEach((tableId) => {
+        if (g.hasNode(tableId)) {
+          g.setParent(tableId, domain.id);
+        }
+      });
+      domainTableMap.set(domain.id, domain.tables);
+    });
+  }
+
+  // Execute Layout Calculation
+  dagre.layout(g);
+
+  // 5. Post-process: Convert Dagre results to Modscape Layout format
+  const newLayout = {};
+  const PAD = 48;
+  const TABLE_W = 280;
+  const TABLE_H = 160; // Default height for layout estimation
+  const GAP = 40;
+
+  // Process Domains (Grid packing)
+  if (schema.domains) {
+    schema.domains.forEach(domain => {
+      const members = domain.tables.filter(tid => g.hasNode(tid));
+      if (members.length === 0) return;
+
+      // Sort by dagre rank (left -> right)
+      members.sort((a, b) => g.node(a).x - g.node(b).x);
+
+      const cols = Math.min(3, Math.ceil(Math.sqrt(members.length)));
+      const rowCount = Math.ceil(members.length / cols);
+
+      const gridW = cols * (TABLE_W + GAP) - GAP;
+      const gridH = rowCount * (TABLE_H + GAP) - GAP;
+
+      // Anchor grid to dagre centroid
+      const cx = members.reduce((s, tid) => s + g.node(tid).x, 0) / members.length;
+      const cy = members.reduce((s, tid) => s + g.node(tid).y, 0) / members.length;
+      const originX = cx - gridW / 2;
+      const originY = cy - gridH / 2;
+
+      members.forEach((tid, idx) => {
+        const col = idx % cols;
+        const row = Math.floor(idx / cols);
+        const xOff = col * (TABLE_W + GAP) + TABLE_W / 2;
+        const yOff = row * (TABLE_H + GAP) + TABLE_H / 2;
+        newLayout[tid] = {
+          x: Math.round(originX + xOff),
+          y: Math.round(originY + yOff),
+          parentId: domain.id
+        };
+      });
+
+      // Domain bounding box
+      const HEADER = 28;
+      newLayout[domain.id] = {
+        x: Math.round(originX - PAD),
+        y: Math.round(originY - PAD - HEADER),
+        width: Math.round(gridW + PAD * 2),
+        height: Math.round(gridH + PAD * 2 + HEADER)
+      };
+    });
+  }
+
+  // Standalone Tables
+  const domainTableIds = new Set(schema.domains?.flatMap(d => d.tables) ?? []);
+  schema.tables.forEach(t => {
+    if (!domainTableIds.has(t.id)) {
+      const pos = g.node(t.id);
+      newLayout[t.id] = { x: Math.round(pos.x), y: Math.round(pos.y) };
+    }
+  });
+
+  // 6. Save back to YAML
+  schema.layout = newLayout;
+  const outputPath = options.output ? path.resolve(process.cwd(), options.output) : absolutePath;
+  
+  fs.writeFileSync(outputPath, yaml.dump(schema, { indent: 2, lineWidth: -1, noRefs: true }), 'utf8');
+  console.log(`  ✅ Layout complete! Saved to: ${path.relative(process.cwd(), outputPath)}`);
+}

package/src/sync-dbt.js

@@ -59,15 +59,6 @@ export async function syncDbt(projectDir, options) {
         }
       }
 
-      const lineageUpstream = [];
-      if (node.depends_on?.nodes) {
-        for (const upstreamId of node.depends_on.nodes) {
-          if (allNodes[upstreamId]) {
-            lineageUpstream.push(upstreamId);
-          }
-        }
-      }
-
       latestTablesMap.set(tableId, {
         id: tableId,
         name: node.name,
@@ -76,7 +67,6 @@ export async function syncDbt(projectDir, options) {
         appearance: { type: 'table' },
         conceptual: { description: node.description || '' },
         columns,
-        lineage: { upstream: lineageUpstream }
       });
     }
 
@@ -112,11 +102,24 @@ export async function syncDbt(projectDir, options) {
           physical_name: latest.physical_name,
           conceptual: latest.conceptual,
           columns: latest.columns,
-          lineage: latest.lineage
         };
       });
 
-      const updated = { ...existing, tables: newTables };
+      // Rebuild lineage from manifest for tables in this file
+      const fileTableIds = new Set(newTables.map(t => t.id));
+      const newLineage = [];
+      for (const [, node] of Object.entries(allNodes)) {
+        if (!fileTableIds.has(node.unique_id)) continue;
+        if (node.depends_on?.nodes) {
+          for (const upstreamId of node.depends_on.nodes) {
+            if (allNodes[upstreamId]) {
+              newLineage.push({ from: upstreamId, to: node.unique_id });
+            }
+          }
+        }
+      }
+
+      const updated = { ...existing, tables: newTables, lineage: newLineage };
       fs.writeFileSync(yamlPath, yaml.dump(updated), 'utf8');
       console.log(`  📄 Updated: ${yamlPath}`);
     }

package/src/templates/codegen-rules.md

@@ -8,11 +8,14 @@ Read this file alongside `.modscape/rules.md` (which defines the YAML schema) be
 
 ## 1. Dependency Order (DAG)
 
-Use `lineage.upstream` to determine build order. Always generate upstream models before downstream ones.
+Use the top-level `lineage` section to determine build order. Always generate upstream (`from`) models before downstream (`to`) ones.
 
 ```yaml
 lineage:
-  upstream: [stg_orders, stg_order_items]  # these must be generated first
+  - from: stg_orders       # must be generated first
+    to: fct_orders
+  - from: stg_order_items  # must be generated first
+    to: fct_orders
 ```
 
 In dbt this becomes `{{ ref('stg_orders') }}`. In SQLMesh, `MODEL (... grain [...])` with `@this_model` references. Apply the equivalent pattern for your target tool.
@@ -123,7 +126,7 @@ Common TODO patterns:
 
 ## 8. Physical Table Names
 
-When `physical_name` is set on a table, use it as the actual table name in DDL or config blocks. The `id` field is the logical reference name used in `ref()` calls and `lineage.upstream`.
+When `physical_name` is set on a table, use it as the actual table name in DDL or config blocks. The `id` field is the logical reference name used in `ref()` calls and the `lineage` section.
 
 ---
 

package/src/templates/rules.md

@@ -8,9 +8,9 @@
 ## QUICK REFERENCE (read this first)
 
 ```
-ROOT KEYS      domains | tables | relationships | annotations | layout
+ROOT KEYS      domains | tables | relationships | lineage | annotations | layout
 COORDINATES    ONLY in `layout`. NEVER inside tables or domains.
-LINEAGE        Use lineage.upstream (not relationships) for mart/aggregated tables.
+LINEAGE        Use top-level `lineage` section (not relationships, not table.lineage.upstream).
 parentId       Declare a table's domain membership inside layout, not inside domains.
 IDs            Every object (table, domain, annotation) needs a unique `id`.
 sampleData     First row = column IDs. At least 3 realistic data rows.
@@ -27,6 +27,7 @@ A valid `model.yaml` has exactly these top-level keys.
 domains:       # (array) visual containers — OPTIONAL but recommended
 tables:        # (array) entity definitions — REQUIRED
 relationships: # (array) ER cardinality edges — OPTIONAL
+lineage:       # (array) data lineage edges — OPTIONAL
 annotations:   # (array) sticky notes / callouts — OPTIONAL
 layout:        # (object) ALL coordinates — REQUIRED if any objects exist
 ```
@@ -140,17 +141,15 @@ relationships:
 
 ## 4. Data Lineage
 
-`lineage.upstream` declares which source tables a derived table is built from.
-This is rendered as animated arrows in **Lineage Mode**. It is separate from ER relationships.
+Top-level `lineage` section declares data flow between tables (which source tables feed which derived tables).
+This is rendered as dashed arrows in **Lineage Mode**. It is separate from ER relationships.
 
 ```yaml
-tables:
-  - id: mart_revenue
-    appearance: { type: mart }
-    lineage:
-      upstream:
-        - fct_orders    # list of source table IDs
-        - dim_dates
+lineage:
+  - from: fct_orders    # source table id
+    to: mart_revenue    # derived table id
+  - from: dim_dates
+    to: mart_revenue
 ```
 
 ### When to use lineage vs relationships
@@ -158,21 +157,21 @@ tables:
 | Situation | Use |
 |-----------|-----|
 | `dim_customers` → `fct_orders` (FK join) | `relationships` |
-| `fct_orders` + `dim_dates` → `mart_revenue` (aggregation) | `lineage.upstream` |
+| `fct_orders` + `dim_dates` → `mart_revenue` (aggregation) | `lineage` |
 
-**MUST** define `lineage.upstream` for every `mart` or aggregated table.
-**MUST NOT** define `lineage.upstream` for raw tables (`fact`, `dimension`, `hub`, `link`, `satellite`).
-**MUST NOT** add a `relationships` entry for a connection already expressed in `lineage.upstream`.
+**MUST** define `lineage` entries for every `mart` or aggregated table.
+**MUST NOT** define `lineage` entries for raw tables (`fact`, `dimension`, `hub`, `link`, `satellite`) as sources.
+**MUST NOT** add a `relationships` entry for a connection already expressed in `lineage`.
 
 #### Example: correct separation
 
 ```yaml
 # CORRECT
-tables:
-  - id: mart_revenue
-    appearance: { type: mart }
-    lineage:
-      upstream: [fct_orders, dim_dates]   # lineage only
+lineage:
+  - from: fct_orders
+    to: mart_revenue
+  - from: dim_dates
+    to: mart_revenue
 
 relationships:
   - from: { table: dim_customers, column: customer_key }
@@ -409,11 +408,9 @@ relationships:
 
 ```yaml
 # CORRECT
-tables:
-  - id: mart_revenue
-    appearance: { type: mart }
-    lineage:
-      upstream: [fct_orders]    # ✅ express lineage here
+lineage:
+  - from: fct_orders
+    to: mart_revenue    # ✅ express lineage in the top-level lineage section
 ```
 
 ---
@@ -663,10 +660,6 @@ tables:
     logical_name: "Executive Revenue Summary"
     physical_name: "mart_finance_monthly_revenue_agg"
     appearance: { type: mart, icon: "📈" }
-    lineage:                        # mart → use lineage, not relationships
-      upstream:
-        - fct_orders
-        - dim_customers
     implementation:
       materialization: table
       grain: [month_key]
@@ -684,6 +677,12 @@ tables:
       - ["2024-02", 15200.00]
       - ["2024-03", 18900.75]
 
+lineage:                            # data flow — separate from ER
+  - from: fct_orders
+    to: mart_monthly_revenue
+  - from: dim_customers
+    to: mart_monthly_revenue
+
 relationships:                      # ER only — not for lineage
   - from: { table: dim_customers, column: customer_key }
     to:   { table: fct_orders,    column: customer_key }