@wrenai/genbi 0.0.4 → 0.0.6

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

@@ -1,9 +1,19 @@
-# Coarse context binding: the whole v5-jaffle semantic layer. Since IR v0.3 the Warble front-end
-# builds a real MdlContext over the bound project and evaluates context_precondition predicates
-# against it — it does introspect MDL. The binding stays "coarse" in a different sense: it names the
-# whole project, not a specific metric/grain.
+# Coarse context binding: the whole v5-jaffle semantic layer, bound as a PREPARED document.
 #
-# The host rewrites this `project:` line to the user's own wren project at bind time; the committed
-# value pins this repo's own v5 example so the profile compiles standalone for CI/dev.
-# Path is relative to this profile directory.
+# `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-default/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-default/ir.golden.json

@@ -4,6 +4,7 @@
       "borrowed_actions": [
         "introspect"
       ],
+      "brief": "Data access in this deployment goes through the `wren` CLI. Introspect the semantic layer\nwith `wren context show` (and, where available, `wren cube list`) to read models, columns,\nrelationships, and metrics/cubes — do not assume the schema.",
       "context_binding": {
         "binding_mode": "runtime_selected",
         "project": "../../../../examples/v5-jaffle"
@@ -14,7 +15,7 @@
         }
       ],
       "context_requirements": [
-        "a wren project (semantic layer) to introspect"
+        "a bound semantic context (semantic layer) to introspect"
       ],
       "description": "Survey the bound semantic model and report what can be asked of it — its models, metrics, dimensions and grain — without querying any rows. Use it to orient before analysis, or when someone asks what data is available; it answers questions *about* the model, not questions *from* the data.",
       "effect": {
@@ -23,6 +24,7 @@
         },
         "render_blocks": []
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "coverage"
@@ -48,7 +50,7 @@
           "consumes": [],
           "name": "summarize_semantics",
           "produces": "semantic_summary",
-          "prompt": "You introspect the `v5-jaffle` wren project (a semantic layer at `../../../../examples/v5-jaffle`) and return a\nstructured summary of what it contains — the map the other GenBI components build on.\n\n- Introspect the semantic layer with the `wren` CLI: run `wren context show` (and, if available,\n  `wren cube list`) to read the models, columns, relationships, and metrics/cubes. This is the\n  `raw_introspect_result` you consume — read it, do not assume the schema.\n- Cover the FULL set: every model, its key columns and their roles (dimension vs measure vs\n  time), the relationships between models, and any defined metrics/cubes. Do not drop entries to\n  keep the summary short — coverage is the point.\n- Produce `semantic_summary`: a compact structured listing of every model and metric found. Your\n  FINAL message must be a single JSON object of the form\n  `{\"columns\": [\"model\"], \"rows\": [[\"<model_name>\"], ...]}` listing every model in the layer\n  (one row per model), so coverage can be checked deterministically. You may add a short prose\n  summary after the JSON.",
+          "prompt": "You introspect the bound semantic context `v5-jaffle` (a semantic layer at `../../../../examples/v5-jaffle`)\nand return a structured summary of what it contains — the map the other GenBI components build on.\n\n- Introspect the semantic layer using the bound introspection capability to read the models,\n  columns, relationships, and metrics/cubes. This is the `raw_introspect_result` you consume — read\n  it, do not assume the schema.\n- Cover the FULL set: every model, its key columns and their roles (dimension vs measure vs\n  time), the relationships between models, and any defined metrics/cubes. Do not drop entries to\n  keep the summary short — coverage is the point.\n- Produce `semantic_summary`: a compact structured listing of every model and metric found. Your\n  FINAL message must be a single JSON object of the form\n  `{\"columns\": [\"model\"], \"rows\": [[\"<model_name>\"], ...]}` listing every model in the layer\n  (one row per model), so coverage can be checked deterministically. You may add a short prose\n  summary after the JSON.",
           "tier": "cheap",
           "when": null
         }
@@ -63,7 +65,7 @@
         ],
         "status": "pass"
       },
