Skip to main content
The Assistant can answer governed data questions and create or repair sources, models, metrics, and dashboards. It is one capable agent rather than a set of isolated task bots, while the product—not the model—enforces permissions, data scope, validation, and commit boundaries.

​
What it can do

  • Answer: query the active environment’s governed marts/warehouse and render concise text, Markdown tables, or an inline visualization when the result benefits from one.
  • Source: prepare and run a database/API integration. Authentication values are entered only in the secure source form, never in chat.
  • Model: add or change dbt staging, warehouse, marts, tests, descriptions, or governed metrics.
  • Dashboard: create or repair an Evidence page using existing governed relations, or add the missing serving model when the requested grain genuinely does not exist.
  • Repair: start from a failed Monitoring run, inspect its real logs/contracts, and commit a validated Staging fix.
The same chat may move between these capabilities. Production remains read-only: the Assistant answers questions there, but change requests start in Staging.

​
Chats and follow-ups

Every conversation appears in the chat rail. Input and running state belong to the active chat, so switching chats or pressing New chat does not carry another run’s locked composer into the new conversation. A mutating chat is bound to its editable staged proposal. Follow up in that chat to refine the same proposal; the Assistant works from current Staging and updates its governed change. Start a new chat for independent work. Once a proposal is undone, released, or otherwise terminal, a follow-up creates new work rather than rewriting history.

​
Initial-build interview

The first model build profiles the selected source tables, then asks a small set of business questions before generating models. Question count is based on what the source/business context needs rather than a fixed customer-visible number. The interview is one step in the existing build chat:
  • questions and selectable defaults render as normal labels, not serialized JSON;
  • Use defaults for all fills every unanswered question;
  • submitting answers continues the same run exactly once;
  • the completed interview remains in the transcript as a compact, read-only carousel with Previous/Next so the team can review each question and answer later;
  • messages before the interview remain in the transcript.

​
Change lifecycle

  1. You ask for a change in Staging.
  2. The Assistant inspects current workspace files, governed model contracts, and bounded source or warehouse evidence.
  3. Candidate files are written only inside that run’s sandbox and allowed generated paths.
  4. dbt changes validate against a throwaway validation namespace; Evidence pages must pass dashboard structure/data guards and a preview build. A changed sandbox invalidates an older validation receipt.
  5. Only a current passing validation may commit to the Staging workspace/Git branch.
  6. The transcript ends with the product-owned card:
    Its white Promotions-icon button opens the matching card. The model does not repeat those lines in its answer.
  7. Promotions—not the Assistant transcript—shows files, code diff, validation, ancestry, GitHub, release state, and dependency-aware Undo.
The removed work panel, action-item checklist, file list, diff, commit SHA, and Undo control do not appear in the Assistant view.

​
Live activity and recovery

The Assistant streams concise actions while it works. Refreshing or revisiting the chat replays the durable event history; it should not be required to reveal hidden progress. Technical tools use action-appropriate language—inspection actions do not pretend every read/list operation “succeeded,” while validations and builds clearly state their real outcome. If validation cannot pass safely, no persistent Staging files are committed. The run explains the specific blocker and remains available for a focused continuation or a new repair request.

​
Usage

Platform-supported AI includes a monthly fair-use allowance. Platinur reserves capacity before each model request, so concurrent runs cannot collectively pass the workspace limit. At the limit, a new model request is not sent and the Assistant shows when the allowance resets; existing chats, proposals, and completed work remain intact. A workspace can instead add its own OpenAI key under Configuration → Assistant; that key takes precedence and is not charged to the platform allowance. During fleet-wide provider bursts, a request may queue briefly before it is sent rather than failing partway through the work.