@wrenai/genbi 0.0.4 → 0.0.5

package/profiles/genbi-enrich-context/context/context.json

@@ -0,0 +1,146 @@
+{
+  "context_version": 2,
+  "parseable": true,
+  "metrics": [
+    {
+      "name": "total_revenue",
+      "owner": "order_metrics",
+      "declared": true,
+      "additivity": "additive"
+    },
+    {
+      "name": "order_count",
+      "owner": "order_metrics",
+      "declared": true,
+      "additivity": "additive"
+    },
+    {
+      "name": "id",
+      "owner": "customers",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "id",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "customer_id",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "amount",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    }
+  ],
+  "dimensions": [
+    {
+      "name": "customer_id",
+      "owner": "order_metrics",
+      "is_temporal": false
+    },
+    {
+      "name": "name",
+      "owner": "customers",
+      "is_temporal": false
+    },
+    {
+      "name": "order_date",
+      "owner": "orders",
+      "is_temporal": true
+    }
+  ],
+  "models": [
+    {
+      "name": "customers",
+      "has_timestamp": false,
+      "columns": [
+        "id",
+        "name"
+      ]
+    },
+    {
+      "name": "orders",
+      "has_timestamp": true,
+      "columns": [
+        "id",
+        "customer_id",
+        "order_date",
+        "amount"
+      ]
+    }
+  ],
+  "lineage": {
+    "nodes": [
+      {
+        "id": "model:customers",
+        "kind": "model"
+      },
+      {
+        "id": "model:orders",
+        "kind": "model"
+      },
+      {
+        "id": "rel:orders_customer",
+        "kind": "relationship"
+      },
+      {
+        "id": "cube:order_metrics",
+        "kind": "cube"
+      },
+      {
+        "id": "metric:order_metrics.total_revenue",
+        "kind": "metric"
+      },
+      {
+        "id": "metric:order_metrics.order_count",
+        "kind": "metric"
+      },
+      {
+        "id": "dim:order_metrics.customer_id",
+        "kind": "dimension"
+      },
+      {
+        "id": "query:total-revenue",
+        "kind": "query"
+      }
+    ],
+    "edges": [
+      {
+        "from": "model:orders",
+        "to": "rel:orders_customer"
+      },
+      {
+        "from": "model:customers",
+        "to": "rel:orders_customer"
+      },
+      {
+        "from": "model:orders",
+        "to": "cube:order_metrics"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "metric:order_metrics.total_revenue"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "metric:order_metrics.order_count"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "dim:order_metrics.customer_id"
+      },
+      {
+        "from": "model:orders",
+        "to": "query:total-revenue"
+      }
+    ]
+  },
+  "lineage_diagnostics": []
+}

package/profiles/genbi-enrich-context/ir.golden.json

@@ -20,6 +20,7 @@
         },
         "render_blocks": []
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "enrichment_gap_coverage"
@@ -93,6 +94,7 @@
           }
         ]
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "enrichment_proposal_soundness",
@@ -172,6 +174,7 @@
           }
         ]
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "enrichment_apply_safety",
@@ -252,10 +255,6 @@
         }
       ],
       "lineage": {
-        "consumers": {
-          "dashboards": 0,
-          "queries": 1
-        },
         "edges": 7,
         "nodes": 8,
         "resolvable": true
@@ -298,5 +297,5 @@
     }
   },
   "profile": "genbi-enrich-context",
-  "warble_ir_version": "0.6"
+  "warble_ir_version": "0.9"
 }

package/profiles/genbi-monitor/context/binding.yml

@@ -1,7 +1,15 @@
 # Coarse context binding: the whole v5-jaffle semantic layer — same shape and same resolution path
-# as genbi-default/context/binding.yml (IR v0.3+ builds a real MdlContext over the bound project and
-# evaluates context_precondition predicates against it). The host rewrites this `project:` line to
-# the user's own wren project at onboarding time; this repo pins v5-jaffle so `genbi-monitor`
-# compiles standalone for CI/dev.
-# Path is relative to this profile directory.
+# as genbi-default/context/binding.yml. `kind: prepared` means Warble reads the JSON document
+# `document:` names (produced by WrenAI's own `wren-context-loader` generator) rather than
+# introspecting MDL itself.
+#
+# `project:` is the layer's IDENTITY, never the document's path; `document:` carries the file. Both
+# resolve relative to this Warble project's own root (the profile directory), not relative to this
+# file.
+#
+# The host rewrites this `project:` line to the user's own semantic layer at onboarding time and
+# regenerates `document:`'s file in place; this repo pins v5-jaffle so `genbi-monitor` compiles
+# standalone for CI/dev. See MAINTAINING.md for how to regenerate the committed document.
+kind: prepared
 project: ../../../../examples/v5-jaffle