-      "prompt_fragment": "## summarize_semantics\n\nYou introspect the `v5-jaffle` wren project (a semantic layer at `../../../../examples/v5-jaffle`) and return a\nstructured summary of what it contains — the map the other GenBI components build on.\n\n- Introspect the semantic layer with the `wren` CLI: run `wren context show` (and, if available,\n  `wren cube list`) to read the models, columns, relationships, and metrics/cubes. This is the\n  `raw_introspect_result` you consume — read it, do not assume the schema.\n- Cover the FULL set: every model, its key columns and their roles (dimension vs measure vs\n  time), the relationships between models, and any defined metrics/cubes. Do not drop entries to\n  keep the summary short — coverage is the point.\n- Produce `semantic_summary`: a compact structured listing of every model and metric found. Your\n  FINAL message must be a single JSON object of the form\n  `{\"columns\": [\"model\"], \"rows\": [[\"<model_name>\"], ...]}` listing every model in the layer\n  (one row per model), so coverage can be checked deterministically. You may add a short prose\n  summary after the JSON.",
+      "prompt_fragment": "## summarize_semantics\n\nYou introspect the bound semantic context `v5-jaffle` (a semantic layer at `../../../../examples/v5-jaffle`)\nand return a structured summary of what it contains — the map the other GenBI components build on.\n\n- Introspect the semantic layer using the bound introspection capability to read the models,\n  columns, relationships, and metrics/cubes. This is the `raw_introspect_result` you consume — read\n  it, do not assume the schema.\n- Cover the FULL set: every model, its key columns and their roles (dimension vs measure vs\n  time), the relationships between models, and any defined metrics/cubes. Do not drop entries to\n  keep the summary short — coverage is the point.\n- Produce `semantic_summary`: a compact structured listing of every model and metric found. Your\n  FINAL message must be a single JSON object of the form\n  `{\"columns\": [\"model\"], \"rows\": [[\"<model_name>\"], ...]}` listing every model in the layer\n  (one row per model), so coverage can be checked deterministically. You may add a short prose\n  summary after the JSON.",
       "realization_kind": "skill",
       "required_capabilities": [
         "semantic_introspection",
@@ -77,6 +79,7 @@
     },
     {
       "borrowed_actions": [],
+      "brief": "Data access in this deployment goes through the `wren` CLI. If you need to introspect the\nschema, run `wren context show`. Query the semantic layer with `wren -q -o json -s '<SQL>'`,\nwhich returns JSON; object-shaped rows are also valid — preserve their values exactly. Never\nhand-write SQL against raw tables outside the model.\nFor time-series questions, use the requested date range. If none is given, use the full\navailable data range and disclose that choice; never silently pick a recent N-week window.\nDistinguish calendar-relative dates from a window anchored on the latest data date. Preserve\nexplicit calendar-relative requests even if the data is old; do not silently re-anchor them.\nExplain exact date bounds, the date column, week start, timezone if known, and partial periods.\nUse semantic metric definitions where available. Otherwise state the chosen interpretation:\ndistinct ordering customers, first-order customers and cumulative customers are different.\nDo not present synonymous counts as different metrics. Do not invent registration dates or\nmetric meanings absent from context. Name the answer SQL in the terminal definition so that\nlater date-bound checks cannot replace the answering table.",
       "context_binding": {
         "binding_mode": "runtime_selected",
         "project": "../../../../examples/v5-jaffle"
@@ -87,31 +90,16 @@
         }
       ],
       "context_requirements": [
-        "a wren project (semantic layer) to query"
+        "a bound semantic context (semantic layer) to query"
       ],
       "description": "Answer one natural-language question about the bound semantic model: resolve the intent, generate SQL against the semantic layer, run it read-only, and repair the query if it fails. Returns a result table with the definitions it relied on. Use it for a single question with a single answer, not for a multi-panel overview.",
       "effect": {
         "outcome": {
           "kind": "none"
         },
-        "render_blocks": [
-          {
-            "fields": {
-              "columns": "string[]",
-              "rows": "row[]"
-            },
-            "type": "table"
-          },
-          {
-            "fields": {
-              "filters": "string[]",
-              "source_tables": "string[]",
-              "sql": "string"
-            },
-            "type": "definition"
-          }
-        ]
+        "render_blocks": []
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "execution_accuracy",
@@ -148,11 +136,14 @@
       "id": "answer_query",
       "llm_calls": [
         {
+          "capabilities": [
+            "llm:cheap"
+          ],
           "conditional": false,
           "consumes": [],
           "name": "resolve_intent",
           "produces": "query_intent",
-          "prompt": "You answer a single data question over the `v5-jaffle` wren project (a semantic layer at\n`../../../../examples/v5-jaffle`). This first step resolves the user's question into a concrete query intent.\n\n- If unsure of the schema, introspect first: `wren context show`.\n- Identify which model(s), metric(s), dimension(s), filters, grouping, and ordering the question\n  implies. Resolve ambiguous business terms to concrete columns/metrics in the semantic layer.\n- Produce `query_intent`: a short, explicit statement of exactly what to compute (measures,\n  grouping, filters, ordering, row limit) — enough for the next step to write SQL without\n  re-reading the question.",
+          "prompt": "You answer a single data question over the bound semantic context `v5-jaffle` (a semantic\nlayer at `../../../../examples/v5-jaffle`). This first step resolves the user's question into a concrete query intent.\n\n- Do not call any tool in this step: it declares no data capability. Resolve the question from the\n  semantic context you were given; the next step writes and runs the query.\n- Identify which model(s), metric(s), dimension(s), filters, grouping, and ordering the question\n  implies. Resolve ambiguous business terms to concrete columns/metrics in the semantic layer.\n- Produce `query_intent`: a short, explicit statement of exactly what to compute (measures,\n  grouping, filters, ordering, row limit) — enough for the next step to write SQL without\n  re-reading the question.",
           "tier": "cheap",
           "when": null
         },
@@ -163,7 +154,7 @@
           ],
           "name": "generate_sql",
           "produces": "query_result",
-          "prompt": "Given the resolved `query_intent`, write and execute the query through the semantic layer.\n\n- Query ONLY through the wren CLI, which returns JSON: `wren -q -o json -s '<SQL>'`. Never\n  hand-write SQL against raw tables outside the model — always go through the semantic layer.\n- Respect the guardrails: read-only only, keep within the row limit, and prefer a deterministic\n  ordering when the question implies a ranking or a top-N.\n- **Verify the result set (deterministic gate — required before answering).** After the query runs,\n  check it is legitimate: it actually executed (no error), it is non-empty where a value is expected,\n  the types/units are sane, and the grain matches the question. Record whether it passed.\n- On success, produce `query_result` as exactly one object with this shape and no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"], \"filters\": [\"...\"]}}\n  ```\n  Object rows from `wren` are also valid; preserve their values exactly. Emit numbers as numbers.\n  Set `verified: true` only after both execution and the deterministic result-set validation pass.\n  The summary must state the useful conclusion, not merely describe the columns or claim that the\n  query succeeded. `definition` is run-level provenance only; do not invent formal lineage.\n- On failure, keep the attempted SQL, execution/validation evidence, and stable non-secret error in\n  `query_result` so the declared repair step can diagnose it. Never mark a failed result verified.",
+          "prompt": "Given the resolved `query_intent`, write and execute the query through the semantic layer.\n\n- Query ONLY through the bound query capability, which returns structured (JSON) results. Never\n  hand-write SQL against raw tables outside the model — always go through the semantic layer.\n- Respect the guardrails: read-only only, keep within the row limit, and prefer a deterministic\n  ordering when the question implies a ranking or a top-N.\n- **Verify the result set (deterministic gate — required before answering).** After the query runs,\n  check it is legitimate: it actually executed (no error), it is non-empty where a value is expected,\n  the types/units are sane, and the grain matches the question. Record whether it passed.\n- On success, produce `query_result` as exactly one object with this shape and no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"query_id\": \"<the query_id the tool result returned>\"}}\n  ```\n  Object-shaped rows are also valid; preserve their values exactly. Emit numbers as numbers.\n  Set `verified: true` only after both execution and the deterministic result-set validation pass.\n  The summary must state the useful conclusion, not merely describe the columns or claim that the\n  query succeeded. `definition` is run-level provenance only; do not invent formal lineage.\n- When the tool result carries a `query_id`, never copy SQL, filters or source tables into\n  `definition`: cite `{\"query_id\": …}` only. When it carries none, cite\n  `{\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"]}` and nothing else. No shape of\n  `definition` has a `filters` key.\n- On failure, keep the attempted SQL, execution/validation evidence, and stable non-secret error in\n  `query_result` so the declared repair step can diagnose it. Never mark a failed result verified.\n- Your final message is `query_result` as JSON and nothing else: no heading, no sentence before or\n  after it, no Markdown fence, no reasoning tags. Every string closed and every bracket matched; it\n  must parse as JSON.",
           "tier": "strong",
           "when": null
         },
@@ -174,7 +165,7 @@
           ],
           "name": "repair_sql",
           "produces": "repaired_result",
-          "prompt": "Repair step — runs ONLY when `query_result` came back with an execution error or an empty/obviously\nwrong result. If the previous step succeeded with a sensible result, do nothing and pass it through.\n\n- Diagnose the failure from the error text (unknown column, bad join, type mismatch, wrong grain),\n  fix the SQL, and re-run it through `wren -q -o json -s '<SQL>'`. Bound your attempts — a few\n  retries at most; do not loop indefinitely (retry depth is this step's concern, not the profile's).\n- **If the result still cannot be validated, REFUSE.** Do not fabricate a number. Emit\n  `{\"verified\": false, \"refused\": true, \"reason\": \"<why it could not be verified>\"}` and stop.\n- Produce `repaired_result`. On success return exactly the same canonical rich result shape as\n  `generate_sql`, with no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"], \"filters\": [\"...\"]}}\n  ```\n  Object rows from `wren` are also valid; preserve their values exactly and emit numbers as numbers.\n  Set `verified: true` only when the repaired query ran and its result set passed validation. The\n  summary must state the useful conclusion grounded only in those rows. The `definition` is\n  run-level provenance only (the query behind this answer) — do not invent unit/owner/formal-metric\n  lineage (out of scope for this run-level card).",
+          "prompt": "Repair step — runs ONLY in one of these cases:\n\n- When `query_result` is `{\"status\": \"error\", \"code\": \"step_failed\", \"reason\":\n  \"terminal_unparseable: …\", \"text\": …}`, the previous answer is in `text`; when `query_result`\n  is otherwise not valid JSON (prose around it, an unterminated string, a stray reasoning tag),\n  the previous answer is that raw text. Re-emit that SAME answer as one JSON object in the canonical\n  shape below, citing its query by its `query_id` (or, when its tool result carried none,\n  `{\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"]}`).\n  Run no new query, and put nothing else in the message.\n- `query_result` came back with an execution error or an empty/obviously wrong result.\n\nIf the previous step succeeded with a valid JSON, sensible result, do nothing and pass it through.\n\n- For an execution failure (the second case above): diagnose the failure from the error text (unknown column, bad join, type mismatch, wrong grain),\n  fix the SQL, and re-run it through the bound query capability. Bound your attempts — a few\n  retries at most; do not loop indefinitely (retry depth is this step's concern, not the profile's).\n- **If the result still cannot be validated, REFUSE.** Do not fabricate a number. Emit\n  `{\"verified\": false, \"refused\": true, \"reason\": \"<why it could not be verified>\"}` and stop.\n- Produce `repaired_result`. On success return exactly the same canonical rich result shape as\n  `generate_sql`, with no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"query_id\": \"<the query_id the tool result returned>\"}}\n  ```\n  Object-shaped rows are also valid; preserve their values exactly and emit numbers as numbers.\n  Set `verified: true` only when the repaired query ran and its result set passed validation. The\n  summary must state the useful conclusion grounded only in those rows. The `definition` is\n  run-level provenance only (the query behind this answer) — do not invent unit/owner/formal-metric\n  lineage (out of scope for this run-level card).\n  When the tool result carries a `query_id`, never copy SQL, filters or source tables into\n  `definition`: cite `{\"query_id\": …}` only. When it carries none, cite\n  `{\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"]}` and nothing else. No shape of\n  `definition` has a `filters` key.\n  Your final message is the JSON object (or the refusal object) and nothing else: no heading, no\n  sentence before or after it, no Markdown fence, no reasoning tags. Every string closed and every\n  bracket matched; it must parse as JSON.",
           "tier": "strong",
           "when": {
             "guard": "on_failure",
@@ -192,7 +183,7 @@
         ],
         "status": "pass"
       },
-      "prompt_fragment": "## resolve_intent\n\nYou answer a single data question over the `v5-jaffle` wren project (a semantic layer at\n`../../../../examples/v5-jaffle`). This first step resolves the user's question into a concrete query intent.\n\n- If unsure of the schema, introspect first: `wren context show`.\n- Identify which model(s), metric(s), dimension(s), filters, grouping, and ordering the question\n  implies. Resolve ambiguous business terms to concrete columns/metrics in the semantic layer.\n- Produce `query_intent`: a short, explicit statement of exactly what to compute (measures,\n  grouping, filters, ordering, row limit) — enough for the next step to write SQL without\n  re-reading the question.\n\n## generate_sql\n\nGiven the resolved `query_intent`, write and execute the query through the semantic layer.\n\n- Query ONLY through the wren CLI, which returns JSON: `wren -q -o json -s '<SQL>'`. Never\n  hand-write SQL against raw tables outside the model — always go through the semantic layer.\n- Respect the guardrails: read-only only, keep within the row limit, and prefer a deterministic\n  ordering when the question implies a ranking or a top-N.\n- **Verify the result set (deterministic gate — required before answering).** After the query runs,\n  check it is legitimate: it actually executed (no error), it is non-empty where a value is expected,\n  the types/units are sane, and the grain matches the question. Record whether it passed.\n- On success, produce `query_result` as exactly one object with this shape and no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"], \"filters\": [\"...\"]}}\n  ```\n  Object rows from `wren` are also valid; preserve their values exactly. Emit numbers as numbers.\n  Set `verified: true` only after both execution and the deterministic result-set validation pass.\n  The summary must state the useful conclusion, not merely describe the columns or claim that the\n  query succeeded. `definition` is run-level provenance only; do not invent formal lineage.\n- On failure, keep the attempted SQL, execution/validation evidence, and stable non-secret error in\n  `query_result` so the declared repair step can diagnose it. Never mark a failed result verified.\n\n## repair_sql\n\nRepair step — runs ONLY when `query_result` came back with an execution error or an empty/obviously\nwrong result. If the previous step succeeded with a sensible result, do nothing and pass it through.\n\n- Diagnose the failure from the error text (unknown column, bad join, type mismatch, wrong grain),\n  fix the SQL, and re-run it through `wren -q -o json -s '<SQL>'`. Bound your attempts — a few\n  retries at most; do not loop indefinitely (retry depth is this step's concern, not the profile's).\n- **If the result still cannot be validated, REFUSE.** Do not fabricate a number. Emit\n  `{\"verified\": false, \"refused\": true, \"reason\": \"<why it could not be verified>\"}` and stop.\n- Produce `repaired_result`. On success return exactly the same canonical rich result shape as\n  `generate_sql`, with no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"], \"filters\": [\"...\"]}}\n  ```\n  Object rows from `wren` are also valid; preserve their values exactly and emit numbers as numbers.\n  Set `verified: true` only when the repaired query ran and its result set passed validation. The\n  summary must state the useful conclusion grounded only in those rows. The `definition` is\n  run-level provenance only (the query behind this answer) — do not invent unit/owner/formal-metric\n  lineage (out of scope for this run-level card).",
+      "prompt_fragment": "## resolve_intent\n\nYou answer a single data question over the bound semantic context `v5-jaffle` (a semantic\nlayer at `../../../../examples/v5-jaffle`). This first step resolves the user's question into a concrete query intent.\n\n- Do not call any tool in this step: it declares no data capability. Resolve the question from the\n  semantic context you were given; the next step writes and runs the query.\n- Identify which model(s), metric(s), dimension(s), filters, grouping, and ordering the question\n  implies. Resolve ambiguous business terms to concrete columns/metrics in the semantic layer.\n- Produce `query_intent`: a short, explicit statement of exactly what to compute (measures,\n  grouping, filters, ordering, row limit) — enough for the next step to write SQL without\n  re-reading the question.\n\n## generate_sql\n\nGiven the resolved `query_intent`, write and execute the query through the semantic layer.\n\n- Query ONLY through the bound query capability, which returns structured (JSON) results. Never\n  hand-write SQL against raw tables outside the model — always go through the semantic layer.\n- Respect the guardrails: read-only only, keep within the row limit, and prefer a deterministic\n  ordering when the question implies a ranking or a top-N.\n- **Verify the result set (deterministic gate — required before answering).** After the query runs,\n  check it is legitimate: it actually executed (no error), it is non-empty where a value is expected,\n  the types/units are sane, and the grain matches the question. Record whether it passed.\n- On success, produce `query_result` as exactly one object with this shape and no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"query_id\": \"<the query_id the tool result returned>\"}}\n  ```\n  Object-shaped rows are also valid; preserve their values exactly. Emit numbers as numbers.\n  Set `verified: true` only after both execution and the deterministic result-set validation pass.\n  The summary must state the useful conclusion, not merely describe the columns or claim that the\n  query succeeded. `definition` is run-level provenance only; do not invent formal lineage.\n- When the tool result carries a `query_id`, never copy SQL, filters or source tables into\n  `definition`: cite `{\"query_id\": …}` only. When it carries none, cite\n  `{\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"]}` and nothing else. No shape of\n  `definition` has a `filters` key.\n- On failure, keep the attempted SQL, execution/validation evidence, and stable non-secret error in\n  `query_result` so the declared repair step can diagnose it. Never mark a failed result verified.\n- Your final message is `query_result` as JSON and nothing else: no heading, no sentence before or\n  after it, no Markdown fence, no reasoning tags. Every string closed and every bracket matched; it\n  must parse as JSON.\n\n## repair_sql\n\nRepair step — runs ONLY in one of these cases:\n\n- When `query_result` is `{\"status\": \"error\", \"code\": \"step_failed\", \"reason\":\n  \"terminal_unparseable: …\", \"text\": …}`, the previous answer is in `text`; when `query_result`\n  is otherwise not valid JSON (prose around it, an unterminated string, a stray reasoning tag),\n  the previous answer is that raw text. Re-emit that SAME answer as one JSON object in the canonical\n  shape below, citing its query by its `query_id` (or, when its tool result carried none,\n  `{\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"]}`).\n  Run no new query, and put nothing else in the message.\n- `query_result` came back with an execution error or an empty/obviously wrong result.\n\nIf the previous step succeeded with a valid JSON, sensible result, do nothing and pass it through.\n\n- For an execution failure (the second case above): diagnose the failure from the error text (unknown column, bad join, type mismatch, wrong grain),\n  fix the SQL, and re-run it through the bound query capability. Bound your attempts — a few\n  retries at most; do not loop indefinitely (retry depth is this step's concern, not the profile's).\n- **If the result still cannot be validated, REFUSE.** Do not fabricate a number. Emit\n  `{\"verified\": false, \"refused\": true, \"reason\": \"<why it could not be verified>\"}` and stop.\n- Produce `repaired_result`. On success return exactly the same canonical rich result shape as\n  `generate_sql`, with no extra keys:\n  ```\n  {\"columns\": [\"col1\", ...], \"rows\": [[v1, ...], ...],\n   \"summary\": \"<a concise prose answer grounded only in the returned rows>\",\n   \"verified\": true,\n   \"definition\": {\"query_id\": \"<the query_id the tool result returned>\"}}\n  ```\n  Object-shaped rows are also valid; preserve their values exactly and emit numbers as numbers.\n  Set `verified: true` only when the repaired query ran and its result set passed validation. The\n  summary must state the useful conclusion grounded only in those rows. The `definition` is\n  run-level provenance only (the query behind this answer) — do not invent unit/owner/formal-metric\n  lineage (out of scope for this run-level card).\n  When the tool result carries a `query_id`, never copy SQL, filters or source tables into\n  `definition`: cite `{\"query_id\": …}` only. When it carries none, cite\n  `{\"sql\": \"<the exact SQL you ran>\", \"source_tables\": [\"...\"]}` and nothing else. No shape of\n  `definition` has a `filters` key.\n  Your final message is the JSON object (or the refusal object) and nothing else: no heading, no\n  sentence before or after it, no Markdown fence, no reasoning tags. Every string closed and every\n  bracket matched; it must parse as JSON.",
       "realization_kind": "skill",
       "required_capabilities": [
         "sql_execution:read_only",
@@ -211,15 +202,16 @@
         "topic_default": "overview"
       },
       "borrowed_actions": [],
+      "brief": "Data access in this deployment goes through the `wren` CLI. Discover the schema at query\ntime with `wren context show`, `wren cube list`, and `wren cube describe <cube>` — do not\nassume it. Run each panel query with `wren -q -o json -s '<SQL>'`; every query goes through\n`wren`, never hand-written SQL against raw tables outside the model.",
       "context_binding": {
         "binding_mode": "runtime_selected",
         "project": "../../../../examples/v5-jaffle"
       },
       "context_precondition": [],
       "context_requirements": [
-        "a wren project (semantic layer) to build dashboards over"
+        "a bound semantic context (semantic layer) to build dashboards over"
       ],
-      "description": "Build a multi-panel dashboard on a topic: plan which panels answer it, run each panel's query read-only, and compose them into one laid-out result of KPI cards, tables and charts. Use it when someone wants an overview of a subject from several angles rather than one specific answer.",
+      "description": "Build a multi-panel dashboard on a topic: plan which panel questions answer it, obtain a verified result for each panel through the profile's bound answer behavior, and compose them into one laid-out result of KPI cards, tables and charts. Use it when someone wants an overview of a subject from several angles rather than one specific answer.",
       "effect": {
         "outcome": {
           "kind": "none"
@@ -252,7 +244,7 @@
           },
           {
             "fields": {
-              "filters": "string[]",
+              "filters": "string[]?",
               "source_tables": "string[]",
               "sql": "string"
             },
@@ -260,6 +252,7 @@
           }
         ]
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "panel_validity",
@@ -291,18 +284,24 @@
           "consumes": [],
           "name": "plan_dashboard",
           "produces": "dashboard_plan",
-          "prompt": "You build data dashboards over the `v5-jaffle` wren project (a semantic layer at\n`../../../../examples/v5-jaffle`).\n\nGiven the user's topic, plan the dashboard:\n\n- If the request doesn't name a fresh topic of its own — it refers back to a dashboard already in\n  play (\"the dashboard,\" \"it,\" \"that dashboard\"), or is a bare \"create an artifact for it\" /\n  \"build it\" follow-up — do NOT stop here to ask what dashboard or what topic. Take the topic from\n  the conversation so far (whatever dashboard/topic was most recently discussed); if there is\n  truly none, fall back to an overview of the project's key metrics. Either way, keep planning:\n  this step always ends with a `dashboard_plan`, never a clarifying question.\n- Discover available models, columns, and cubes **at query time** using the `wren` CLI\n  (`wren context show`, `wren cube list`, `wren cube describe <cube>`). Do not assume the schema —\n  introspect it.\n- Decide which metrics and dimensions answer the topic, and what panels are needed\n  (KPI cards for headline numbers, a chart for trends/breakdowns, a table for detail).\n- Produce `dashboard_plan`: for each panel, the panel type (kpi_card | table | chart) and the exact\n  query (through the semantic layer) that populates it. Every query goes through `wren`; never\n  hand-write SQL against raw tables outside the model.",
+          "prompt": "You build data dashboards over the bound semantic context `v5-jaffle` (a semantic layer at\n`../../../../examples/v5-jaffle`).\n\nGiven the user's topic, plan the dashboard:\n\n- If the request doesn't name a fresh topic of its own — it refers back to a dashboard already in\n  play (\"the dashboard,\" \"it,\" \"that dashboard\"), or is a bare \"create an artifact for it\" /\n  \"build it\" follow-up — do NOT stop here to ask what dashboard or what topic. Take the topic from\n  the conversation so far (whatever dashboard/topic was most recently discussed); if there is\n  truly none, fall back to an overview of the project's key metrics. Either way, keep planning:\n  this step always ends with a `dashboard_plan`, never a clarifying question.\n- Decide which business questions answer the topic, and what panels are needed\n  (KPI cards for headline numbers, a chart for trends/breakdowns, a table for detail).\n- Produce `dashboard_plan`: for each panel, give its title, panel type (kpi_card | table | chart),\n  and one self-contained natural-language data question whose verified answer will populate it.\n  Do not inspect the schema, write a query, or invent data in this step; the bound answer behavior\n  resolves each panel question against its own semantic context and query authority.",
           "tier": "strong",
           "when": null
         },
         {
+          "component_calls": [
+            {
+              "alias": "answer",
+              "component": "answer_query"
+            }
+          ],
           "conditional": false,
           "consumes": [
             "dashboard_plan"
           ],
           "name": "compose_layout",
           "produces": "dashboard",
-          "prompt": "Given the `dashboard_plan`, run each panel's query and compose the dashboard.\n\n- Run each planned panel query with the `wren` CLI (`wren -q -o json -s '<SQL>'`) and collect the\n  results — these are the `panel_results` you consume. (This inlines the query behavior; it does not\n  call a separate query component.)\n- Assemble each panel into a typed render block conforming to the render contract:\n  `kpi_card` for headline numbers, `chart` for trends/breakdowns, `table` for detail.\n- Produce `dashboard`: follow the \"Render output\" instructions the dispatcher appends below for the\n  active render flavor — emit the `{ blocks, summary }` envelope (programmatic) or write the HTML\n  (prompt). The blocks must carry real values from `panel_results`, not placeholders.\n- The rendered dashboard IS the artifact. Never ask the user what kind of artifact they want, and\n  never offer alternatives — saving the plan/JSON to a file, exporting to CSV, \"something else?\",\n  etc. Whatever the user called it (\"an artifact,\" \"a report,\" \"the dashboard\"), this step's only\n  job is to compose it and produce `dashboard` per the render flavor above; don't stop to\n  clarify format, and don't do anything else instead (no writing files outside what \"Render\n  output\" already directs).",
+          "prompt": "Given the `dashboard_plan`, obtain each panel's verified answer and compose the dashboard.\n\n- For every planned panel, call the logical `answer` alias once with a concise request to answer\n  that panel's natural-language data question. Include the panel title and type in the optional\n  structured input. Call the same alias again for every additional panel; do not combine unrelated\n  panels into one request merely to avoid repeated calls.\n- Accept a panel result only when the call returns `status: \"ok\"`, `output.kind: \"value\"`, and a\n  value containing `verified: true`, `columns`, `rows`, `summary`, and `definition`. Refuse the\n  dashboard rather than using a refused, failed, unverified, malformed, or placeholder result.\n- Assemble each panel into a typed render block conforming to the render contract:\n  `kpi_card` for headline numbers, `chart` for trends/breakdowns, `table` for detail. Panels reach\n  this step with SQL provenance; a host that issues `query_id`s resolves them first. Derive the\n  dashboard's definition block from the accepted panel definitions: copy `sql` and `source_tables`\n  when the panel carries them, include `filters` only if the panel carries them, and never invent\n  provenance.\n- Produce `dashboard`: follow the \"Render output\" instructions the dispatcher appends below for the\n  active render flavor — emit the `{ blocks, summary }` envelope (programmatic) or write the HTML\n  (prompt). The blocks must carry real values from the accepted panel results, not placeholders.\n- The rendered dashboard IS the artifact. Never ask the user what kind of artifact they want, and\n  never offer alternatives — saving the plan/JSON to a file, exporting to CSV, \"something else?\",\n  etc. Whatever the user called it (\"an artifact,\" \"a report,\" \"the dashboard\"), this step's only\n  job is to compose it and produce `dashboard` per the render flavor above; don't stop to\n  clarify format, and don't do anything else instead (no writing files outside what \"Render\n  output\" already directs).",
           "tier": "cheap",
           "when": null
         }
