> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platinur.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The Assistant

> Ask governed questions and make validated Staging changes with one capable assistant.

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:

   ```text theme={null}
   Request completed
   See Promotions for details
   ```

   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.