dataspring-cli 0.3.0__py3-none-any.whl → 0.4.0__py3-none-any.whl

cli/_skills/dataspring-author/SKILL.md

@@ -196,9 +196,19 @@ already have, not a sync loop to maintain afterwards.
 
 That's the contract. Boring, dense, useful.
 
+## 8.1 Briefings are boards with a cadence
+
+Do not build a second set of rows for a recurring mail. A briefing
+references a board by id, so the board and the mail built from it match
+by construction, and `briefing_edit` `render` records which board
+version produced each issue. Edit the board and the next issue follows.
+`render` answers markdown, never HTML; `commit: true` files the issue
+and is what stops later history columns moving. Rendering and checking
+prose is the consumer's job and is covered in `dataspring-consume`.
+
 ## 9. Parameter reference
 
-<!-- dispatch-params: semantic_model_edit metric_edit import_manifest business_context_edit warehouse_edit datacore_edit datacore_run -->
+<!-- dispatch-params: semantic_model_edit metric_edit board_edit briefing_edit import_manifest business_context_edit warehouse_edit datacore_edit datacore_run -->
 _Generated from the dispatch registry (`GET /api/dispatch`); do not edit by hand. Field descriptions are the models' own, verbatim on every surface._
 
 #### `semantic_model_edit`
@@ -275,6 +285,75 @@ MCP tool `metric_edit`; `POST /api/dispatch/metric_edit`. Edit metrics in the or
 | `name` | string | yes |  |
 | `updates` | object | yes | The updates whose impact to assess |
 
