ReportPlane Assistant

ReportPlane Assistant is available throughout the authenticated Console. Open it from the launcher in the lower-right corner. The conversation remains available while you move between pages and after a browser refresh.

The Assistant runs as an independent reasoning and conversation service. The Console browser still connects only to ReportPlane Core; Core supplies verified facts and remains the sole authorization and execution plane. An Assistant outage affects the drawer, not normal Console or Management API operations.

Languages#

The Assistant automatically follows the language you use in the conversation. If you explicitly ask it to continue in another language, that preference takes precedence until you change it again. The Console locale is sent only as a weak hint and does not override the conversation language. Canonical English operation names, reason codes, and tool results also do not change the response language after an operation runs.

Confirmation buttons and other fixed interface labels follow the Console UI locale. Operation IDs, tool names, JSON fields, and other machine contracts remain canonical and are never translated.

How the Assistant understands a request#

Each new message first goes through a provider-neutral understanding stage. It records a compact semantic state—your current goal, facts already supplied, genuine uncertainties, relevant concepts, and any explicit response-language preference. Corrections such as “actually, that is 100 thousand per day” replace the corresponding conversation fact. This state is reasoning memory only: it cannot authorize an action, establish ownership, or invent an existing resource.

If an ambiguity has a known finite answer, the drawer can offer a typed choice immediately. For example, “100 thousand events” can produce a daily/weekly/monthly/yearly period selector, and a generic “reporting service” request can offer Analytics API, Query Client, or Data Model as possible goals. You can ignore the control and answer naturally in chat. Submitting a deterministic field or resource control is server-validated, updates conversation state directly, and makes no additional model call. A genuinely semantic goal clarification may use one bounded reasoning call after the selection; it still does not bypass Core validation or confirmation.

After the goal is understood, the reasoning stage receives only recent necessary text, the semantic state, relevant verified Core facts, relevant operations, and a bounded set of focused product-knowledge sections. Mutation operations are hidden until the goal and required resource context are resolved. The provider cannot successfully propose an operation that was not exposed for that turn.

ReportPlane product guidance is maintained as small Markdown knowledge units for Analytics, Data Models, warehouses, ingest, Query Clients, plans, security, and troubleshooting. Only the sections matching the current intent and concepts are retrieved. Current plan, usage, project, resource IDs, permissions, and credentials never come from these documents; Core supplies or enforces those facts.

The Assistant also acts as a grounded ReportPlane product guide. It distinguishes explanation, feature and capability questions, how-to guidance, product value questions, use-case advice, troubleshooting, live-resource questions, and mutation requests. Mentioning a concept does not request an operation: “What is a Query Client?” explains the concept, while “Create a Query Client” can begin a reviewed create flow. Simple product questions do not expose mutation operations or open forms.

Knowledge retrieval is granular and evidence-linked. General product knowledge can explain concepts such as managed warehouses, Discover, mTLS, workspace-shared credentials, Query Clients, and Analytics APIs. Claims about the signed-in workspace—such as whether a resource exists, what it can access, or whether the current plan permits an action—require verified Core context or a read operation.

What it can do#

The initial release can recommend and create a managed warehouse, list and create data models, add fields, create ingest and query clients, create or update Analytics APIs, and run analytics. It is a general management surface rather than a separate onboarding wizard.

The Assistant starts from your goal rather than forcing every request through warehouse onboarding. You can begin with new infrastructure, an existing warehouse, a Data Model, JSON, an Analytics requirement, a Query Client, troubleshooting, or a specific resource. It combines conversation history with verified page context and asks only when a genuinely missing or ambiguous business decision blocks progress. Tool schemas describe capabilities; they are not forms.

When warehouse selection is actually relevant, the Assistant reasons about event volume and its time basis, retention, expected Analytics/query response time, and operational preference in whichever order fits the conversation. Generic onboarding intent alone is not enough to select BigQuery or ClickHouse: Core accepts a recommendation operation only after those workload facts are complete. It does not request facts you already supplied. Recommendation results are explained as trade-offs, and creation details are requested only after you choose a direction. Safe presentation values such as an Analytics name and key may be proposed for review; canonical resource IDs, credentials, and existing resource identity are never invented.

Questions about supported warehouses are grounded in Core's current capability catalog rather than the model's general knowledge. The catalog currently exposes BigQuery, ClickHouse, Snowflake, Elasticsearch, and OpenSearch together with their supported deployment models; an unlisted backend is not presented as a supported integration.

When creating a managed BigQuery warehouse, specify the dataset location that fits your residency and workload requirements. Multi-regions such as US and EU, and regional locations such as us-central1 or europe-west4, are passed to BigQuery during dataset creation. A dataset location cannot be changed after creation.

The Assistant uses the current project and a typed page context. For example, when you open a Data Model or Analytics API, the browser sends its resource ID to Core. Core revalidates ownership and builds a secret-free context from canonical storage, including safe model field names and types where relevant. The Assistant does not trust browser-supplied resource metadata or scrape page text or the DOM.