+document: context/context.json

package/profiles/genbi-monitor/context/context.json

@@ -0,0 +1,146 @@
+{
+  "context_version": 2,
+  "parseable": true,
+  "metrics": [
+    {
+      "name": "total_revenue",
+      "owner": "order_metrics",
+      "declared": true,
+      "additivity": "additive"
+    },
+    {
+      "name": "order_count",
+      "owner": "order_metrics",
+      "declared": true,
+      "additivity": "additive"
+    },
+    {
+      "name": "id",
+      "owner": "customers",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "id",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "customer_id",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "amount",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    }
+  ],
+  "dimensions": [
+    {
+      "name": "customer_id",
+      "owner": "order_metrics",
+      "is_temporal": false
+    },
+    {
+      "name": "name",
+      "owner": "customers",
+      "is_temporal": false
+    },
+    {
+      "name": "order_date",
+      "owner": "orders",
+      "is_temporal": true
+    }
+  ],
+  "models": [
+    {
+      "name": "customers",
+      "has_timestamp": false,
+      "columns": [
+        "id",
+        "name"
+      ]
+    },
+    {
+      "name": "orders",
+      "has_timestamp": true,
+      "columns": [
+        "id",
+        "customer_id",
+        "order_date",
+        "amount"
+      ]
+    }
+  ],
+  "lineage": {
+    "nodes": [
+      {
+        "id": "model:customers",
+        "kind": "model"
+      },
+      {
+        "id": "model:orders",
+        "kind": "model"
+      },
+      {
+        "id": "rel:orders_customer",
+        "kind": "relationship"
+      },
+      {
+        "id": "cube:order_metrics",
+        "kind": "cube"
+      },
+      {
+        "id": "metric:order_metrics.total_revenue",
+        "kind": "metric"
+      },
+      {
+        "id": "metric:order_metrics.order_count",
+        "kind": "metric"
+      },
+      {
+        "id": "dim:order_metrics.customer_id",
+        "kind": "dimension"
+      },
+      {
+        "id": "query:total-revenue",
+        "kind": "query"
+      }
+    ],
+    "edges": [
+      {
+        "from": "model:orders",
+        "to": "rel:orders_customer"
+      },
+      {
+        "from": "model:customers",
+        "to": "rel:orders_customer"
+      },
+      {
+        "from": "model:orders",
+        "to": "cube:order_metrics"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "metric:order_metrics.total_revenue"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "metric:order_metrics.order_count"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "dim:order_metrics.customer_id"
+      },
+      {
+        "from": "model:orders",
+        "to": "query:total-revenue"
+      }
+    ]
+  },
+  "lineage_diagnostics": []
+}

package/profiles/genbi-monitor/ir.golden.json

