The Product Strategy set out eight capabilities the analytics suite had to deliver. This document takes each one in turn — the requirement as the business framed it, and the capability now running in the product — explained in full, with technical terms written out rather than assumed.
One principle organises this whole document: collapse the distance between intent — what the business asked for — and content — the trustworthy thing now running in the product.
Every requirement below has the same three parts. First, what they asked for — the intent, in a single sentence. Then what we built — the content, the capability now running. And finally a short analogy that makes the capability concrete. Read it top to bottom, or jump to the one you need.
In this domain the letters "RAG" get used two completely different ways. When it describes the knowledge base, it means Retrieval-Augmented Generation — an Artificial-Intelligence-searchable library. When it describes alerts and status, it means Red-Amber-Green — a traffic-light health rating. To avoid blurring them, this document always writes both out in full.
This document is the high-level overview. The full record lives here: the problem statement, the Product-Requirements gap analysis, every feature, and the live demo application — with complete documentation, the build checklists, and the future plan of action, all in one place.
AskedOne official place that records what every metric means — its definition, who owns it, where it comes from, its history, and the approved "golden" way to calculate it — so people stop arguing about whose number is right.
BuiltA governed dictionary of 29 metrics on a searchable Artificial-Intelligence knowledge base. You can look up a definition, trace a metric's family tree (what feeds it, and what depends on it), and read its full version history. The rest of the product pulls its definitions from here rather than hardcoding them — so there is exactly one source of truth.
The dictionary plus the editorial board — not just "here's what the word means," but "here's who approved that meaning, when it last changed, and why."
AskedA single, central, trustworthy store of the company's key numbers — quick to read, version-controlled, and sliceable by dimension (by platform, by region, by category, and so on). The target: return an answer in under three seconds.
BuiltA "gold" number store that answers in roughly five milliseconds — thousandths of a second, far under the three-second target. Three ideas make it fast and trustworthy, and they're worth spelling out, because the whole product rests on them.
Raw company data arrives messy — duplicate rows, half-finished records, journal logs. It gets cleaned in stages: the raw layer is tidied into a silver layer (cleaned and standardised), then summarised into a gold layer (business-ready totals, ready to report). Our product only ever reads the silver and gold layers — the polished, trustworthy data — never the messy raw journals. The gold layer is the finished dish on the pass; nobody serves customers straight from the unwashed crate of vegetables.
A normal spreadsheet stores data row by row (one whole order, then the next). Our gold data is stored column by column — all the "amounts" together, all the "regions" together. When you ask "what's the total amount across millions of orders," the engine reads just the one "amount" column and adds it up, instead of wading through every full row. That's the difference between a near-instant answer and a slow one.
We use a tool called DuckDB. It speaks the same query language every database speaks (the same "give me the total by region" requests), but it has a different shape: instead of being a separate server you phone over the network, it runs inside our own program and reads those column-by-column files directly. A traditional database is the restaurant kitchen — a separate operation you send order tickets to. DuckDB is a calculator on your desk that reads the spreadsheets directly — no waiter, no round-trip.
Right now the numbers are realistic demo data, generated to be identical every time, and they live on this machine as files — not on the other machine, and not changing on their own. When this goes to the customer, we point the same engine at their real data platform instead. Only one thing changes: where the table lives (a local file path becomes the customer's data-platform connection). The way we calculate every metric, the trust receipts, the family tree — all stay exactly the same. We swap the pantry, not the recipe and not the kitchen.
A calculator that reads the finished, polished spreadsheets column-by-column — so "total this across millions of rows" comes back almost instantly, and pointing it at the customer's real data later is just changing which spreadsheet it opens.
AskedStop relying on people to notice problems. Automatically watch for both data-quality problems (a feed broke, "refunded before it was ordered") and business-performance problems (a metric went into the red), then don't just alarm — explain the cause — and deliver that to the right people.
BuiltThe flagship. Alerts watch the data and rate each metric Red, Amber, or Green (a traffic-light health rating). When one turns red, the system runs an investigation by itself: it walks down a branching "issue tree" — is it traffic? the funnel? payments? — to the actual root cause, and rules out the innocent suspects with evidence (not seasonality, not that one-day data gap, not a coincidence elsewhere). It then delivers the finding to eight delivery channels — in-app, email, a weekly digest, a printable review deck, Slack, Microsoft Teams, WhatsApp, or a generic webhook — and can also raise a ticket or page (Jira, ServiceNow, PagerDuty) or push to a business-intelligence tool (Tableau). The standout is what it catches that a normal dashboard structurally cannot: a number that looks flat but is hiding a real change, and a number that looks healthy because a festival's volume is masking a failure underneath.
Most tools are a smoke alarm — they beep. This one beeps, walks through the house, finds the actual smouldering wire, and tells you it already checked the candles and the toaster and those were fine.
AskedA place for analysts to do real exploration — connect to data, slice it, run analysis and machine-learning, build interactive boards, and try "what-if" scenarios — without exporting everything to a spreadsheet on their own laptop.
BuiltA workspace where you compose governed slices of data into saved multi-metric boards — and every single cell carries its own receipt showing where its number came from. It includes a slice-builder, an automatic "what moved the most" scan, the ability to save a useful analysis as a reusable skill, and a no-code "what-if" sandbox (drag sliders, watch the projected result flow through a transparent model on real data). The heavier machine-learning toolkits are the next build, on local computing power.
A proper workshop with labelled tools, versus everyone whittling at their own desk with a pocket-knife and no record of what they did.
AskedLet people build dashboards in plain English, avoid the sprawl of fifty near-identical dashboards, publish and share them, and get automatic summaries and health scores.
BuiltA plain-English dashboard builder (type what you want, and real tiles appear over the governed data), a template gallery, a "you already have one like this" duplicate-nudge, an automatic health score, one-click publishing to a shared gallery that re-opens live, and the standardised weekly and monthly business-review deck.
Instead of everyone hand-building and hoarding dashboards, it's an app store — describe what you want, publish it, and the shelf warns you before you add the hundredth copy of the same thing.
AskedMake it possible to see what data even exists, query it without timeouts, understand how datasets relate and can be joined together, and see where each number came from and how fresh it is — right next to the number.
BuiltA browsable map of the data — every fact table (its size, freshness, and what it's broken down by) and all 29 metrics with their owner, source, version, and last-refreshed time. Click any metric and its full family tree and change-log appear live. We also added join discovery (it works out which datasets can be connected, without manual plumbing) and an auto-onboarding feed that surfaces newly added data.
A library catalogue — not the books themselves, but the index that tells you what's on the shelves, where each came from, how fresh it is, and which volumes belong together.
AskedA trustworthy place to run and read A/B tests (showing different versions to different users), with proper statistics, so teams stop declaring winners that aren't real.
BuiltAn end-to-end experiment reader that does the unglamorous-but-vital thing first: it checks whether the test was even set up fairly — whether users were actually split evenly. A great-looking result is worthless if the split was broken. Only then does it report the gain, the statistical confidence, whether an early bump is just novelty wearing off, and a clear Go / No-Go. It can also build audiences, design a new test from a plain-English description, and show the annual money impact.
A referee who checks the pitch is level before counting the goals — because a three-nil win on a tilted field doesn't count.
AskedLet anyone ask a question in plain English and get a trusted answer — with a chart, a download, the ability to set an alert or start an investigation, and export to spreadsheet or slides.
BuiltA conversational front door that recognises nine kinds of question and routes each to the right engine without needing a model to guess — a fast lane that returns in milliseconds with a receipt, slice-and-dice lanes, the full investigation lanes, and a "second-opinion" lane for open-ended questions. It remembers the conversation, returns findings in-line, and exports to spreadsheet, Excel, a real slide deck, or Google Sheets.
A knowledgeable front-desk clerk — you just ask; they know whether to grab the answer off the shelf, pull the ledger, or convene the experts, and they hand you the source every time.
The strategy also set time limits. The headline one — answer a question in under two seconds — we beat by a wide margin: the fast lane returns in roughly five milliseconds (thousandths of a second), because, as explained in requirement 2, the data is read straight from column-by-column files with no slow, row-by-row loop. The longer "thinking" questions are honest about taking time, and stream their reasoning as it arrives so it never feels stuck.
The strategy asked for trusted analytics. The genuinely distinctive work went beyond what it spelled out:
A companion to the Product Strategy. For the complete technical overview — gap analysis, features, the live demo, documentation, checklists and the plan of action — visit aina.dkube.app.