You own the semantic layer.
Ward is not building a second one.
Your warehouse stays the system of record and your metric definitions stay the definitions. Ward reads what you already publish, cites the SQL under every number it reports, and takes the ad-hoc queue off your team.
Read-only service account, locked to SELECT on schemas you name. Federated query, no copy of your data.
Nothing you run gets replaced.
The three tools this question always comes up about. In each case the longer column is the one describing what stays yours, which is the point.
Power BI
Your reporting layer- Every report, dataset and workspace, untouched
- Your DAX measures stay the definition of record
- Fabric capacity planning is unchanged
- Row-level security still governs who sees what
Reads the same warehouse your semantic model sits on. It publishes no competing measures and writes nothing into your datasets.
Looker
Your semantic layer- LookML remains the single definition of every metric
- Explores, dashboards and schedules run as they do now
- Your Git-based LookML review process is unchanged
- Ward does not fork or shadow your model
Queries the underlying tables, not your Explores, so there is no second semantic layer to keep in step. Where a metric is defined in LookML, that definition wins.
Snowflake
Your warehouse- The warehouse stays the system of record
- Your roles, grants and masking policies govern access
- No ETL into a Ward-side database, no shadow lake
- Warehouse sizing and credit governance stay with you
Runs federated queries in place against a service account you issue, locked to SELECT on the schemas you name. Nothing is copied, so your residency position does not change.
Three things your team will audit, and where to find each.
A number nobody can reproduce is a rumour. Everything Ward reports is designed to be checked by someone who does not trust it.
Every number is one click from the query that produced it
Not a description of the query. The query, the source tables, the parameters, and the run timestamp. Any figure Ward reports can be re-derived independently by your team, in your warehouse, without us. A number nobody can reproduce is a rumour.
Every forecast says which model produced it
Forecasts run on ARIMA, Holt-Winters, Bayesian hierarchical and gradient-boosted residuals, never on the language model. Each carries a model card naming the method, the training window, the parameters, and the features. The LLM frames results it did not compute and does not generate figures.
Every forecast ships with its own error rate attached
Backtested over 24 months, with the mean absolute percentage error stated on the card rather than in a footnote. A forecast without a published error rate is an opinion, and your team is entitled to see how wrong ours has been before acting on it.
The part of the job that stops your analysts doing analysis.
Forrester puts median ad-hoc turnaround at large retailers above six days. The cost is not the six days. It is the questions nobody bothers to ask because of them.
The questions that never needed you
"Which stores are down on fill rate this week and why." Ward answers it in plain English against the warehouse, cites the SQL, and names the source tables. Nobody opens a ticket, and nobody waits for you to close one.
The questions that did need you, arriving better formed
When someone does escalate, they arrive with the query that was already run, the tables it hit, and the number they are disputing. You debug an artifact instead of reconstructing a conversation.
The recurring ones stop recurring
A question asked three times becomes a playbook with a trigger and a close condition. It stops being a request and starts being a procedure that runs itself, so the queue does not refill behind you.
What does not come off your plate
Modelling, warehouse cost, data quality upstream, and the definition of every metric. Those stay yours, and Ward is a consumer of them rather than a second source of truth. If your fill-rate definition is wrong, Ward is confidently wrong with it.
What it takes from your team, and what it costs.
Issuing a service account and naming schemas is most of week one, measured in hours. The policy review in weeks three to five is a pull request against a set we draft first.
-
48 hoursFirst insight cards
From a read-only connection. Findings on your own data, not a sandbox and not a slide.
-
Week 2Findings ranked by dollars
Stores, SKUs and vendors ranked by what they cost you, with the cause named and the SQL one click under every number.
-
Week 6First gated write
One playbook, one system of record, blocked on an approver role you named. Everything before this is read-only.
-
Day 90The number, either way
Measured KPI delta against the metric agreed on day one. If it did not move, the pilot ends.
Tier follows stack complexity: how many systems have to talk to each other, how many brands you run, and how custom your schema is. Not headcount, and not revenue.
- Month-to-month, 30 days notice
- No rollover clause
- Every tier is the full platform
If someone is going to ask you to compare anyway.
Three honest comparisons, each ending in what the other tool is genuinely better at. Read them knowing nothing above changes.
Written for the person who owns the warehouse.
Longer arguments than a product page can carry, including the objection at the top of this one.
Security and finance objections are answerable with documents. The one that kills the deal comes from whoever owns the warehouse, is rarely said out loud, and is usually correct. How a competing metric definition gets built by accident, and the structural fix.
8 min read →Your questionnaire was written for software that stores data and shows it back. An agent asks for the ability to act on your systems of record. Six questions that cover the difference, in the order the answers matter.
9 min read →Ninety days later nobody can say whether it worked, because nobody agreed a number in advance. The four things to fix before a single system is connected, and the sentence a vendor should be willing to put in writing.
8 min read →What data leaders ask, including the awkward one.
No, and this is the objection worth pressing hardest. Ward queries the underlying tables rather than your Explores or datasets, and it publishes no competing metric definitions. Where a metric is defined in LookML or DAX, that definition is the one Ward is pointed at. There is no Ward-side model to reconcile at quarter end.
Federated read queries on a schedule you control, against a service account you issue and can throttle or revoke. Query patterns and frequency are visible to you in your own warehouse monitoring from the first day, because they run as your service account, not through an opaque connector.
Then Ward will be wrong in the same places your dashboards already are, and it will say which table it read to get there. It does not fix upstream quality and does not claim to. In practice the SQL lineage tends to surface quality problems faster than dashboards do, because a wrong number arrives with the query attached.
It replaces the ad-hoc queue, which is the part of the job that stops analysts doing analysis. Modelling, definitions, warehouse architecture and data quality all stay with your team. If a headcount argument is being made in your organisation using this tool, we would rather you heard that from us now than found out at renewal.
You do, as code. Cedar policies and agent charters live in your Git repository and change by pull request through the review process you already run. Narrowing an agent or changing an approver role is a merge, and it rolls back the way the rest of your code does.
It is yours, logged, and exportable. Every query Ward runs is in the audit stream that goes to your SIEM, so you can review what it asked, how often, and against which tables, without taking our word for any of it.
Put it in front of your own warehouse.
Read-only service account, schemas you name, and every query visible in your own monitoring from day one.
Read-only to start · your LLM keys · SOC 2 Type II underway · or book a call directly
Find out what your data has been hiding.
Tell us about your operation. We’ll show you the problems Ward catches, and the ones your current tools miss.