@@ -40,6 +40,7 @@
           }
         ]
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "detection_accuracy",
@@ -60,6 +61,15 @@
       ],
       "id": "monitor_freshness",
       "llm_calls": [
+        {
+          "conditional": false,
+          "consumes": [],
+          "name": "read_freshness",
+          "produces": "freshness_reading",
+          "prompt": "You are the `read_freshness` step of the `monitor_freshness` assertion, bound to the semantic\ncontext `v5-jaffle`.\n\nRun the deterministic freshness assert through the bound query capability — `SELECT\nmax(<timestamp column>)` on the bound model — and compare the observed lag against the expected\ncadence (the `expected_cadence` param, or the MDL's declared cadence). Fresh iff the newest row is\nwithin the cadence; stale otherwise. This is a SQL comparison, not a judgment call: do NOT ask an\nLLM to decide fresh-vs-stale, and do not estimate or guess at a reading you did not query for.\n\nYour one job is to report the reading, not to grade it — severity classification belongs entirely\nto `assess_severity`, which runs next and only when this step finds the data stale.\n\nProduce `freshness_reading`: the observed newest timestamp, the observed lag (against now), the\nexpected cadence, and a `stale` boolean (`true` iff the observed lag exceeds the expected cadence).\nEvery field must come from the query result; never fabricate a reading.",
+          "tier": "cheap",
+          "when": null
+        },
         {
           "conditional": true,
           "consumes": [
@@ -67,7 +77,7 @@
           ],
           "name": "assess_severity",
           "produces": "severity_verdict",
-          "prompt": "You are the `assess_severity` step of the `monitor_freshness` assertion, bound to the\n`v5-jaffle` wren project.\n\nYou run ONLY when the deterministic freshness assert has already decided the data is **stale** —\ni.e. `max(<timestamp>)` on the monitored model is older than the expected cadence. The fresh-vs-stale\ndecision is not yours; it was a SQL comparison. You never re-run it, and when the data is fresh this\nstep does not run at all.\n\nYour one job: given the `freshness_reading` (the observed newest timestamp, the observed lag, and the\nexpected cadence), classify how bad the breach is:\n\n- `warn` — modestly overdue (roughly within ~2× the cadence), no compounding signal. The pipeline is\n  probably just late.\n- `critical` — badly overdue (well beyond ~2× the cadence), or the lag is still growing across recent\n  readings, or this model feeds known-critical downstreams. Someone should be paged.\n\nJudge from the lag magnitude relative to the cadence and any history in the reading; do not invent\nnumbers you were not given. Keep it to a reproducible, conservative call — when genuinely on the\nboundary, prefer `warn` and say why.\n\nProduce `severity_verdict` as a compact judgement: the chosen `severity` (`warn` | `critical`) and a\none-line rationale grounded in the lag vs cadence. This feeds the `status` block's `severity` field\nin the verdict envelope; it does not change the fresh/stale verdict itself.",
+          "prompt": "You are the `assess_severity` step of the `monitor_freshness` assertion, bound to the semantic\ncontext `v5-jaffle`.\n\nYou run ONLY when the deterministic freshness assert has already decided the data is **stale** —\ni.e. `max(<timestamp>)` on the monitored model is older than the expected cadence. The fresh-vs-stale\ndecision is not yours; it was a SQL comparison. You never re-run it, and when the data is fresh this\nstep does not run at all.\n\nYour one job: given the `freshness_reading` (the observed newest timestamp, the observed lag, and the\nexpected cadence), classify how bad the breach is:\n\n- `warn` — modestly overdue (roughly within ~2× the cadence), no compounding signal. The pipeline is\n  probably just late.\n- `critical` — badly overdue (well beyond ~2× the cadence), or the lag is still growing across recent\n  readings, or this model feeds known-critical downstreams. Someone should be paged.\n\nJudge from the lag magnitude relative to the cadence and any history in the reading; do not invent\nnumbers you were not given. Keep it to a reproducible, conservative call — when genuinely on the\nboundary, prefer `warn` and say why.\n\nProduce `severity_verdict` as a compact judgement: the chosen `severity` (`warn` | `critical`) and a\none-line rationale grounded in the lag vs cadence. This feeds the `status` block's `severity` field\nin the verdict envelope; it does not change the fresh/stale verdict itself.",
           "tier": "cheap",
           "when": {
             "guard": "on_flag",
@@ -103,7 +113,7 @@
         ],
         "status": "pass"
       },
-      "prompt_fragment": "## assess_severity\n\nYou are the `assess_severity` step of the `monitor_freshness` assertion, bound to the\n`v5-jaffle` wren project.\n\nYou run ONLY when the deterministic freshness assert has already decided the data is **stale** —\ni.e. `max(<timestamp>)` on the monitored model is older than the expected cadence. The fresh-vs-stale\ndecision is not yours; it was a SQL comparison. You never re-run it, and when the data is fresh this\nstep does not run at all.\n\nYour one job: given the `freshness_reading` (the observed newest timestamp, the observed lag, and the\nexpected cadence), classify how bad the breach is:\n\n- `warn` — modestly overdue (roughly within ~2× the cadence), no compounding signal. The pipeline is\n  probably just late.\n- `critical` — badly overdue (well beyond ~2× the cadence), or the lag is still growing across recent\n  readings, or this model feeds known-critical downstreams. Someone should be paged.\n\nJudge from the lag magnitude relative to the cadence and any history in the reading; do not invent\nnumbers you were not given. Keep it to a reproducible, conservative call — when genuinely on the\nboundary, prefer `warn` and say why.\n\nProduce `severity_verdict` as a compact judgement: the chosen `severity` (`warn` | `critical`) and a\none-line rationale grounded in the lag vs cadence. This feeds the `status` block's `severity` field\nin the verdict envelope; it does not change the fresh/stale verdict itself.",
+      "prompt_fragment": "## read_freshness\n\nYou are the `read_freshness` step of the `monitor_freshness` assertion, bound to the semantic\ncontext `v5-jaffle`.\n\nRun the deterministic freshness assert through the bound query capability — `SELECT\nmax(<timestamp column>)` on the bound model — and compare the observed lag against the expected\ncadence (the `expected_cadence` param, or the MDL's declared cadence). Fresh iff the newest row is\nwithin the cadence; stale otherwise. This is a SQL comparison, not a judgment call: do NOT ask an\nLLM to decide fresh-vs-stale, and do not estimate or guess at a reading you did not query for.\n\nYour one job is to report the reading, not to grade it — severity classification belongs entirely\nto `assess_severity`, which runs next and only when this step finds the data stale.\n\nProduce `freshness_reading`: the observed newest timestamp, the observed lag (against now), the\nexpected cadence, and a `stale` boolean (`true` iff the observed lag exceeds the expected cadence).\nEvery field must come from the query result; never fabricate a reading.\n\n## assess_severity\n\nYou are the `assess_severity` step of the `monitor_freshness` assertion, bound to the semantic\ncontext `v5-jaffle`.\n\nYou run ONLY when the deterministic freshness assert has already decided the data is **stale** —\ni.e. `max(<timestamp>)` on the monitored model is older than the expected cadence. The fresh-vs-stale\ndecision is not yours; it was a SQL comparison. You never re-run it, and when the data is fresh this\nstep does not run at all.\n\nYour one job: given the `freshness_reading` (the observed newest timestamp, the observed lag, and the\nexpected cadence), classify how bad the breach is:\n\n- `warn` — modestly overdue (roughly within ~2× the cadence), no compounding signal. The pipeline is\n  probably just late.\n- `critical` — badly overdue (well beyond ~2× the cadence), or the lag is still growing across recent\n  readings, or this model feeds known-critical downstreams. Someone should be paged.\n\nJudge from the lag magnitude relative to the cadence and any history in the reading; do not invent\nnumbers you were not given. Keep it to a reproducible, conservative call — when genuinely on the\nboundary, prefer `warn` and say why.\n\nProduce `severity_verdict` as a compact judgement: the chosen `severity` (`warn` | `critical`) and a\none-line rationale grounded in the lag vs cadence. This feeds the `status` block's `severity` field\nin the verdict envelope; it does not change the fresh/stale verdict itself.",
       "realization_kind": "tool",
       "required_capabilities": [
         "scheduler",
@@ -138,10 +148,6 @@
         }
       ],
       "lineage": {
-        "consumers": {
-          "dashboards": 0,
-          "queries": 1
-        },
         "edges": 7,
         "nodes": 8,
         "resolvable": true
@@ -184,5 +190,5 @@
     }
   },
   "profile": "genbi-monitor",