@@ -318,16 +317,15 @@
         "checks": [],
         "status": "pass"
       },
-      "prompt_fragment": "## plan_dashboard\n\nYou build data dashboards over the `v5-jaffle` wren project (a semantic layer at\n`../../../../examples/v5-jaffle`).\n\nGiven the user's topic, plan the dashboard:\n\n- If the request doesn't name a fresh topic of its own — it refers back to a dashboard already in\n  play (\"the dashboard,\" \"it,\" \"that dashboard\"), or is a bare \"create an artifact for it\" /\n  \"build it\" follow-up — do NOT stop here to ask what dashboard or what topic. Take the topic from\n  the conversation so far (whatever dashboard/topic was most recently discussed); if there is\n  truly none, fall back to an overview of the project's key metrics. Either way, keep planning:\n  this step always ends with a `dashboard_plan`, never a clarifying question.\n- Discover available models, columns, and cubes **at query time** using the `wren` CLI\n  (`wren context show`, `wren cube list`, `wren cube describe <cube>`). Do not assume the schema —\n  introspect it.\n- Decide which metrics and dimensions answer the topic, and what panels are needed\n  (KPI cards for headline numbers, a chart for trends/breakdowns, a table for detail).\n- Produce `dashboard_plan`: for each panel, the panel type (kpi_card | table | chart) and the exact\n  query (through the semantic layer) that populates it. Every query goes through `wren`; never\n  hand-write SQL against raw tables outside the model.\n\n## compose_layout\n\nGiven the `dashboard_plan`, run each panel's query and compose the dashboard.\n\n- Run each planned panel query with the `wren` CLI (`wren -q -o json -s '<SQL>'`) and collect the\n  results — these are the `panel_results` you consume. (This inlines the query behavior; it does not\n  call a separate query component.)\n- Assemble each panel into a typed render block conforming to the render contract:\n  `kpi_card` for headline numbers, `chart` for trends/breakdowns, `table` for detail.\n- Produce `dashboard`: follow the \"Render output\" instructions the dispatcher appends below for the\n  active render flavor — emit the `{ blocks, summary }` envelope (programmatic) or write the HTML\n  (prompt). The blocks must carry real values from `panel_results`, not placeholders.\n- The rendered dashboard IS the artifact. Never ask the user what kind of artifact they want, and\n  never offer alternatives — saving the plan/JSON to a file, exporting to CSV, \"something else?\",\n  etc. Whatever the user called it (\"an artifact,\" \"a report,\" \"the dashboard\"), this step's only\n  job is to compose it and produce `dashboard` per the render flavor above; don't stop to\n  clarify format, and don't do anything else instead (no writing files outside what \"Render\n  output\" already directs).",
+      "prompt_fragment": "## plan_dashboard\n\nYou build data dashboards over the bound semantic context `v5-jaffle` (a semantic layer at\n`../../../../examples/v5-jaffle`).\n\nGiven the user's topic, plan the dashboard:\n\n- If the request doesn't name a fresh topic of its own — it refers back to a dashboard already in\n  play (\"the dashboard,\" \"it,\" \"that dashboard\"), or is a bare \"create an artifact for it\" /\n  \"build it\" follow-up — do NOT stop here to ask what dashboard or what topic. Take the topic from\n  the conversation so far (whatever dashboard/topic was most recently discussed); if there is\n  truly none, fall back to an overview of the project's key metrics. Either way, keep planning:\n  this step always ends with a `dashboard_plan`, never a clarifying question.\n- Decide which business questions answer the topic, and what panels are needed\n  (KPI cards for headline numbers, a chart for trends/breakdowns, a table for detail).\n- Produce `dashboard_plan`: for each panel, give its title, panel type (kpi_card | table | chart),\n  and one self-contained natural-language data question whose verified answer will populate it.\n  Do not inspect the schema, write a query, or invent data in this step; the bound answer behavior\n  resolves each panel question against its own semantic context and query authority.\n\n## compose_layout\n\nGiven the `dashboard_plan`, obtain each panel's verified answer and compose the dashboard.\n\n- For every planned panel, call the logical `answer` alias once with a concise request to answer\n  that panel's natural-language data question. Include the panel title and type in the optional\n  structured input. Call the same alias again for every additional panel; do not combine unrelated\n  panels into one request merely to avoid repeated calls.\n- Accept a panel result only when the call returns `status: \"ok\"`, `output.kind: \"value\"`, and a\n  value containing `verified: true`, `columns`, `rows`, `summary`, and `definition`. Refuse the\n  dashboard rather than using a refused, failed, unverified, malformed, or placeholder result.\n- Assemble each panel into a typed render block conforming to the render contract:\n  `kpi_card` for headline numbers, `chart` for trends/breakdowns, `table` for detail. Panels reach\n  this step with SQL provenance; a host that issues `query_id`s resolves them first. Derive the\n  dashboard's definition block from the accepted panel definitions: copy `sql` and `source_tables`\n  when the panel carries them, include `filters` only if the panel carries them, and never invent\n  provenance.\n- Produce `dashboard`: follow the \"Render output\" instructions the dispatcher appends below for the\n  active render flavor — emit the `{ blocks, summary }` envelope (programmatic) or write the HTML\n  (prompt). The blocks must carry real values from the accepted panel results, not placeholders.\n- The rendered dashboard IS the artifact. Never ask the user what kind of artifact they want, and\n  never offer alternatives — saving the plan/JSON to a file, exporting to CSV, \"something else?\",\n  etc. Whatever the user called it (\"an artifact,\" \"a report,\" \"the dashboard\"), this step's only\n  job is to compose it and produce `dashboard` per the render flavor above; don't stop to\n  clarify format, and don't do anything else instead (no writing files outside what \"Render\n  output\" already directs).",
       "realization_kind": "skill",
       "required_capabilities": [
-        "sql_execution:read_only",
-        "genbi_build",
         "render_contract",
         "artifact_write",
         "llm:per_step_tier",
         "llm:strong",
-        "llm:cheap"
+        "llm:cheap",
+        "component_invocation"
       ],
       "trigger": {
         "kind": "one_shot"
@@ -337,13 +335,14 @@
     },
     {
       "borrowed_actions": [],
+      "brief": "Data access in this deployment goes through the `wren` CLI. Introspect the layer as needed\nwith `wren context show`. Run the decomposition queries with `wren -q -o json -s '<SQL>'`.",
       "context_binding": {
         "binding_mode": "runtime_selected",
         "project": "../../../../examples/v5-jaffle"
       },
       "context_precondition": [],
       "context_requirements": [
-        "a wren project with an additive metric plus a time dimension and a groupable dimension"
+        "a bound semantic context with an additive metric plus a time dimension and a groupable dimension"
       ],
       "description": "Explain why a metric moved: decompose the change across time and the dimensions that drive it, then report the contributing drivers as a narrative. Needs an additive metric with a time dimension; the specific metric's additivity is checked at run time. Use it for causal \"why did this move\" questions, not for retrieving the number itself.",
       "effect": {
@@ -360,6 +359,7 @@
           }
         ]
       },
