LightBI

Business understanding before dashboard output

LightBI is a Business Understanding Engine for operational data. It is designed for the files and reports that teams actually receive: Excel workbooks with multiple sheets, CSV and text exports, online files, database results, inconsistent headers, mixed languages, and related ERP reports that must not be joined by guesswork.

The product does not treat a chart as the first proof of correctness. It first profiles the physical source, identifies semantic evidence, checks row grain and relationships, evaluates readiness, and exposes only the questions and metrics that the available evidence can support.

Core capabilities

• Source understanding: physical profiling, column and value inspection, data-quality signals, semantic candidates, grain inference, and source fingerprinting.
• Question-first analysis: operators can begin with business questions instead of SQL, DAX, or a blank dashboard canvas.
• Governed execution: selected actions remain bound to source identity, physical fields, measures, dimensions, aggregation, and evidence scope.
• Local analytical runtime: local file analysis runs through DuckDB, with stale or mismatched source handoffs failing closed.
• Decision output: executed evidence can become KPIs, charts, decision briefs, Deep BA investigations, dashboards, and exports.
• Advanced workspace: technical users can inspect schemas, query supported sources, filter results, import/export data, and review writeback plans.

How the system is structured

LightBI is a TypeScript and Rust monorepo. React provides the desktop and web interface. The shared contracts define projects, datasets, recipes, execution plans, result buffers, plugins, and evidence boundaries. Rust and Axum provide the native/server runtime boundaries, while DuckDB handles local analytical execution and SQLite stores application metadata.

The canonical path is:

1. Intake records a local file, online file, or database result.
2. The Understanding Core profiles the complete source and representative evidence sample.
3. Semantic, grain, relationship, and readiness evidence are resolved.
4. Domain support gates determine which questions, metrics, and actions are allowed.
5. A deterministic plan is created and executed against the bound source.
6. The result is presented with evidence, scope, caveats, and limitations.

Presentation layers do not redefine business meaning. Runtime executors consume canonical bindings, and multi-source analysis keeps source-local identity until a governed relationship is proven.

Simple Mode and Advanced Mode

Simple Mode is for operators who need a guided route from raw data to a useful, reviewable answer. It hides unnecessary technical mapping while keeping trust and limitations visible.

Advanced Mode is for analysts and technical operators who need schema discovery, SQL, filters, connection profiles, import/export, result editing, and controlled mutation review. Results can be handed back into the governed analysis flow instead of becoming a separate definition of truth.

Safety and evidence boundaries

• No speculative joins between unrelated sources.
• No unguarded aggregation of identifiers or ambiguous measures.
• No execution when source identity or runtime continuity is stale.
• No causal claim without supporting evidence.
• No silent fallback from a governed metric to another measure.
• Subset analysis retains its parent scope and active filters.

These restrictions are product behavior, not only documentation. The Beta acceptance process measures mapping precision, signal recall, grain accuracy, domain activation, runnable actions, metric correctness, blocked-action explanations, and time to the first valid result.

Current status

LightBI is in Public Beta. The live distribution is available at lightbi.thaiduy.digital, and the web application can be evaluated at lightbi.thaiduy.digital/app.

AI is not a current product feature. It remains an optional future direction for reporting or explanation. The current LightBI runtime does not depend on an LLM to understand data, calculate KPIs, score trust, execute queries, or mutate sources.

Provider expansion is also deliberately governed. The plugin SDK currently defines trusted provider contracts and exposure gates; it is not yet a dynamic third-party marketplace runtime.

Technical references

Source and implementation: LightBI GitHub repository. Architecture: architecture overview. Product boundary and MVP decisions: MVP decision record. Provider extension contract: Provider Plugin SDK manual.