-  "warble_ir_version": "0.6"
+  "warble_ir_version": "0.9"
 }

package/profiles/genbi-report/context/binding.yml

@@ -0,0 +1,19 @@
+# Coarse context binding: the whole v5-jaffle semantic layer, bound as a PREPARED document.
+#
+# `kind: prepared` means Warble does not read the semantic layer itself — it reads the JSON document
+# `document:` names, which WrenAI's own `wren-context-loader` generator produced from the project.
+# Warble therefore needs no knowledge of MDL, and the projection Wren hands it is the one Wren
+# controls. The binding stays "coarse" in the original sense: it names the whole project, not a
+# specific metric/grain.
+#
+# `project:` is the layer's IDENTITY, not a path Warble reads, and never the document's path — it is
+# what the compiled prompts call the project the agent is working on. `document:` is the separate
+# field carrying the file. Both resolve relative to this Warble project's own root (the profile
+# directory), not relative to this file.
+#
+# The host rewrites this `project:` line to the user's own wren project at bind time and regenerates
+# `document:`'s file in place; the committed values pin this repo's own v5 example so the profile
+# compiles standalone for CI/dev. See MAINTAINING.md for how to regenerate the committed document.
+kind: prepared
+project: ../../../../examples/v5-jaffle
+document: context/context.json

package/profiles/genbi-report/context/context.json

