LightBI Starts With Understanding the Data, Not Drawing the Chart

A different starting point for BI

LightBI started from a practical problem: many business intelligence tools assume that data is already clean, the schema is already understood, and the user already knows which query to write.

That assumption breaks down in real operations. Data arrives as workbooks with multiple sheets, manual exports, ERP reports, online files, and tables whose headers are inconsistent across teams. A column named Qty, Units, or Stock Quantity may look similar while representing a different grain or business meaning.

So LightBI does not begin by drawing a chart. It begins by asking what the source actually contains.

Understand the source before using it

The first stage profiles the physical source: rows, columns, types, sample values, completeness, and data-quality signals. The next stage looks for semantic evidence such as time, revenue, product, warehouse, status, customer, order, or shipment.

Finding a possible meaning is not the same as proving that a dataset is ready for a business conclusion. LightBI also has to reason about row grain, relationships between sources, ambiguous fields, and whether a metric can be executed safely.

This distinction is central to the project. Signal recognition is one capability. Dataset understanding, business interpretation, and executable decision support are progressively stronger capabilities. A broad dictionary of column aliases cannot, by itself, prove that an entire domain is supported.

Questions instead of an empty canvas

LightBI uses a Question-first direction so that operators do not have to begin with SQL, DAX, or a complex data model. The user can start with a question such as:

• How does revenue change over time?
• Which locations show inventory or backlog risk?
• How does delivery activity differ across routes?
• Which rows need to be checked before analysis?

The question is then connected to physical fields, measures, dimensions, source identity, and evidence scope. If the source cannot support the question safely, the system should make that limitation visible instead of inventing a plausible answer.

A pipeline with explicit boundaries

The architecture separates source intake, canonical understanding, domain support, planning, execution, and presentation.

1. The source adapter records the physical source boundary.
2. The Understanding Core profiles the data and resolves semantic, grain, relationship, and readiness evidence.
3. A domain support gate determines which questions and metrics are actually allowed.
4. The planner creates a deterministic execution plan.
5. DuckDB executes the guarded analytical query against the bound source.
6. The result becomes a chart, decision brief, Deep BA view, or export while retaining scope and limitations.

This separation prevents a UI component, a chart recommendation, or a future provider from silently redefining business meaning. The runtime consumes an approved binding; it does not guess a new one.

Fail closed when the evidence is weak

One of the less glamorous but more important design rules is fail-closed behavior. If a source fingerprint is stale, a required physical field is missing, a relationship is not sufficiently supported, or a measure is ambiguous, execution must stop or narrow its claim.

That is also why multi-source analysis cannot simply flatten every file into one table. Source identity, role, period, relationship, and duplication risk all need evidence before a combined route is allowed.

Simple Mode and Advanced Mode

Simple Mode is intended for operators who want a trustworthy analytical path without learning the internals of a database engine. Advanced Mode is for users who need schema inspection, SQL, filters, imports, exports, connection profiles, and controlled writeback review.

The two modes share the same source and evidence boundaries. Advanced work can be handed back into the governed analysis flow, while Simple Mode does not need to expose provider-specific implementation details.

What is implemented, and what is not

LightBI is currently a Public Beta. The repository contains local-first file analysis, DuckDB execution, governed questions, Deep BA flows, multi-file work, provider contracts, and regression evidence for real and sanitized datasets. The project also records its limitations openly because a green unit test is not the same as product acceptance.

AI is not a current LightBI feature. It appears in the architecture and roadmap as an optional future assistant for reporting or explanation. The current product does not depend on an LLM to understand data, calculate KPIs, score trust, execute queries, or mutate sources.

Where the project is going

The live distribution page is available at lightbi.thaiduy.digital, and the current web application can be evaluated at lightbi.thaiduy.digital/app. The source and development history are published in the LightBI GitHub repository.

The goal is not to turn every raw file into a dashboard in a few seconds. The goal is to make clear what the data can support, where the evidence lives, and which conclusions still need more work.

Technical references

The implementation and evidence behind this entry are documented in the LightBI README, the architecture overview, and the MVP decision record. Privacy boundaries are described in PRIVACY.md. The provider extension boundary is documented in the Provider Plugin SDK manual.