Resource-aware workflows#

Core projects a bounded, secret-free resource graph for warehouses, Data Models, Analytics APIs, Ingest Clients, and Query Clients. The Assistant uses operation metadata to resolve dependencies instead of maintaining a second set of product workflows. For example, a Data Model selects one or more available warehouses, an Analytics API selects a Data Model that is actually bound to the selected warehouse, an Ingest Client selects its allowed Data Models, and a Query Client selects its allowed Analytics APIs.

Selections follow the same deterministic rule everywhere: an unavailable required resource starts the earliest supported prerequisite step, one verified resource may be selected automatically and shown during review, and multiple resources produce a typed picker. The original goal is retained while that prerequisite is completed, so the next deterministic step can resume without asking you to restate the goal. Current-page resources are accepted only after Core verifies that they belong to the active project. Conversation references such as “the Analytics we just created” are lookup hints; Core remains authoritative and revalidates the resource before use.

Console navigation is also structured. Requests such as “open the Warehouses page” or “take me to the Analytics we just created” produce a localized action whose route is resolved by the Console's canonical route registry. The language model does not generate paths or resource IDs. If the Assistant cannot perform a supported Console-only mutation—for example, connecting an existing customer-operated warehouse—it can explain that boundary and provide the relevant Console action.

Follow-up changes resolve the existing target before selecting an operation. A request such as “make this a line chart” updates the verified recent Analytics API; it does not reopen the create flow or ask for its name, key, or Data Model. Core operation metadata distinguishes create, update, archive, execute, and inspect capabilities. Unsupported mutations do not fall back to creating a new resource. When a new dependent resource is requested—such as a Query Client for the Analytics API just created—the existing Analytics API is used as the verified dependency instead of being updated.

When the Assistant creates an Analytics API, Core also creates its executable destination bindings from the Data Model's enabled warehouse connections. The action is not reported as successful if no enabled warehouse binding can be created, so the resulting Analytics API is immediately usable by Explorer and the query runtime.

Safe list and get operations read the current project state from Core, so resource discovery also works in a new conversation. Existing resource IDs, relationships, credentials, and ownership are never inferred from model memory.

For an Analytics create request, the Assistant recommends a supported visualization from the intended result shape while keeping chart_type separate from the Analytics query definition. Ranking and Top-N results can default to a horizontal bar, bucketed time series to a line, category comparisons to a bar, small composition results to a doughnut, single aggregates to a number, and detailed rows to a table. The review form shows the recommendation as a localized dropdown, so you can change it without sending another model request. An explicit supported chart preference always takes precedence.

Review and confirmation#

When the next step is a known value rather than an open-ended decision, the drawer shows a typed control instead of starting another AI turn. Supported controls include single- and multi-selects, text and number inputs, yes/no choices, resource and field pickers, date ranges, and confirmations. A managed BigQuery setup, for example, can collect the warehouse name and dataset region in one review form.

Submitting a deterministic field or resource control is not sent back to the language model as chat text. The Assistant validates the submitted shape and allowed options, persists the interaction against the conversation, and produces at most one canonical operation proposal after all required values are present. A semantic intent-selection control may invoke one bounded reasoning step because the selected goal still needs product reasoning; this exception is explicit and does not apply to ordinary form completion. Region options come from Core's warehouse capability catalog; resource and field choices come from Core-verified page context. Values outside a closed option set are rejected. BigQuery's editable location field still passes through Core's canonical location validator, which allows supported locations beyond the convenience list without trusting the model.

Workflows are interruptible. While a field selector or confirmation is pending, you can ask a product question such as “What does managed mean?” or “What happens if I confirm this?”. The Assistant answers the question in the conversation language without treating it as a field value or consent, and re-presents the same interaction at the conversation tail. Only that latest presentation is actionable; older snapshots are read-only, including after refresh. An actual natural-language field answer can complete the existing deterministic interaction; it does not create a duplicate workflow record or trigger a second proposal-generation call. A question about a confirmation never confirms it—only the explicit confirmation control can do that.

Read-only operations can run immediately. Mutations that create, update, or archive resources produce a structured confirmation card. Review the target and impact, then choose Confirm or Cancel.

Confirming or canceling does not call the language model again. Pending conversational state and expiry live in the Assistant service. After a pending action is claimed, Core independently rechecks your authorization, plan and resource limits, the exact target, operation version, arguments, impact, and resource version before execution. Core also keeps a mutation idempotency receipt, so a repeated or semantically duplicated confirmation cannot execute the same mutation twice.

A confirmation card is a complete review step. Core does not render a model-generated follow-up question alongside a prepared confirmation card. Managed warehouse target name and region are shown through localized deterministic impact text.

Existing-resource updates show only the requested difference. For example, a visualization change shows the current and proposed chart types, while a limit change shows the old and new limits. Omitted Analytics fields keep their current values; the model is not asked to regenerate the complete definition for a presentation-only or other partial update.

Security model#