+      "entrypoint": true,
       "eval": {
         "metrics": [
           "driver_correctness",
@@ -400,7 +400,7 @@
           "consumes": [],
           "name": "plan_decomposition",
           "produces": "decomposition_plan",
-          "prompt": "You explain why a metric changed over the `v5-jaffle` wren project (a semantic layer at\n`../../../../examples/v5-jaffle`), by planning how to decompose the change.\n\n- Introspect the layer as needed (`wren context show`) to find the metric, its time dimension, and\n  the dimensions you can break the change down by.\n- Confirm the metric is **additive** across the dimensions you intend to decompose along (a sum of\n  parts equals the whole). Nothing upstream guarantees this — you must check that the **specific**\n  metric you decompose is additive. If it is a ratio/average/distinct-count or otherwise\n  non-additive, note that: decomposing it can mislead.\n- Produce `decomposition_plan`: the metric, the two periods being compared, and the ordered list of\n  dimensions to decompose the delta along (bounded by the drill-depth limit).",
+          "prompt": "You explain why a metric changed over the bound semantic context `v5-jaffle` (a semantic\nlayer at `../../../../examples/v5-jaffle`), by planning how to decompose the change.\n\n- Introspect the layer as needed, using the bound introspection capability, to find the metric, its\n  time dimension, and the dimensions you can break the change down by.\n- Confirm the metric is **additive** across the dimensions you intend to decompose along (a sum of\n  parts equals the whole). Nothing upstream guarantees this — you must check that the **specific**\n  metric you decompose is additive. If it is a ratio/average/distinct-count or otherwise\n  non-additive, note that: decomposing it can mislead.\n- Produce `decomposition_plan`: the metric, the two periods being compared, and the ordered list of\n  dimensions to decompose the delta along (bounded by the drill-depth limit).",
           "tier": "strong",
           "when": null
         },
@@ -411,7 +411,7 @@
           ],
           "name": "synthesize_drivers",
           "produces": "driver_explanation",
