Spreadsheet & text files
Excel workbooks, CSV, TSV, and delimited text are parsed in the browser and registered as queryable tables.
XLSX / XLS / XLSM / CSV / TSV / TXT
Technical overview / Vibe Data
Document: VT-DAT-01Revision: 1.0 Implemented architecture
Vibe Data AI Integration Architecture
An implementation architecture that translates natural-language intent into grounded, source-aware plans across files, databases, analytics, pipelines, and visual outputs.
01
AI Integration Architecture
Logical boundaries and authoritative data sources
Vibe Data AI integration architecture Implemented architecture
Vibe Data Workspace
Natural-language analysis, connected datasets, pipelines, dashboards, charts, and exports
Chat workspaceDataset catalogPipeline editorDashboards
Orchestration & Translation Layer
Maps intent to source-aware query plans, executes approved operations, and combines results across systems
Catalog groundingQuery planningDialect translationResult coordination
AI Model
Produces structured query and pipeline plans from the supplied dataset manifests and conversation context
GeminiOpenAIApproved model endpoints
Connected Data Sources
File datasets and remote databases supply authoritative schemas and rows
CSV / Excel / SQLitePostgreSQLMySQL / MariaDBMongoDB
Application Records
Durable conversations, dataset manifests, imported rows, dashboards, pipeline definitions, and run history
Threads & messagesDatasetsDashboardsPipeline runs
Execution boundary. The model creates a structured plan. Source systems retain their data authority, while the orchestration layer mediates access and combines validated results.
02
Data sources & model services
Supported inputs and planning boundary
SQLite files
SQLite databases are opened in-browser through WebAssembly, with each discovered table added to the local dataset catalog.
SQLite / SQLite3 / DB
PostgreSQL
Schema metadata is introspected and planned SQL executes against the remote PostgreSQL source through a server boundary.
Native dialect / encrypted transport required by default
MySQL & MariaDB
Remote table metadata and rows are retrieved with single-statement execution and optional transport encryption.
Native dialect / multiple statements disabled
MongoDB
Collections are sampled for schema inference and accessed through bounded find, aggregate, insert, update, and delete operations.
Document and aggregation operations
AI model
Gemini, OpenAI, or another approved model converts grounded catalog context into structured query and pipeline plans.
Selectable provider and model boundary
03
Query lifecycle
From natural-language intent to a traceable result
- 01
Capture
Persist the user's question and update the thread record before planning begins.
- 02
Scope
Stop with a recorded notice if no dataset is active; otherwise resolve conversation, datasets, and model.
- 03
Catalog
Serialize source type, dialect, manifest, capabilities, notes, and file-table engine names.
- 04
Propose
Generate native source steps, final local SQL, and optional chart or analysis specifications.
- 05
Normalize
Parse the structured response, normalize recoverable fields, or exit with a focused clarification.
- 06
Register
Load imported file rows into named in-memory tables before any remote step runs.
- 07
Acquire
Execute each remote step in its native system and register returned rows under its planned alias.
- 08
Shape
Run final local SQL across engine tables, or return the last remote result when final SQL is absent.
- 09
Analyze
When specified, apply the requested deterministic statistical routine to the final rows.
- 10
Record
Persist the assistant response with its plan, outcomes, result payload, summary, and errors.
- 11
Present
Render the stored result as a table, chart, analysis view, and execution details.
- 12
Reuse
Optionally export the rendered output or save the completed query view to a dashboard.
04
Query execution network
Detailed flow inside Vibe Data's orchestration layer
Query execution network Source-aware execution
Capture & Persist Intent
The workspace stores the user's question, updates thread activity, and establishes the conversation record before planning begins
User messageThread titleActivity timestamp
Active Dataset Guard & Scope
The request stops with a recorded notice when no dataset is active; otherwise enabled datasets, recent messages, and model selection define scope
Availability checkRecent messagesEnabled datasetsModel selection
Manifest & Catalog Assembly
Dataset kinds, manifests, source dialects, and local engine table names are serialized into the context supplied to the model
Tables & columnsCapabilities & notesEngine table names
Structured Query Plan Generation
The model proposes native source steps, final local SQL, and optional chart or deterministic analysis specifications
Remote operationsFinal SQLChart specAnalysis spec
Plan Normalization & Clarification Gate
Structured output is parsed and normalized; an ambiguous request is recorded as a focused clarification and exits before execution
Schema parsingAlias defaultsType normalizationEarly exit
Local File Table Registration
Rows already imported from CSV, Excel, text, or SQLite datasets are registered first as named tables in the in-memory engine
Imported rowsEngine table namesNo remote fetch
Native Remote Step Execution
Each planned PostgreSQL, MySQL, or MongoDB operation runs against its source, and returned rows are registered under the planned alias
Native SQL / MongoSequential steps5,000-row response cap
Result Shaping
Final local SQL combines and shapes engine tables; when no final SQL is supplied, the last remote result is returned directly
AlaSQLCross-source joinsFilter & aggregateDirect-result fallback
Optional Deterministic Analysis
When the plan includes an analysis specification, the final result rows pass into the requested statistical routine
RegressionForecastingClusteringAnomaly detection
Persist Assistant Response
The assistant message stores the generated plan, per-step outcomes, result payload, chart, analysis, summary, and any execution error
PlanStep outcomesResult payloadErrors
Result Presentation
The stored message payload renders as a result table, chart, analysis view, execution details, and generated summary
Result tableNine chart formsAnalysis viewStep details
Optional Export & Dashboard Save
After rendering, the user may export the result or chart, or save the completed query view to a dashboard
CSV / JSON / XLSXSQL / SQLite / MongoPNG chartDashboard widget
Execution boundary. Remote queries execute in their native dialects. Only returned rows and imported file tables enter the local engine for cross-source composition and analysis.
05
Responsibility & trust boundaries
Authority by system component
ComponentResponsible forNot responsible for
Vibe Data workspace
Responsible for
User intent, active-source selection, conversation, pipeline editing, and result presentation
Not responsible for
Does not connect directly to remote databases or decide source-specific query syntax
AI model
Responsible for
Structured query and pipeline proposals grounded in the supplied catalog
Not responsible for
Does not access source credentials, execute queries, or inspect rows before execution
Orchestration & execution
Responsible for
Catalog assembly, plan normalization, source routing, local joins, analysis, and result coordination
Not responsible for
Does not replace the authoritative data held by connected systems
Connected sources
Responsible for
Original schemas, source records, native query behavior, and accepted remote writes
Not responsible for
Do not determine how data from other sources is combined or displayed
Application records
Responsible for
Conversations, manifests, imported file rows, dashboards, pipeline definitions, and run history
Not responsible for
Do not supersede current records in an external database
06
Execution & quality controls
Deterministic safeguards around generated plans
Server-mediated connections
Remote database operations and model requests run behind server functions rather than from browser query code.
Credentials excluded from generated plans
Clarification before inference
Planning instructions require one focused clarification when a source, table, column, grouping, or destination is ambiguous.
No silent schema invention
Bounded retrieval
Read plans default to limits, and remote result handling applies a hard cap before rows enter the local engine.
5,000-row remote hard cap
Structured plan normalization
Model output is parsed into the supported plan shape and recoverable fields are normalized before source operations execute.
Recoverable parsing and normalized fields
Source isolation
Each remote step runs in its source's native dialect; returned aliases are combined only after retrieval.
Cross-source work occurs in memory
Quality-aware pipelines
Row-count, not-null, uniqueness, allowed-set, and range expectations can warn or stop a pipeline.
Explicit stop or warning behavior
Failure behavior: missing source details trigger clarification; invalid plans, connection failures, query errors, quality failures, and analysis errors are returned explicitly rather than silently treated as valid results.
07
Persistent application records
Conversations, connected data, saved views, and pipeline history
Threads & messages
Conversation history with generated plans, execution outcomes, result metadata, and analysis responses
Datasets
Source type, connection configuration, manifest, availability state, and enabled status
Dataset tables
Imported file schemas, rows, table names, and row counts used by the local engine
Dashboards & widgets
Saved query plans, prompts, chart or table type, layout position, and sizing
Pipelines
Ordered source, transform, quality, analysis, and load steps with operating state
Pipeline runs
Trigger, duration, input/output counts, step results, metrics, status, and failure details