+#### `board_edit`
+
+MCP tool `board_edit`; `POST /api/dispatch/board_edit`. Create, change, delete or convert a board. The body is `{"action": {"action": "<verb>", ...}}`, one verb per table below.
+
+**`apply`** — Write a whole board: create it, or replace an existing one entirely.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `document` | object | yes | The whole board document (schemas/board.schema.json): `title`, `sections` of `rows`, and optionally `controls` and `display`. A row is {id, metric, label} plus optional filters, format, good ('up'\|'down'), chart and threshold. `metric` is a manifest metric name or 'qm:<name>' for a quick metric. Layout - pages, column spans, chart types - belongs under `display` and is never structure. |
+| `id` | string | no | Board id to write to. Omit to create one (the document's own `id` is used when it has one). |
+| `expect_version` | integer | no | The board version this edit was written against, from the previous edit's `version` or from read(kind="board"). The write is refused with the current version when it is stale, so two agents editing one board cannot silently overwrite each other. Omit to write without a check. |
+
+**`patch`** — Apply a JSON merge patch (RFC 7386: a key set to null is removed) to a stored board, for a small edit that does not need the whole document.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | yes | Board id |
+| `patch` | object | yes | JSON merge patch over the stored board document |
+| `expect_version` | integer | no | The board version this edit was written against, from the previous edit's `version` or from read(kind="board"). The write is refused with the current version when it is stale, so two agents editing one board cannot silently overwrite each other. Omit to write without a check. |
+
+**`delete`** — Delete a board. Cannot be undone.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | yes | Board id |
+
+**`convert_dashboard`** — Convert one of the organization's dashboards into a board, mechanically: each widget becomes a row, pages and sections become sections, and the grid becomes display hints. The dashboard is left exactly as it was.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `dashboard_id` | string | yes | The dashboard to convert |
+| `id` | string | no | Board id to write to. Defaults to the dashboard's own id. |
+| `save` | boolean | no, default `True` | False returns the converted board without storing it, to look before committing. |
+
+#### `briefing_edit`
+
+MCP tool `briefing_edit`; `POST /api/dispatch/briefing_edit`. Create, change, delete or RENDER a briefing. The body is `{"action": {"action": "<verb>", ...}}`, one verb per table below.
+
+**`apply`** — Write a whole briefing: create it, or replace an existing one entirely.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `document` | object | yes | The whole briefing document (schemas/briefing.schema.json): id, name, `board` (a saved board's id, or an inline board document), and the optional cadence, period, narrative, freshness and recipients blocks. `board` is a REFERENCE: edit the board and the next issue follows, and each issue records the board version it was rendered from. |
+| `id` | string | no | Briefing id to write to. Omit to use the document's own `id`. |
+| `expect_version` | integer | no | The version this edit was written against, from the previous edit's `version` or dataspring://briefings/<id>. A concurrent change is refused with the current version instead of overwriting it. |
+
+**`patch`** — Apply a JSON merge patch (RFC 7386: a key set to null is removed) to a stored briefing, for a small edit that does not need the whole document.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | yes | Briefing id |
+| `patch` | object | yes | JSON merge patch over the stored briefing document |
+| `expect_version` | integer | no | The version this edit was written against, from the previous edit's `version` or dataspring://briefings/<id>. A concurrent change is refused with the current version instead of overwriting it. |
+
+**`delete`** — Delete a briefing definition. Its committed issues are kept: they are the record of what was sent, and deleting the definition unsends nothing.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | yes | Briefing id |
+
+**`render`** — Render one issue: a headline, a reason, a view URL, markdown blocks and the structured snapshot. Never HTML.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | no | A saved briefing's id. Give this or `inline`, not both. |
+| `inline` | object | no | A whole briefing document to render without saving it, for iterating on a draft. An inline briefing cannot commit: an issue is filed under a stored briefing. |
+| `period` | string | no | Override the period this issue covers (last_closed_week, last_closed_month, mtd, last_<n>_<grain>, ...). Omit to use the briefing's own, which its cadence implies when it names none. Resolved in the organization's timezone and echoed back with the exact dates. |
+| `commit` | boolean | no, default `False` | True writes the snapshot as an issue, ONCE, under this period's key. Do it when you send: the committed issue is what the next issue's history columns read, so those columns never shift afterwards. A period that already has an issue is left exactly as it is and the answer says so. |
+
 #### `import_manifest`
 
 MCP tool `import_manifest`; `POST /api/dispatch/import_manifest`. Import a semantic manifest using replace semantics.

cli/_skills/dataspring-consume/SKILL.md

@@ -30,6 +30,8 @@ traces — departing from them produces misleading numbers.
 | Read business_context | `dataspring://context` resource | `dataspring business-context get` | `GET /api/context` |
 | Check business_context size | `business_context_edit show_size` | `dataspring business-context size` | (no dedicated route — use `GET /api/context` and measure) |
 | Org's published skill | (this skill, served via SKILL.md) | `dataspring skill instructions consume` | `GET /api/v1/skill/consume/instructions` |
+| Be woken when a number moves | `watch_edit apply` | `dataspring watch_edit apply --document-json @watch.yaml` | `POST /api/dispatch/watch_edit` |
+| List watches | `read(kind="watches")` | (no CLI command yet) | `GET /api/watches` |
 
 No catalog is pre-loaded. You are handed NO catalog up front — the catalog
 index (`list_metrics` / `dataspring metrics list` / `GET
@@ -106,7 +108,17 @@ For any analytical question, in this order:
    touches, in ONE call. This is where the authoritative description
    lives: unit, source rollup, standing filter rules, caveats (§3). Read
    it before you query; do not paraphrase from the name or the summary.
-3. **Query** — only now, with the names and grains you just confirmed.
+3. **Check what THAT metric can be sliced by, before you write a
+   `dimensions` / `group_by`** — `read(kind="metric_dimensions", id="<metric>")`
+   on MCP, the `dataspring://metrics/{name}/dimensions` resource, or
+   `GET /api/metrics/{name}/dimensions`. The index in step 1 lists the
+   dimensions the ORG has; a metric can only be sliced by the ones its own
+   semantic models join to, and the two sets are not the same. Each entry
+   carries the exact name to send, the join path that reaches it, the grains a
+   time dimension offers, and a sample of a categorical one's values. Skipping
+   this is how a query comes back refused for a dimension that exists in the
+   org and not on this metric.
+4. **Query** — only now, with the names and grains you just confirmed.
 
 Don't skip step 1: "obvious" metrics like `total_revenue` differ across
 orgs in unit, source, and standing filter rules, and a name matching the
@@ -449,8 +461,8 @@ entity fact goes in that object's `description` in the dbt YAML;
 a cross-cutting organisation fact goes in `business_context`. This table
 answers *whether it's worth capturing*; that rule answers *which document*.
 
-Propose the change via `metric_edit` / `semantic_model_edit` (MCP), `dataspring metrics create` /
-`dataspring models create` (CLI), or the equivalent admin REST routes —
+Propose the change via `metric_edit` / `semantic_model_edit` (MCP), `dataspring metric_edit create` /
+`dataspring semantic_model_edit create` (CLI), or the equivalent admin REST routes —
 admin/owner only. Show it first (§8): a `preview` compiles the definition
 and writes nothing, so it needs no consent. What needs the user's yes is
 `create`; never make that change unilaterally.
@@ -539,6 +551,49 @@ breakdown.
 The catalog is only stale if the user pivots to a brand-new
 analytical area; in that case, re-list.
 
+## 12.1 Do not poll. Ask to be woken.
+
+If the task is "tell me when X changes", do not run the same query on a loop.
+Set a **watch** (`watch_edit apply`) and let DataSpring call you: it is the
+only component that knows when data lands, so it evaluates the condition after
+the run that could change it and posts to your webhook.
+
+A watch is one board row, one condition, one callback. The condition is not an
+expression — it is one of three shapes, all of them the same rules a
+`board_fetch` answer already reports:
+
+```yaml
+id: revenue_odd
+title: Weekly revenue moved oddly
+board_id: weekly          # or an inline `board:` document for a row that exists only to be watched
+row: rev
+period: last_closed_week
+compare_to: previous_period
+condition: {kind: notable}                                 # any notability rule
+# condition: {kind: notable, rules: [volatility, sign_change]}   # only these
+# condition: {kind: threshold, value: 0.3, direction: below}     # stay below 0.3
+# condition: {kind: direction, direction: down, min_change_pct: 0.1}
+delivery: {kind: webhook, url: "https://hooks.example.com/..."}
+```
+
+Three things to know before you write one:
+
+- **It fires on the edge, not every run.** Once it has fired it stays quiet
+  until an evaluation finds the condition no longer met. Do not expect one
+  message per run, and do not write a second watch to "confirm" the first.
+- **The callback is signed and you have to verify it.** The answer to a
+  create carries a one-time link; open it once and put the secret in your
+  receiver. Every request then carries `X-DataSpring-Timestamp` and
+  `X-DataSpring-Signature: v1=<hex>`, where the hex is HMAC-SHA256 over
+  `v1:<timestamp>:<the raw body>`. Compare it in constant time and refuse a
+  timestamp more than a few minutes old.
+- **The URL must be public HTTPS.** Loopback, private, link-local and cloud
+  metadata addresses are refused when the watch is written and again against
+  what the name resolves to at delivery time, and no redirect is followed.
+
+The payload tells you what the row did and gives you a link. What to say
+about it, and to whom, is yours.
+
 ## 13. The org's `business_context` document
 
 Cross-cutting org orientation lives in `business_context` — what
@@ -558,9 +613,31 @@ manifest workflow), same trust level.
 That's the working agreement. Same principles, three surfaces —
 do this and the answers will be right.
 
-## 14. Parameter reference
-
-<!-- dispatch-params: query_metrics explain_query run_sql update_context quick_metric_edit learned_edit verified_query_edit business_context_edit -->
+## 14. Briefings: render, write, verify, send
+
+A **briefing** is a board plus a cadence. You render it; you deliver it.
+
+1. `briefing_edit` `render` answers markdown that leads with the answer — a
+   `headline` saying whether the period is normal, a `reason` naming what
+   moved and the rule it broke, and a `view_url` the reader can open — then
+   `blocks[]` you can send whole or recombine, then the structured `snapshot`.
+   It never returns HTML; convert at the point of sending if you need it.
+2. Write the prose yourself unless the briefing asks DataSpring to write it.
+   Quote numbers from the snapshot, not from your own arithmetic.
+3. **Check it with `verify_numbers` before you send.** Pass the text and the
+   `snapshot_id` the render returned. It answers with every number the
+   snapshot does not support, in Danish and English formats, and lists dates,
+   years and counts of periods under `ignored` rather than flagging them. A
+   high-confidence mismatch means the sentence is wrong, not that the tool is
+   fussy: fix the sentence.
+4. Render again with `commit: true` when you actually send. That files the
+   issue, and the next issue's history columns read it instead of re-querying,
+   so a column a reader has already seen cannot move afterwards. Commit when
+   you send and not before.
+
+## 15. Parameter reference
+
+<!-- dispatch-params: query_metrics board_fetch explain_query run_sql briefing_edit verify_numbers update_context quick_metric_edit learned_edit verified_query_edit business_context_edit -->
 _Generated from the dispatch registry (`GET /api/dispatch`); do not edit by hand. Field descriptions are the models' own, verbatim on every surface._
 
 #### `query_metrics`
@@ -574,13 +651,35 @@ MCP tool `query_metrics`; `POST /api/dispatch/query_metrics`. Fetch metric data
 | `grain` | string | no | Time granularity: 'day', 'week', 'month', 'quarter', or 'year' |
 | `start_date` | string | no | Start date in YYYY-MM-DD format |
 | `end_date` | string | no | End date in YYYY-MM-DD format |
+| `period` | string | no | A named period, resolved server-side in the organization's timezone and echoed back on the answer as `period` with the exact start and end dates it meant: last_closed_day, last_closed_week, last_closed_month, last_closed_quarter, last_closed_year (the most recent whole one that has ended); wtd, mtd, qtd, ytd (the current one so far, still open); or last_<n>_<grain> such as last_13_week (the n most recently closed periods as one window). Use this instead of start_date/end_date whenever the question is relative, so the dates are DataSpring's and not a guess about which timezone today is in. Ignored when start_date and end_date are both given. |
 | `limit` | integer | no | Maximum number of rows to return |
 | `order_by` | string | no | Column to sort by, append ' desc' for descending (e.g., 'total_revenue desc') |
 | `where` | list of string | no | Row filters in MetricFlow's constraint syntax, one string each, e.g. "{{ Dimension('customer__segment') }} NOT IN ('Direct')". Use qualified names from dataspring://dimensions - an unresolvable name comes back as an error whose suggestion names the qualified form. `where` decides WHICH ROWS the numbers cover; `dimensions` breaks the numbers OUT by a column; send both for a breakdown of a filtered slice. A `where` on a dimension also overrides the user's standing filter on that same dimension for this call. |
 | `warehouse` | string | no | Which of the org's warehouses to run against - an id from dataspring://warehouses ('managed', 'external', ...). Omit for the active one. During a migration ask both and compare. |
+| `compare_to` | one of `previous_period`, `same_period_last_year` | no | Compare the window against the one before it (previous_period, stepped back by whole calendar periods when the window is whole ones) or the same window a year earlier (same_period_last_year). The deltas come back BESIDE the values - each metric column gains <metric>__previous, <metric>__delta and <metric>__delta_pct - so there is no second result set to line up and no arithmetic to do. `comparison_period` says which window they were measured against. |
 | `suggest_visualization` | boolean | no, default `False` | Also return a suggested visualization type for the result. |
 | `format` | one of `json`, `csv` | no, default `json` | 'json' (default) answers rows in `data`; 'csv' answers the same result as one CSV document in `content` (header row first) for a file or a spreadsheet, with `columns` and `row_count` alongside. |
 
+#### `board_fetch`
+
+MCP tool `board_fetch`; `POST /api/dispatch/board_fetch`. Run every row of a board in one call and answer salience first.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `board_id` | string | no | A saved board's id. Give this or `inline`, not both. |
+| `inline` | object | no | A whole board document to run without saving it (schemas/board.schema.json). This is how to ask several unrelated questions in one call: put each one in its own row. |
+| `period` | string | no | A named period, resolved server-side in the organization's timezone and echoed back on the answer as `period` with the exact start and end dates it meant: last_closed_day, last_closed_week, last_closed_month, last_closed_quarter, last_closed_year (the most recent whole one that has ended); wtd, mtd, qtd, ytd (the current one so far, still open); or last_<n>_<grain> such as last_13_week (the n most recently closed periods as one window). Use this instead of start_date/end_date whenever the question is relative, so the dates are DataSpring's and not a guess about which timezone today is in. Ignored when start_date and end_date are both given. |
+| `grain` | one of `day`, `week`, `month`, `quarter`, `year` | no | Bucket grain for each row's history. Defaults to the period's own grain. |
+| `start_date` | string | no | Start date in YYYY-MM-DD format, instead of a named period |
+| `end_date` | string | no | End date in YYYY-MM-DD format, instead of a named period |
+| `compare_to` | one of `previous_period`, `same_period_last_year` | no | Compare the window against the one before it (previous_period, stepped back by whole calendar periods when the window is whole ones) or the same window a year earlier (same_period_last_year). The deltas come back BESIDE the values - each metric column gains <metric>__previous, <metric>__delta and <metric>__delta_pct - so there is no second result set to line up and no arithmetic to do. `comparison_period` says which window they were measured against. |
+| `detail` | one of `salient`, `full` | no, default `salient` | 'salient' (default) answers EVERY row compactly - value, delta, and whether it is notable - and adds the full detail (history, sparkline, receipt, freshness, which rule fired) only for the rows that are notable plus any named in `rows`. 'full' answers everything for every row, for an export or a spreadsheet. |
+| `rows` | list of string | no | Row ids to return in full detail whether or not they are notable. |
+| `history` | integer | no, default `13` | How many periods of history to fetch per row, for the sparkline and the volatility measure. |
+| `format` | one of `json`, `markdown`, `csv` | no, default `json` | 'json' (default) answers the structured result; 'markdown' adds one markdown document in `content`, leading with what moved and then a table per section, ready to paste into a chat, a document or a terminal; 'csv' adds one row per board row in `content`. |
+| `locale` | one of `en`, `da` | no, default `en` | Number formatting for the `formatted` fields: 'en' (1,234.5) or 'da' (1.234,5). |
+| `warehouse` | string | no | Which of the org's warehouses to run against. Omit for the active one. |
+
 #### `explain_query`
 
 MCP tool `explain_query`; `POST /api/dispatch/explain_query`. Show what a query computes without running it: the resolved metrics and dimensions, the effective time window, the filters (including any standing preference folded in) and the compiled SQL. Use it when the user asks what you actually computed, disputes a number, or before proposing a correction. ``warehouse`` picks one of the org's warehouses; omit it for the active one.
@@ -592,6 +691,7 @@ MCP tool `explain_query`; `POST /api/dispatch/explain_query`. Show what a query
 | `grain` | string | no | Time granularity: 'day', 'week', 'month', 'quarter', or 'year' |
 | `start_date` | string | no | Start date in YYYY-MM-DD format |
 | `end_date` | string | no | End date in YYYY-MM-DD format |
+| `period` | string | no | A named period, resolved server-side in the organization's timezone and echoed back on the answer as `period` with the exact start and end dates it meant: last_closed_day, last_closed_week, last_closed_month, last_closed_quarter, last_closed_year (the most recent whole one that has ended); wtd, mtd, qtd, ytd (the current one so far, still open); or last_<n>_<grain> such as last_13_week (the n most recently closed periods as one window). Use this instead of start_date/end_date whenever the question is relative, so the dates are DataSpring's and not a guess about which timezone today is in. Ignored when start_date and end_date are both given. |
 | `limit` | integer | no | Maximum number of rows to return |
 | `order_by` | string | no | Column to sort by, append ' desc' for descending (e.g., 'total_revenue desc') |
 | `where` | list of string | no | Row filters in MetricFlow's constraint syntax, one string each, e.g. "{{ Dimension('customer__segment') }} NOT IN ('Direct')". Use qualified names from dataspring://dimensions - an unresolvable name comes back as an error whose suggestion names the qualified form. `where` decides WHICH ROWS the numbers cover; `dimensions` breaks the numbers OUT by a column; send both for a breakdown of a filtered slice. A `where` on a dimension also overrides the user's standing filter on that same dimension for this call. |
@@ -609,6 +709,51 @@ MCP tool `run_sql`; `POST /api/dispatch/run_sql`. Run ONE read-only SQL statemen
 | `format` | one of `json`, `csv`, `markdown` | no, default `json` | 'json' answers rows in `data`; 'csv' or 'markdown' answer one document in `content`. |
 | `dry_run` | boolean | no, default `False` | Only estimate the bytes the statement would process (and check it parses); run nothing. |
 
+#### `briefing_edit`
+
+MCP tool `briefing_edit`; `POST /api/dispatch/briefing_edit`. Create, change, delete or RENDER a briefing. The body is `{"action": {"action": "<verb>", ...}}`, one verb per table below.
+
+**`apply`** — Write a whole briefing: create it, or replace an existing one entirely.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `document` | object | yes | The whole briefing document (schemas/briefing.schema.json): id, name, `board` (a saved board's id, or an inline board document), and the optional cadence, period, narrative, freshness and recipients blocks. `board` is a REFERENCE: edit the board and the next issue follows, and each issue records the board version it was rendered from. |
+| `id` | string | no | Briefing id to write to. Omit to use the document's own `id`. |
+| `expect_version` | integer | no | The version this edit was written against, from the previous edit's `version` or dataspring://briefings/<id>. A concurrent change is refused with the current version instead of overwriting it. |
+
+**`patch`** — Apply a JSON merge patch (RFC 7386: a key set to null is removed) to a stored briefing, for a small edit that does not need the whole document.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | yes | Briefing id |
+| `patch` | object | yes | JSON merge patch over the stored briefing document |
+| `expect_version` | integer | no | The version this edit was written against, from the previous edit's `version` or dataspring://briefings/<id>. A concurrent change is refused with the current version instead of overwriting it. |
+
+**`delete`** — Delete a briefing definition. Its committed issues are kept: they are the record of what was sent, and deleting the definition unsends nothing.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | yes | Briefing id |
+
+**`render`** — Render one issue: a headline, a reason, a view URL, markdown blocks and the structured snapshot. Never HTML.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `id` | string | no | A saved briefing's id. Give this or `inline`, not both. |
+| `inline` | object | no | A whole briefing document to render without saving it, for iterating on a draft. An inline briefing cannot commit: an issue is filed under a stored briefing. |
+| `period` | string | no | Override the period this issue covers (last_closed_week, last_closed_month, mtd, last_<n>_<grain>, ...). Omit to use the briefing's own, which its cadence implies when it names none. Resolved in the organization's timezone and echoed back with the exact dates. |
+| `commit` | boolean | no, default `False` | True writes the snapshot as an issue, ONCE, under this period's key. Do it when you send: the committed issue is what the next issue's history columns read, so those columns never shift afterwards. A period that already has an issue is left exactly as it is and the answer says so. |
+
+#### `verify_numbers`
+
+MCP tool `verify_numbers`; `POST /api/dispatch/verify_numbers`. Check every number in a piece of prose against a briefing snapshot.
+
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `text` | string | yes | The prose to check. Markdown is fine; code spans and URLs are skipped. |
+| `snapshot_id` | string | no | A committed issue's snapshot id, as render returns it ('<briefing_id>:<period_key>'). Give this or `snapshot`, not both. |
+| `snapshot` | object | no | The `snapshot` block a render returned, for prose written against an issue that has not been committed. Give this or `snapshot_id`. |
+
 #### `update_context`
 
 MCP tool `update_context`; `POST /api/dispatch/update_context`. Update user preferences (merge, not replace).

cli/_skills/dataspring-correct/SKILL.md

@@ -36,7 +36,7 @@ no data. Explaining a null is not an answer.
 | Region, dbt layout, project-level operational pointers | `business_context` |
 | Findings, analysis results, history | NOT in the context layer at all |
 | Per-metric definition logic | NOT in context — lives in the dbt model SQL |
-| The user's own standing intent ("always exclude Direct for me") | A personal preference, via `update_user_preferences` |
+| The user's own standing intent ("always exclude Direct for me") | A personal preference, via `update_context` |
 | A question and the query that correctly answers it, confirmed by the user | `verified_query_edit` record, scope `user` |
 
 A verified query is scope `org` only on an admin's say-so. When torn between