-          "prompt": "Given the `decomposition_plan`, quantify the change and synthesize the drivers into an explanation.\n\n- Run the decomposition queries through the `wren` CLI (`wren -q -o json -s '<SQL>'`): compute the\n  metric for each period and the per-dimension contribution to the delta. Rank contributors by the\n  size of their contribution.\n- Produce `driver_explanation` as a `narrative` render block: a short, ordered account of what drove\n  the change (largest contributors first), with the actual numbers. Follow the \"Render output\"\n  instructions the dispatcher appends below.\n- **Additivity caveat (required):** if the metric is not strictly additive across the decomposition\n  dimensions, state plainly in the narrative that the attribution is approximate and additivity was\n  not enforced. Never present a decomposition of a non-additive metric as exact — the hero output\n  must not claim to run on verified reasoning it did not.",
+          "prompt": "Given the `decomposition_plan`, quantify the change and synthesize the drivers into an explanation.\n\n- Run the decomposition queries through the bound query capability: compute the metric for each\n  period and the per-dimension contribution to the delta. Rank contributors by the size of their\n  contribution.\n- Produce `driver_explanation` as a `narrative` render block: a short, ordered account of what drove\n  the change (largest contributors first), with the actual numbers. Follow the \"Render output\"\n  instructions the dispatcher appends below.\n- **Additivity caveat (required):** if the metric is not strictly additive across the decomposition\n  dimensions, state plainly in the narrative that the attribution is approximate and additivity was\n  not enforced. Never present a decomposition of a non-additive metric as exact — the hero output\n  must not claim to run on verified reasoning it did not.",
           "tier": "strong",
           "when": null
         }