You do not create or paste a Management Token for the built-in Assistant. The browser talks only to ReportPlane Core using the existing Console session. Core talks to the Assistant service with a separate first-party service token; it never forwards the Console JWT or a Management Token. The Assistant and AI provider propose operations but cannot authorize or execute them and cannot directly access Core business repositories.

Conversation, message, run, deterministic-interaction, provider-usage, and pending-action records are stored only in the Assistant database. Core stores business resources and narrow execution-safety receipts, not conversation history. Losing Assistant persistence loses conversational continuity but does not lose or roll back ReportPlane business state.

The active conversation is selected and persisted by the Assistant service rather than browser-only storage. Reopening the drawer after a refresh restores messages, pending controls, confirmations, and safe completion summaries. You can also reopen older conversations without treating their remembered resource references as current business state.

After a successful resource mutation, Core returns only a normalized resource identity and status. The Console maps that canonical resource type and ID to a real detail route, navigates the background page, and refreshes its data while leaving the drawer available. Raw execution payloads, credential configuration, and internal action-result blocks are not rendered in conversation history.

Secrets—including API keys, Management Tokens, private keys, credential configuration, and service-account material—are excluded from runtime transcripts and action results.

Evidence and capability boundaries#

The Assistant keeps product knowledge, conversation memory, verified Core context, Core read results, Core operation results, and model inference separate. Product knowledge can explain how Query Clients work in general, but it cannot prove which Query Client exists in the current project or which Analytics APIs it can access. Current resource counts, identities, bindings, plan state, and mutation outcomes require current Core evidence.

Success language is tied to a matching successful Core operation result. A prepared, running, rejected, or failed action is not described as created or updated. Exact root-cause language likewise requires supporting Core evidence; otherwise the Assistant states that the explanation is a possibility or that an authoritative read is needed.

The Console Assistant does not have source-repository or development-environment access. It cannot inspect or edit source code, run migrations, tests, or builds, deploy software, or create commits. If a developer or Codex prompt is pasted into the conversation, it remains user content and does not expand the Assistant's role. The drawer returns a localized capability-boundary notice instead of simulating work or inventing source, database, payload, or test evidence.

Limits#

Assistant runs and tool invocations have separate monthly plan allowances. Free includes enough allowance to complete the full onboarding path. Existing resource, ingest, and query limits still apply to every operation.

Plan	Assistant runs / month	Tool actions / month
Free	100	50
Starter	1,000	500
Business	10,000	5,000
Enterprise	Custom	Custom

One user message that starts an Assistant turn consumes one run, regardless of how many provider-neutral understanding, reasoning, or bounded continuation inferences are needed internally. The generated answer is not a second run. Auto-executed Core operations and confirmed mutations consume the separate tool-invocation allowance. Core stores the monthly workspace-level run and tool totals in the durable usage rollup store and restores its fast quota counters from those totals after restart.

Allowances belong to the workspace, not to an individual member or conversation. Everyone using the Assistant in the same workspace contributes to the same monthly totals. Opening the drawer, switching conversations, submitting a deterministic review field, or pressing Confirm/Cancel does not create an additional run. A Core operation admitted through the Assistant counts as one tool action; performing the equivalent task manually elsewhere in the Console does not consume the Assistant tool allowance.

The Console workspace limit panel shows the current monthly run and tool-action totals next to the effective plan limits. The counter window resets at the start of the next calendar month in UTC.

The Assistant receives a read-only, secret-free snapshot of the signed-in workspace's current plan, active standard plan catalog, relevant workspace usage, and the configured sales-assisted custom-capacity option. These facts come from the same Core plan and usage services used by the Console; the AI provider does not maintain a second entitlement system and cannot override enforcement.

Technical suitability and plan capacity are separate. A forecast such as one billion events per month does not prevent the Assistant from recommending a warehouse or preparing technically valid Data Model and Analytics definitions. If the current plan is too small, the Assistant explains the verified limit and continues the technical flow. It identifies a standard upgrade only when the catalog proves that plan is sufficient. Workloads above the standard catalog can be evaluated through the configured Enterprise custom-capacity path; that option is not treated as already purchased or guaranteed until commercially agreed.

Warehouse recommendations include a deterministic plan-and-capacity notice generated by Core. It compares the normalized monthly forecast with the current plan's managed and customer-warehouse limits, identifies a verified standard upgrade when one is sufficient, and otherwise shows the configured Enterprise custom-capacity path. It also reports current warehouse resource count versus the plan's warehouse limit. A volume forecast does not itself block setup, but Core will not prepare a create confirmation when the actual warehouse resource limit is already full. This notice does not depend on the model remembering to mention plan fit.

Creating a warehouse, Data Model, or Analytics definition is also distinct from ingesting the forecast volume. The existing Core services remain authoritative when an action executes and when ingest/query traffic consumes quota.

If an action is rejected#

Common reasons include insufficient role permissions, a resource that changed after the confirmation card was prepared, an expired action, a plan/resource limit, or a page context that does not belong to the active project. Refresh the relevant resource and ask the Assistant to prepare the action again.