Technical governance for conversational BI

Rumbleo operates as a governed layer between your users, your semantic model, your analytical databases, and the configured LLM provider. The platform resolves identity, permissions, connection, execution, audit, and usage before querying data

Tenant

One isolated organization

Data

Read-only execution

LLM

No credentials or direct database access

Authenticated session

tenant_id, user_id, role

Policy engine

tools, limits, timeout, row_limit

Semantic model

metrics, dimensions, joins

Validated query

SELECT / CTE, read-only

Audit trail

audit_id, usage, status, rows

Rumbleo system architecture

Rumbleo combines business context, analytical connections, and configurable agents inside a central governance layer

Business context

Tenant configuration

Semantic models

Metrics, dimensions, relationships, granularity, and official definitions

Customer prompt

Tenant base instructions to adapt tone, scope, and analysis rules

Database connections

Governed analytical databases with internal read-only credentials

Agents

Personal or organization agents that specialize analysis by domain or method

Analytical examples

Saved questions and reference queries that guide recurring analysis

Rumbleo core

Governed orchestrator

Control before execution

Resolves identity, session, model, tools, limits, and policies before querying data

Allowed capabilities

Semantic tools, limits, timeout, autonomy level, and permissions available for each channel

Configured LLM model

Policy-configured model, without analytical credentials or direct database connections

Semantic execution

Translation from semantic model to validated read-only queries scoped to the tenant

Audit and usage

Events, status, rows, errors, model, provider, tokens, and usage attached to each execution

Experience and execution

Conversational answer

Analysis methodology

Planning, clarifications, queries, comparison, explanation, and recommendations

Conversational interface

Webapp and compatible channels to ask, continue conversations, and share findings

History and sharing

Private-by-default history, thread continuation, and explicit sharing with tenant users

Artifacts and attachments

Input documents, generated files, tables, charts, and platform-proxied downloads

Cross-cutting layer

Governance, audit, policies, identity, limits, privacy, and traceability

What does not cross the data boundary

The LLM provider does not receive credentials, does not open connections to your warehouse, and does not decide identity, tenant, or permissions; Rumbleo acts as the governance proxy and only returns structured results from allowed queries

Analytical credentials are stored as orchestrator-recoverable secrets and encrypted with envelope encryption in deployed environments

The analytical database is queried through internal adapters and read-only users; writes, DDL, administrative commands, and dangerous functions are blocked

Queries are limited by rows and timeout, run on the active tenant connection, and are not exposed in the normal user experience

Detectable sensitive results in samples or tabular responses are masked before return when they match sensitive column patterns

In external channels, the agent only invokes governed tools such as get_semantic_model and run_analytical_query; the platform keeps audit, limits, and session control

Governed entities inside Rumbleo

Tenant

The isolation unit where each organization has its own users, agents, conversations, semantic model, analytical connection, limits, audit trail, and usage

Semantic model

The functional representation of the business, loaded per tenant, not editable by tenant analysts or tenant admins in the platform, and used as the source of truth for analysis

Analytical connections

Connections to analytical databases configured for the tenant, with several governed databases and one default connection when applicable; credentials never reach the browser

Agents

Configurable instructions inside the tenant to specialize analysis by domain, method, or style, available to the organization's users

Conversations

Threads with contextual memory, associated agent, state, messages, and artifacts, which the owner can share with other users in the same tenant

Audit and usage

Usage events, tool calls, queries, timings, errors, status, rows, and consumption, with full content reserved for authorized internal support

Operational control over users, models, and usage

Organization isolation

Operations are always resolved against one active tenant. Users, agents, conversations, connections, and consumption are not mixed across organizations

Clear roles

Analysts ask questions and work with agents; tenant admins manage users and see usage metrics; internal operators administer tenants and audit trails for support and security

Visibility without reading conversations

Tenant admins see activity, active users, questions per user, consumption, aggregate errors, agents, and operational status, but they do not read other users' questions, answers, data, or queries unless a conversation is explicitly shared

Transparent consumption

Usage is monthly and shared by tenant, with consumption recorded by tenant, user, agent, model, token, and event so teams know how much is consumed and where

Customer LLM credentials

When the configured mode allows it, the tenant can bring its own OpenAI credential; the key is stored encrypted, never exposed to the frontend, and monthly limits still apply

Models under policy

The organization can control available models and default configuration, with calls associated with provider, model, credential source, and consumption

Tenant control and exposure limits

The organization keeps operational control of the experience without exposing credentials or opening direct access to the LLM provider

What the customer controls

Available models and default configuration

Own OpenAI credential when the mode allows it

Tenant users, roles, and agents

Analytical connection and read-only credentials

Shared monthly usage and operational limits

Explicit conversation sharing inside the tenant

What does not happen

The LLM does not execute free SQL against the analytical database

Credentials do not reach the browser

The LLM provider does not open direct warehouse connections

Data, users, agents, and conversations are not mixed across tenants

Internal queries are not shown in the normal user experience

Artifacts are not downloaded without going through the platform

Semantic model traceability

Every analytical answer starts from tenant-versioned definitions: official metrics, compatible dimensions, relationships, granularity, filters, examples, and limitations; if a metric is ambiguous, the system should ask for clarification, and if a definition does not exist in the model, it should not invent it as official

Active model, files, and source documented per tenant

Business term resolution before data execution

Internal queries associated with audit, not visible to the end user

Results include limitations, truncation, or blocking when policy requires it

Controlled collaboration

Users in the same tenant can work over the same data available to the organization and use shared tenant agents; conversations remain private by default and can be shared with specific people in the tenant to review analysis, continue an investigation, or align decisions without exporting the content out of the platform

Users in the same tenant work over the same available data

Shared agents align analysis criteria

Conversations are private by default

Explicit sharing with specific people in the tenant

Traceability example

Each execution leaves a functional trail to review identity, context, tool, status, and usage without showing internal queries to the end user

audit_id

aud_7f3c9a

tenant

acme_retail

user

analyst@company.com

agent

Revenue analyst

semantic_model

retail_v12

tool

run_analytical_query

status

completed

usage

1,248 tokens

Connection and deployment

The connection is prepared to operate over a governed analytical database, with controlled reads, encrypted secrets, and execution limits

Analytical database

Governed connectors for supported or planned databases according to deployment

Read-only credentials

Read users, encrypted secrets, and recovery only from the orchestrator

Execution limits

Timeout, row limit, and pre-validation before querying data

Controlled output

Tables, charts, files, and downloads served by platform endpoints

Governance before execution

Connect conversational BI without opening your warehouse to the model

Rumbleo keeps execution, identity, security, audit, and usage inside the platform while your teams ask natural-language questions over traceable business definitions

Request a demo