@@ -421,7 +421,7 @@
         "checks": [],
         "status": "pass"
       },
-      "prompt_fragment": "## plan_decomposition\n\nYou explain why a metric changed over the `v5-jaffle` wren project (a semantic layer at\n`../../../../examples/v5-jaffle`), by planning how to decompose the change.\n\n- Introspect the layer as needed (`wren context show`) to find the metric, its time dimension, and\n  the dimensions you can break the change down by.\n- Confirm the metric is **additive** across the dimensions you intend to decompose along (a sum of\n  parts equals the whole). Nothing upstream guarantees this — you must check that the **specific**\n  metric you decompose is additive. If it is a ratio/average/distinct-count or otherwise\n  non-additive, note that: decomposing it can mislead.\n- Produce `decomposition_plan`: the metric, the two periods being compared, and the ordered list of\n  dimensions to decompose the delta along (bounded by the drill-depth limit).\n\n## synthesize_drivers\n\nGiven the `decomposition_plan`, quantify the change and synthesize the drivers into an explanation.\n\n- Run the decomposition queries through the `wren` CLI (`wren -q -o json -s '<SQL>'`): compute the\n  metric for each period and the per-dimension contribution to the delta. Rank contributors by the\n  size of their contribution.\n- Produce `driver_explanation` as a `narrative` render block: a short, ordered account of what drove\n  the change (largest contributors first), with the actual numbers. Follow the \"Render output\"\n  instructions the dispatcher appends below.\n- **Additivity caveat (required):** if the metric is not strictly additive across the decomposition\n  dimensions, state plainly in the narrative that the attribution is approximate and additivity was\n  not enforced. Never present a decomposition of a non-additive metric as exact — the hero output\n  must not claim to run on verified reasoning it did not.",
+      "prompt_fragment": "## plan_decomposition\n\nYou explain why a metric changed over the bound semantic context `v5-jaffle` (a semantic\nlayer at `../../../../examples/v5-jaffle`), by planning how to decompose the change.\n\n- Introspect the layer as needed, using the bound introspection capability, to find the metric, its\n  time dimension, and the dimensions you can break the change down by.\n- Confirm the metric is **additive** across the dimensions you intend to decompose along (a sum of\n  parts equals the whole). Nothing upstream guarantees this — you must check that the **specific**\n  metric you decompose is additive. If it is a ratio/average/distinct-count or otherwise\n  non-additive, note that: decomposing it can mislead.\n- Produce `decomposition_plan`: the metric, the two periods being compared, and the ordered list of\n  dimensions to decompose the delta along (bounded by the drill-depth limit).\n\n## synthesize_drivers\n\nGiven the `decomposition_plan`, quantify the change and synthesize the drivers into an explanation.\n\n- Run the decomposition queries through the bound query capability: compute the metric for each\n  period and the per-dimension contribution to the delta. Rank contributors by the size of their\n  contribution.\n- Produce `driver_explanation` as a `narrative` render block: a short, ordered account of what drove\n  the change (largest contributors first), with the actual numbers. Follow the \"Render output\"\n  instructions the dispatcher appends below.\n- **Additivity caveat (required):** if the metric is not strictly additive across the decomposition\n  dimensions, state plainly in the narrative that the attribution is approximate and additivity was\n  not enforced. Never present a decomposition of a non-additive metric as exact — the hero output\n  must not claim to run on verified reasoning it did not.",
       "realization_kind": "skill",
       "required_capabilities": [
         "sql_execution:read_only",
@@ -456,10 +456,6 @@
         }
       ],
       "lineage": {
-        "consumers": {
-          "dashboards": 0,
-          "queries": 1
-        },
         "edges": 7,
         "nodes": 8,
         "resolvable": true
@@ -502,5 +498,5 @@
     }
   },
   "profile": "genbi-default",