@@ -0,0 +1,223 @@
+{
+  "context_version": 2,
+  "parseable": true,
+  "metrics": [
+    {
+      "name": "total_revenue",
+      "owner": "order_metrics",
+      "declared": true,
+      "additivity": "additive"
+    },
+    {
+      "name": "order_count",
+      "owner": "order_metrics",
+      "declared": true,
+      "additivity": "additive"
+    },
+    {
+      "name": "id",
+      "owner": "customers",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "id",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "customer_id",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    },
+    {
+      "name": "amount",
+      "owner": "orders",
+      "declared": false,
+      "additivity": null
+    }
+  ],
+  "dimensions": [
+    {
+      "name": "customer_id",
+      "owner": "order_metrics",
+      "is_temporal": false
+    },
+    {
+      "name": "name",
+      "owner": "customers",
+      "is_temporal": false
+    },
+    {
+      "name": "order_date",
+      "owner": "orders",
+      "is_temporal": true
+    }
+  ],
+  "models": [
+    {
+      "name": "customers",
+      "has_timestamp": false,
+      "columns": [
+        "id",
+        "name"
+      ]
+    },
+    {
+      "name": "orders",
+      "has_timestamp": true,
+      "columns": [
+        "id",
+        "customer_id",
+        "order_date",
+        "amount"
+      ]
+    }
+  ],
+  "lineage": {
+    "nodes": [
+      {
+        "id": "model:customers",
+        "kind": "model"
+      },
+      {
+        "id": "model:orders",
+        "kind": "model"
+      },
+      {
+        "id": "rel:orders_customer",
+        "kind": "relationship"
+      },
+      {
+        "id": "cube:order_metrics",
+        "kind": "cube"
+      },
+      {
+        "id": "metric:order_metrics.total_revenue",
+        "kind": "metric"
+      },
+      {
+        "id": "metric:order_metrics.order_count",
+        "kind": "metric"
+      },
+      {
+        "id": "dim:order_metrics.customer_id",
+        "kind": "dimension"
+      },
+      {
+        "id": "query:total-revenue",
+        "kind": "query"
+      }
+    ],
+    "edges": [
+      {
+        "from": "model:orders",
+        "to": "rel:orders_customer"
+      },
+      {
+        "from": "model:customers",
+        "to": "rel:orders_customer"
+      },
+      {
+        "from": "model:orders",
+        "to": "cube:order_metrics"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "metric:order_metrics.total_revenue"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "metric:order_metrics.order_count"
+      },
+      {
+        "from": "cube:order_metrics",
+        "to": "dim:order_metrics.customer_id"
+      },
+      {
+        "from": "model:orders",
+        "to": "query:total-revenue"
+      }
+    ]
+  },
+  "lineage_diagnostics": [],
+  "analysis": {
+    "impact": {
+      "cube:order_metrics": {
+        "downstream": [
+          "dim:order_metrics.customer_id",
+          "metric:order_metrics.order_count",
+          "metric:order_metrics.total_revenue"
+        ],
+        "severity": {
+          "rank": 3,
+          "name": "semantic"
+        }
+      },
+      "dim:order_metrics.customer_id": {
+        "downstream": [],
+        "severity": {
+          "rank": 0,
+          "name": "none"
+        }
+      },
+      "metric:order_metrics.order_count": {
+        "downstream": [],
+        "severity": {
+          "rank": 0,
+          "name": "none"
+        }
+      },
+      "metric:order_metrics.total_revenue": {
+        "downstream": [],
+        "severity": {
+          "rank": 0,
+          "name": "none"
+        }
+      },
+      "model:customers": {
+        "downstream": [
+          "rel:orders_customer"
+        ],
+        "severity": {
+          "rank": 1,
+          "name": "compatibility"
+        }
+      },
+      "model:orders": {
+        "downstream": [
+          "cube:order_metrics",
+          "dim:order_metrics.customer_id",
+          "metric:order_metrics.order_count",
+          "metric:order_metrics.total_revenue",
+          "query:total-revenue",
+          "rel:orders_customer"
+        ],
+        "severity": {
+          "rank": 3,
+          "name": "semantic"
+        }
+      },
+      "query:total-revenue": {
+        "downstream": [],
+        "severity": {
+          "rank": 0,
+          "name": "none"
+        }
+      },
+      "rel:orders_customer": {
+        "downstream": [],
+        "severity": {
+          "rank": 0,
+          "name": "none"
+        }
+      }
+    },
+    "consumers": {
+      "queries": 1,
+      "dashboards": 0
+    }
+  }
+}