Analytics, reporting and decision support

Figures people act on, with the records behind them.

What it is

Decision support is the last step of a data platform and the only one most people see. It covers the data warehouse and the marts that hold the figures, OLAP models and analytics for analysts and controllers, reporting systems for management, KPI systems for operations, and live dashboards for the shop floor or control room. Cloudtech builds all of it, fed by the pipelines it builds for your systems or by data you already have.

The difference between a report that is used and one that is ignored is rarely the chart. It is whether the reader believes the number and can see why it is what it is. That is an engineering problem: definitions, denominators, freshness and traceability.

In the industry’s terms this is decision support: the person decides. Decision augmentation and automation, where a model explains, forecasts or acts, are the work of AI integration, on the same warehouse and the same definitions. The other lines meet here too: Data platform engineering feeds the warehouse continuously, Software development writes the KPI applications, DevOps, automation and observability versions every model and report, and Managed platform and database services runs the warehouse 24/7.

What we do

Data warehouses and marts. Star-schema warehouses and marts with a declared grain and conformed dimensions, loaded continuously as the source systems change rather than by a nightly ETL job. Storage is columnar, so a query over years of facts reads only the columns it needs: Snowflake, Amazon Redshift or Microsoft Fabric in the cloud, DuckDB as compact local analytics, and Oracle or PostgreSQL on premises with their columnar options.
Reporting systems. Operational and management reporting: real-time, shift, daily, weekly and period reports, scheduled or on demand, exported as PDF where a document is needed. Management reports follow one notation across the company, so a variance looks the same on every page.
KPI systems. Every KPI is defined once with the people accountable for it: numerator, denominator, filters, time grain, owner. It is computed once, in the pipeline or the warehouse, as one metrics layer, and every screen, report and export reads that one figure. Where an industry standard defines the measure, such as ISO 22400 for manufacturing KPIs, the definition follows it.
Live analytical dashboards. Figures are pushed to the screen as they change in real-time, over server-sent events, instead of being polled. A new event is visible within a second. A dashboard that has lost its connection says so, rather than showing a quiet plant.
Drill-down to the records. Every figure links to the rows that produced it, with the reporting period carried along. Where a figure counts mentions rather than rows, the screen says so.
Statistical views where they apply. Control charts with limits drawn from the data, Pareto analysis, recurrence and trend views. The method is shown next to the result.
Delivery to the people who need it. Interfaces in the users’ languages, role-based access enforced by the server, per-user layouts, light and dark themes, and an audit log of administrative actions.

What you get

The scope is set per engagement, from one KPI screen on one line to the warehouse a company reports from. What you receive follows the practice the industry has settled on for warehouses and BI: dimensional models, a metrics layer, transformations as code and reconciled figures.

A dimensional model and data dictionary. The business processes, their grain and the conformed dimensions they share, documented well enough for your own analysts to extend without asking.
A warehouse loaded continuously. Facts arrive as the source systems change. Freshness is stated per subject area and monitored against that statement, history is kept, and any layer can be rebuilt from the one beneath it.
A metrics catalogue. Definition, numerator and denominator, source, owner and refresh for every figure, and the same definition in every screen, report and export.
Reports and dashboards that drill down. Every figure leads to the records behind it, with the reporting period carried along, in the users’ languages, with roles enforced by the server and an audit log.
Transformations as code. Models, jobs and report definitions in version control, reviewed and deployed through CI/CD, with lineage from source to figure documented.
Reconciled figures. Every warehouse and every report runs in parallel with what it replaces until the numbers agree, and the reconciliation is kept as sign-off evidence.
Measured performance. Response times for the screens that matter, measured before and after.
Operations. The warehouse and its reports under the 24/7 service with a P1 reaction within the hour.

AI adoption

AI enters this service line in many forms; two examples show the pattern, and both stand on the warehouse and the metrics layer rather than beside them.

One is embedding an existing model with your structured data. The model is not retrained and the warehouse does not change; the records are handed to the model as context. Pretrained tabular models take your rows as they are and predict in a single pass, and on tables of up to ten thousand records they outperform gradient-boosted trees given four hours of tuning.¹ Models that read the warehouse through its keys learn directly from the related tables, without hand-built features; in a benchmark study they matched or beat an experienced data scientist on most tasks and cut the hours worked by 96 per cent.² When the model is a language model answering plain-language questions, the metrics layer is what makes it reliable: given the business definitions beside the schema, three frontier models each gained 17 to 23 points of accuracy, while on real enterprise schemas without them the best agent solved one query in five.³

The other is training decision models on your own data. For the decisions an operation makes many times a day, pass or inspect, approve or escalate, flag or clear, a model trained on your history that returns a probability for each allowed answer is the workhorse, and gradient-boosted trees remain strong contenders on practical tables.⁴ For a narrow, well-defined task, a compact model fine-tuned on your data matches or beats much larger general models and runs locally.⁵ The newest form is the decision-only model, with TypeSafe AI’s Jev as the best-known example: it returns a decision, a probability for each option and a confidence score rather than text, and a threshold frozen in advance decides which cases software acts on and which go to a person. In a 2026 study of that cascade it matched a frontier reasoning model’s accuracy at a fraction of the cost.⁶ Cloudtech trains and runs models of this kind inside your boundary. Each decision is explained, written back into the warehouse as one more governed figure and monitored for drift, and the threshold is set from measured accuracy on your own data, not from a vendor’s benchmark.

Forecasts from pretrained time-series models that need no task-specific training, and plain-language explanations of anomalies that statistics have already detected, follow the same pattern.⁷ In every case the figures stay traceable to the records behind them and nothing leaves your boundary. Building the models is the work of AI integration; what this service line provides is the data they can be trusted with.

Built on what you have, or built for you

Not every reporting problem needs a new warehouse. Where a warehouse or a BI tool is already in place and trusted, Cloudtech builds the missing models, figures and applications on top of it and publishes its models to the tool your people already use. Where there is no warehouse, or the one there is cannot be trusted, Cloudtech builds it. Where the source data is the problem, the work starts in Data platform engineering.