-  "warble_ir_version": "0.6"
+  "warble_ir_version": "0.9"
 }

package/profiles/genbi-default/profile.yml

@@ -10,7 +10,38 @@ context:
   project: ./context/binding.yml
 
 components:
+  # Each mount's `brief` carries this binding's concrete data-access framing — the wren CLI
+  # invocations the underlying Hub component prompts used to name directly before they were
+  # neutralized. It replaces the component's own `brief` wholesale and is assembled into every
+  # step's system prompt for that component (see Warble's docs/spec/authoring.md, "brief").
   - use: explore_model
+    brief: |
+      Data access in this deployment goes through the `wren` CLI. Introspect the semantic layer
+      with `wren context show` (and, where available, `wren cube list`) to read models, columns,
+      relationships, and metrics/cubes — do not assume the schema.
   - use: answer_query
+    brief: |
+      Data access in this deployment goes through the `wren` CLI. If you need to introspect the
+      schema, run `wren context show`. Query the semantic layer with `wren -q -o json -s '<SQL>'`,
+      which returns JSON; object-shaped rows are also valid — preserve their values exactly. Never
+      hand-write SQL against raw tables outside the model.
+      For time-series questions, use the requested date range. If none is given, use the full
+      available data range and disclose that choice; never silently pick a recent N-week window.
+      Distinguish calendar-relative dates from a window anchored on the latest data date. Preserve
+      explicit calendar-relative requests even if the data is old; do not silently re-anchor them.
+      Explain exact date bounds, the date column, week start, timezone if known, and partial periods.
+      Use semantic metric definitions where available. Otherwise state the chosen interpretation:
+      distinct ordering customers, first-order customers and cumulative customers are different.
+      Do not present synonymous counts as different metrics. Do not invent registration dates or
+      metric meanings absent from context. Name the answer SQL in the terminal definition so that
+      later date-bound checks cannot replace the answering table.
   - use: generate_dashboard
