DecisionBox writes down
what your data means.

Connect a warehouse and DecisionBox indexes it before anything else. For each table it reads the columns, their types, the row count and a few sample rows. Then it writes 2 to 4 sentences: what one row is, which columns matter most, which ones look like keys, and what the table is useful for. It also marks each column's role, such as dimension, metric or time, from its name and type.

Those descriptions go into a searchable index. On a warehouse with thousands of tables, DecisionBox starts from a catalog with one line per table and finds the right tables by meaning. It pulls full column detail only for the tables it uses, so the model never has to read every column at once.

In our demo runs, indexing a 9-table warehouse took between 30 seconds and about 3 minutes. Nobody had to write a data model first.

The index is open to your team. In the schema editor, pick a table and read the description DecisionBox wrote for it. Rewrite one that is off, add keywords, or remove a noisy column or an irrelevant table from the index. Your warehouse isn't touched. The change applies at once, for discovery and for Ask.

Every edit is recorded: who made it, when, and what it said before. When your warehouse changes, re-index it. DecisionBox rebuilds the descriptions from the warehouse as it is now, picks up new and dropped tables, and warns you first if your edits would be replaced. They stay in the history, ready to re-apply.

Some meaning never makes it into a schema. Add it as knowledge: a data dictionary, a policy document, a web page, a Google Drive folder, or a short note in plain words.

“GMV means the sum of item price, excluding freight.”

Pin a note and it is in context for every run and every answer. Ask what your GMV was in 2017, and the query Ask writes applies your definition: item prices, excluding freight.

Sometimes a run meets two definitions that could both be right, such as GMV with or without freight, or a column whose meaning the data can't settle. Instead of settling it silently, DecisionBox can ask a few short questions after the run, grounded in what it saw.

You answer with a choice or a short sentence. Each answer is saved as a pinned note that the next run reads instead of guessing again. Over time the answers add up to your business definitions, written down once.

A playbook tells DecisionBox what to investigate: the analysis areas and the questions inside each one. The project profile beside it holds your business facts and the targets you measure against. Start from a built-in playbook, edit it in the dashboard, or import one as a file. On Enterprise, DecisionBox can write the first version from your schema and your documents.

When runs keep finding signals that no analysis area covers, DecisionBox can propose a change to the playbook, with its reason. You decide per project whether proposals wait for approval.

Discovery Scope sets which tables are in bounds. It applies from indexing onward, so an out-of-scope table is never described, searched or queried. Governance rules hide or redact sensitive columns on top of that.

When a project spans more than one data source, each source gets a short card: what data it holds, the main things it records and the measures it tracks. Ask uses the cards, together with a search of each source's tables, to send each question to the right source. DecisionBox suggests the keys that join one source to another, and your team confirms or rejects them.