How decision intelligence actually works, from a plain-language question through the semantic metrics layer to a grounded answer, with anomaly detection and forecasting with honest uncertainty. Written so you understand the engine before you ever share a byte of data with us.
For years, getting an answer from your data required a data analyst, a ticket queue, and a few days of back and forth. The tooling has changed enough that none of that is necessary. What has not changed is the discipline required to make the answers trustworthy: you cannot just point a language model at a raw database and call it analytics. This guide is the whole method, written out.
Decision intelligence is the practice of making business data answerable in plain language, with the answers grounded in agreed definitions so they mean the same thing to everyone who asks. It is a layer that sits on top of your data warehouse and turns it from a place where data is stored into a place where decisions are made.
It helps to separate three things that often get collapsed into one pitch:
Each of these can stand alone, but they compound. A team that can ask any question, gets alerted when something breaks, and has a forecast for what is coming operates fundamentally differently from one that waits for the weekly review.
Every engagement starts with a free analysis, because it is the only honest way to scope the work. You share a sample of your data and a list of the questions your team is currently asking a person to answer. We model the metrics, run the analysis, and come back with real answers grounded in your numbers, anomalies surfaced on your history, and a forecast with its accuracy measured.
You keep the result whether or not you continue. A measured analysis on your real data is a useful artifact on its own, and it ends the guessing that kills most data projects before they start. If the numbers hold up and the answers are genuinely useful, we scope the full build from there.
The interface that most people see first is the question box. You type "why did revenue dip in March?" in plain English and an answer comes back. The mechanism behind that is a language model that translates your question into SQL, runs it against your data, and returns the result with a chart.
This is where most demos stop and where most projects fail. A language model translating a free-form question into SQL against an undocumented, unlabeled database will produce SQL that runs but returns the wrong number with high confidence. It will join the wrong tables, apply the wrong date filter, and miss the business logic that makes "revenue" mean gross or net depending on the context. The output looks plausible. It is not trustworthy.
The fix is not a smarter model. It is a semantic metrics layer, which is the next section.
The semantic metrics layer is the set of definitions that sit between your raw tables and the question interface. It is where "revenue" gets defined as orders.amount minus refunds.amount, filtered to completed orders, with the rule that a refund applied to a prior-period order adjusts the current period rather than the original one. That definition is encoded once, tested, and then every query uses it.
Building this layer is the majority of the engagement work, and it is also where most of the value sits. Once the metrics are defined, a business user asking "what was revenue in March?" and a data analyst writing the same query will get the same number, because they are both running against the same definition. That consistency is what makes the answers trustworthy enough to put in an exec brief or a board deck.
The layer also carries grain (is this metric daily, monthly, by region, by product?), access rules (who can see which metrics?), and dimension mappings (when someone says "UK", which column values does that map to?). These are the details that a raw language-model query will get wrong, and the layer is what makes getting them right reliable rather than lucky.
Grounding means that every number in an answer can be traced back to the SQL that produced it, and that SQL can be traced back to the metric definition that informed it. A user who questions a number can see exactly how it was computed, which column it came from, and which filter was applied. That is the difference between a result you trust and a result you verify every time.
This matters most at the edges: when a forecast looks surprising, when an anomaly alert fires, when an exec challenges a number in a brief. In each case, the answer to "how did you get this?" is a clean, auditable chain from definition to query to result. That chain is what earns organizational trust in the system over time.
Anomaly detection is the system watching your metrics continuously and alerting when a value breaks outside its expected range. The alert includes the affected metric, the dimension that is driving the break, the magnitude of the deviation, and a plain-language description of the likely cause based on historical patterns.
The engineering behind this is straightforward in concept: for each metric, we fit a model of normal behavior on your historical data, set alert thresholds based on your tolerance for false positives, and then compare each new observation against that model. In practice, the interesting work is in the dimension analysis: not just "revenue is down" but "revenue is down and it is entirely explained by a spike in refund rate in the UK, which has happened three times before when a specific product category had a quality issue."
False positive rate matters. An alert system that fires every other day trains people to ignore it. We calibrate the thresholds during the Build phase using your historical data and your stated tolerance, and we revisit them during Operate as the business changes.
A forecast is a claim about the future, and honest uncertainty is the most useful thing a forecast can contain. A single-point prediction ("revenue next quarter will be EUR 2.4M") is less useful than a range ("the model puts 80% of the probability mass between EUR 2.1M and EUR 2.7M, based on this backtest error"). The range is the thing you plan around.
Our forecasts are built on three disciplines:
What changes the accuracy of a forecast is the quality of the input data and the stability of the underlying process, not the sophistication of the model. A business that changes its pricing strategy every quarter will have a harder time forecasting revenue than one with a stable pricing structure. We make that plain during the analysis rather than promising accuracy we cannot deliver.
On backtesting. The backtest figure we show you in the free analysis is the mean absolute percentage error (MAPE) of the model on held-out periods of your historical data. It is the number you should use to judge whether the forecast is useful for your planning horizon, not a figure we chose to make the pitch look good.
Once the metrics layer is in place and the queries are running, generating a weekly or monthly executive brief is a composition step. The system pulls the key metrics, compares them to the prior period and the forecast, surfaces the anomalies that fired, and writes a short narrative that describes what happened, what to watch, and what the forecast shows. It is sent on a schedule or triggered on demand.
The brief is not creative writing. It is a structured summary of the data, written in plain language, with the numbers grounded in the same definitions that answer the interactive queries. A manager can read it in two minutes and walk into the leadership review knowing the numbers without having built a slide deck.
The value here is not that the narrative is beautifully written. It is that it is ready at 07:00 on Monday rather than at 11:00 after someone has spent the morning pulling it together. The time that frees up is real and it compounds across every week the system runs.
The system sits on top of your existing data warehouse rather than replacing it. We connect to BigQuery, Snowflake, and Postgres as primary targets, with Redshift and Databricks available for teams already running on those platforms. The semantic metrics layer is the portable artifact: it can be defined once and queried from the natural-language interface, from a BI tool like Looker or Metabase via their API, or directly via SQL for teams that want to blend both approaches.
| Layer | What it does | What you keep |
|---|---|---|
| Warehouse (yours) | Stores the raw and transformed data | Full ownership, no migration |
| Semantic metrics layer | Defines metrics, grain, access, dimensions | Portable YAML or SQL definitions |
| Query engine | Translates questions to SQL, runs them, returns results | API access for embedding elsewhere |
| Alert and forecast service | Watches metrics, fires anomaly alerts, runs forecasts | Configured alert rules and thresholds |
| Brief generator | Composes and distributes the exec brief on schedule | Brief templates you own and edit |
Nothing in this stack requires you to move your data. The query layer connects to your warehouse with read-only credentials. The data stays where it is.
Access control is not an afterthought in a well-built metrics layer, it is part of the schema. Each metric is tagged with the roles that are permitted to see it. The query layer checks those tags at runtime: a user asking about executive compensation or customer PII who is not in the right role gets a response that tells them the metric exists but is not available to them, rather than an error or a data leak.
The governance model we recommend is simple: start with the broadest access that is safe, measure which queries are being run and by whom, and tighten where the data shows usage that was not intended. Overly restrictive access from day one kills adoption before the system has a chance to prove its value.
For companies under GDPR or other data-residency obligations, the read-only warehouse connection and the absence of a data copy in our infrastructure are the key facts. We document the data flow in the engagement and can provide the technical architecture for a compliance review.
A system that nobody uses is not a success, however good the underlying technology. We track two categories of metric through the Operate phase:
| Metric | What it tells you |
|---|---|
| Time to insight | How long from a question to an answer, against the pre-system baseline |
| Query volume by team | Whether the system is being used and by whom, as a leading indicator of adoption |
| Forecast MAPE by metric | How the forecast accuracy evolves as the model is retrained on more data |
| Alert precision | The share of anomaly alerts that led to a real investigation (true positives) |
| Brief open rate | Whether the exec briefs are being read, as a proxy for whether they are useful |
The adoption metric matters as much as the accuracy metric. A technically excellent system that is bypassed in favour of a spreadsheet has not delivered value. We revisit both categories in the monthly Operate report and adjust the configuration when either is trending in the wrong direction.
A short list of approaches that look reasonable and fail in practice:
The shape of the work: a free analysis to prove the approach on your own data, a fixed-scope Build that connects the warehouse and ships the metrics layer, natural-language interface, anomaly alerts, and first exec brief, then an Operate phase that keeps the metrics and forecasts honest as your business and data change. You get one point of contact, software that runs on your infrastructure, and the measurement to prove it is working.
AI Analytics is our second AI service. The same methodology that makes Document AI trustworthy, start with a free pilot, measure before you commit, ship a real workflow, own the result, is what makes AI Analytics trustworthy. The services complement each other: Document AI turns documents into data, AI Analytics turns data into decisions. Start with a free analysis.
That is the whole engine. The next step is a free analysis on your own data: real answers to your real questions, the anomalies surfaced, the forecasts backtested, and no obligation.
A free analysis on your real data, the metrics modeled and backtested, the anomalies surfaced. Then we build the layer that makes every answer take seconds.
Get a free analysis