+    brief: |
+      Data access in this deployment goes through the `wren` CLI. Discover the schema at query
+      time with `wren context show`, `wren cube list`, and `wren cube describe <cube>` — do not
+      assume it. Run each panel query with `wren -q -o json -s '<SQL>'`; every query goes through
+      `wren`, never hand-written SQL against raw tables outside the model.
   - use: explain_change
+    brief: |
+      Data access in this deployment goes through the `wren` CLI. Introspect the layer as needed
+      with `wren context show`. Run the decomposition queries with `wren -q -o json -s '<SQL>'`.

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

@@ -1,4 +1,15 @@
-# A pinned, existing semantic project. Runtime hosts replace this fixture binding with the project
-# selected at bind time and must present a successful context-build proof before starting a run.
-# Path is relative to this profile directory.
+# A pinned, existing semantic project, bound as a PREPARED document: `kind: prepared` means Warble
+# reads the JSON document `document:` names — produced by WrenAI's own `wren-context-loader`
+# generator — rather than introspecting the project's 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.
+#
+# Runtime hosts replace this fixture binding with the project selected at bind time (rewriting
+# `project:` and regenerating `document:`'s file in place) and must present a successful
+# context-build proof before starting a run. See MAINTAINING.md for how to regenerate the committed
+# document.
+kind: prepared
 project: ../../../../examples/v5-jaffle
+document: context/context.json