AI and machine learning
You end up with business users asking questions in plain language and getting answers that are right — because the model queries a governed set of metric definitions instead of guessing at your raw tables.
A senior engineer reads it and replies within one business day. Or write to emilio@lyticaconsulting.com.
- Week one
- One question worth answering, and the metrics around it, chosen
- Inside a month
- You are asking it real questions and trying to break it
- From there
- Coverage widens one business area at a time, each metric with a test
The problem this solves
A demo where someone types a question and a chart appears takes an afternoon. Putting that in front of a CFO takes a governed definition of every metric it can reach, because the failure mode is not an error message. It is a confident, wrong number that nobody in the room can challenge.
Language models are good at writing SQL and bad at knowing what your business means by "active customer". That is not a model problem, and a better model will not fix it. It is a definition problem, which is why we build the semantic layer first and the chat interface second.
A business user asks a question. The answer has to be right.
Which enterprise accounts churned within 90 days of a price increase last quarter?
select a.account_name,
p.effective_date as price_change,
c.churned_at
from dim_account a
join fct_price_change p using (account_id)
join fct_churn_event c using (account_id)
where a.segment = 'enterprise'
and p.effective_date >= date_trunc('quarter', now())
- interval '3 months'
and p.effective_date < date_trunc('quarter', now())
and c.churned_at <= p.effective_date + interval '90 days'
order by c.churned_at;That query is dull, and that is the point. It runs against tables we designed, where enterprise, churned, and price increase each have one definition the business has already agreed to.
Without that layer underneath, a language model writes something plausible against raw tables and nobody in the room can tell whether it is wrong. Conversational analytics is a semantic-layer problem before it is an AI problem, which is why we build the layer first and the chat second.
What we build
Artifacts you own, not activities we perform.
- Conversational analytics
- A question interface over a semantic layer where every metric has one tested definition. The model composes answers from defined metrics; it does not invent SQL against raw tables.
- Agentic workflows
- Agents that do real work inside your systems — run a process, prepare a report, open and route a ticket — with the boundaries of what they may touch written down.
- Coding agents grounded in your codebase
- Agents that know your repository layout, your standards, and your deployment path, so what they produce reads like your code and not like a generic sample.
- Internal AI infrastructure
- Somewhere your staff can use models against company data without that data leaving your tenant, with access control, audit logging, and retention you set.
- Predictive models
- Forecasting, classification, and scoring, deployed as a service and monitored for drift, so you find out when a model stops working before the business does.
A senior engineer reads it and replies within one business day. Or write to emilio@lyticaconsulting.com.
How the engagement runs
You should be able to picture week one before you sign anything.
Week one
Where we start
We pick one question worth answering and the handful of metrics around it. Narrow on purpose — the failure mode of these projects is a system that answers anything, badly.
The first weeks
The first thing that runs
Metrics get defined and tested first, then the interface goes on top. You will be asking it real questions inside the first month, and trying to break it, which is exactly what we want.
From there
The cadence
Coverage widens one business area at a time. Every new metric arrives with a test, so the set of questions it can answer correctly only ever grows.
What we need, and what you get
What we need from you
- Agreement on what your core metrics mean. If two people give different answers, that is the first thing we fix.
- A business user willing to try to break it every week and tell us where it was wrong.
- Clarity on what data models are allowed to see, in writing, before we connect anything.
What you get from us
- A definition layer you own, which stays useful even if you later replace the interface on top of it.
- Honest scoping about what a model can and cannot answer reliably.
- Evaluation you can run yourself, so "is it still right?" is a question with an answer.
Related
Tell us what you are trying to build
Describe the situation in your own words. A senior engineer reads it and replies, usually with questions rather than a brochure.
Or write to emilio@lyticaconsulting.com