Build the thread. Then widen it.
A thread is the thinnest end-to-end slice of a system that proves the whole path works: one decision, wired from source data through the context layer, the model, the guardrail and into production, with monitoring on it. Deliberately narrow. Either it works, or it tells you something true about your data.
Most AI programmes do the opposite. They build width first — a platform, a strategy, a centre of excellence — and discover in month seven that the metric everything depends on was never agreed.
Fit call
30 minutesYou describe the decision you want to improve. We tell you whether AI is the right tool for it, and say so plainly when it is not. No deck.
Readiness Check
2 weeksA fixed-fee diagnostic. Where AI would pay, whether your data can carry it, what any existing AI would fail on, and a prioritised 90-day plan you own outright.
The first thread
3 to 6 weeksOne decision, wired end to end: source data, context layer, model, guardrail, production, monitoring. Deliberately narrow. It either works or it tells us something true.
Widen it
OngoingOnce the thread holds, the pod broadens it on 21-day cycles. Every cycle ends with something in production and a written readout. Thirty days notice, no exit fee.
AI & Data Readiness Check
An honest answer to two questions: where AI would actually pay in your business, and whether your data can carry it yet.
Two weeks, and you own the output
- Interviews with the people who use, and mistrust, the numbers
- A review of your pipelines, dbt project, semantic models and reporting
- Any AI already in the path, and the specific things it would fail on
- Your EU AI Act exposure, if you have any, in plain language
- A scored assessment across the five capability areas
- A prioritised 90-day plan, with the first working thread specified
Six things we hold to
These are commitments rather than values. Each one is checkable, and you should hold us to them.
One thread before any width
We build the narrowest end-to-end slice first and put it in production. A thin thing that works tells you more than a wide thing that is nearly finished.
Context before cleverness
Nothing goes in front of a model until the metrics it will read are defined, tested and documented. Most of what looks like a model problem is a definition problem.
Evals from the first commit
A golden set exists before the first prompt is tuned. Without it you are shipping on vibes and you will not notice the day it stops working.
The same names every sprint
You meet the people before you sign. They stay for the engagement. If someone has to change we tell you before it happens and the lead covers the gap.
Documentation as we go
Written continuously, not assembled in the last week. A pod you cannot leave is a pod you cannot trust, so we make leaving cheap on purpose.
We will tell you when to stop
If AI is the wrong tool, or the work is done, or the real problem is that two teams disagree about a definition, we say so. We would rather lose the retainer than bill you for motion.
What the fee covers
One monthly figure. No day-rate arithmetic, no change request for a conversation, and no charge for onboarding the person we chose to put on your account.
Included
- A named AI and analytics lead at 0.25 FTE, reviewing every model, prompt and eval
- Daily standups in your time zone, in your tools
- A written readout at the end of every 21-day cycle
- All code, models, prompts, evals and infrastructure yours outright
- Onboarding and handover included, not billed separately
- One monthly invoice, one point of contact, one contract
Not included
- Model inference, licences and cloud spend — those stay in your name and your account
- Out-of-hours production support, unless you want it as a separate line
- Anything we have told you we are not the right people for
Data protection, model choice and the boring practicalities
Where your data goes
Enterprise endpoints with no training on your data, inside your own cloud tenancy where the workload allows, with personal data pseudonymised or excluded before anything leaves your environment. If a use case cannot be built that way, we say so before you sign.
Which model
Whichever fits the job, and we will change it when a better one lands. Model choice is an implementation detail behind a good context layer and a good eval suite — which is exactly why we build those first.
Overlap and reporting
The team is in Bengaluru. Four hours of daily overlap with Central European Time, three with the UK. A written readout every 21 days: what shipped, what did not, what it cost, what we would do next. Short enough that you will read it.
The dimensional model is the guardrail
Agents do not hallucinate because they are told not to. They hallucinate because they are asked a question the data model cannot answer, and answering is easier than refusing. A conformed dimensional model closes that gap: there is one grain, one definition and one join path, so the agent selects rather than invents.
Facts, with declared grain
- fct_applicationone row per application attempt
- fct_loanone row per loan at issue
- fct_instalmentone row per scheduled instalment
- fct_paymentone row per received payment
- fct_contactone row per collections contact attempt
- fct_decision_logone row per automated decision, immutable
Conformed dimensions
- dim_date, with fiscal and cohort attributes
- dim_customer, with a stable surrogate key across systems
- dim_market and dim_product
- dim_channel, from UTM through to affiliate and broker
- dim_decision_rule, versioned
- dim_agent, for collections attribution
One grain per fact, declared
Every fact table states its grain in the model, and a test fails if it is ever violated. Fan-out on a join is the single most common source of a confidently wrong number, and it is the one an agent cannot see.
Metrics defined once, not per query
FPD 30 exists as one metric with its exclusions inside the definition. The agent asks for the metric. It never gets the chance to reconstruct it from a fact table and a guess.
Conformed dimensions across the estate
Market means the same thing in risk, collections and marketing. Without that, an agent comparing two domains produces a number that is arithmetically correct and analytically meaningless.
Slowly changing dimensions where policy changes
Decline rules and score cutoffs are versioned with valid-from dates, so the agent can answer what the policy was in March rather than what it is today. This is the difference between an explanation and a guess.
The model is the eval fixture
Because the grain and the definitions are declared, expected answers can be generated from the model itself. That is what makes a golden set maintainable rather than a snapshot that rots.
Refusal has somewhere to point
When a question falls outside the model, the agent can say which dimension is missing rather than improvising. A specific refusal is useful. A vague answer is not.
It works out the why before it interrupts you
An alert that says a number moved is noise. An alert that says which segment moved it, by how much, and what changed that day is a decision.
No step above is generative. The model writes the brief; the dimensional model decides what is true.
Everything people ask before signing
Are you just putting a chat box on top of our database?
No, and that is the thing we are usually hired to undo. Pointing a language model at a normalised warehouse produces confident, wrong answers, because the model has to guess your business logic from table names. The work is in the layer underneath: metrics defined once in dbt, documented in a way a model can read, and served to the assistant as tools rather than tables. The chat box is the last two percent.
We do not have dbt or a semantic layer yet. Are we too early?
You are not too early to talk, but you probably are too early to buy an AI assistant. That is what the Foundation and Context pods exist for, and it is what the Readiness Check is honest about. Building AI on top of pipelines nobody trusts just moves the mistrust somewhere more expensive.
How do you stop it hallucinating?
Three things, in order. Constrain what it can reach — it queries defined metrics through tools, not arbitrary SQL. Check the answer against the retrieved context before it is shown, so an unsupported claim fails rather than ships. And run an eval suite on every prompt, model or data change, with a golden set of real questions. Hallucination is not a prompt problem, it is a systems problem.
Does our data end up training somebody else’s model?
Not with the setups we build. We default to enterprise endpoints with no training on your data, run inside your own cloud tenancy where the workload allows, and pseudonymise or exclude personal data before anything leaves your environment. If a use case genuinely cannot be built that way, we say so before you sign, not afterwards.
Are we in scope for the EU AI Act?
Anything that materially affects a person — credit, employment, education, insurance pricing, access to essential services — is worth checking, because Annex III high-risk obligations started applying in August 2026. Plenty of AI is not in scope at all. Working out which of your systems are, and what evidence each one needs, is part of the Readiness Check and the whole point of the Guardrail Pod.
Can you work with Power BI Copilot and Fabric?
Yes, and a good share of the Copilot Pod is exactly this. Copilot is only as good as the semantic model behind it: synonyms, hierarchies, descriptions, verified answers, and row-level security that carries through. Most of the disappointment we are called in to fix is a model preparation problem, not a Copilot problem.
What if the honest answer is that AI is not the answer?
Then we say it, usually on the fit call and at the latest in the Readiness Check. A surprising share of the problems that arrive described as AI problems are a missing definition, a broken pipeline or an organisational disagreement about who owns a number. We would rather tell you that for a fixed fee than bill you for four months of building around it.
How is a pod different from hiring contractors?
Contractors arrive as individuals and you become their manager. A pod arrives as a team that has worked together, with its own lead, its own standards and one invoice. You brief the lead, not four people. If someone is unwell or leaves, the pod absorbs it — that is our problem, not yours.
Where is the team, and what are the hours?
Bengaluru, India. We keep four hours of daily overlap with Central European Time and three with the UK, and we join your ceremonies in your time zone rather than asking you to move them.
What happens if it is not working?
Thirty days notice, in writing, no exit fee and no clawback. Documentation, evals and infrastructure are written continuously and handed over as we go, precisely so leaving is cheap. A pod you cannot leave is a pod you cannot trust.
Start with the Readiness Check.
Two weeks, fixed fee, and you keep the plan whether or not you run a pod with us. It is the cheapest way to find out whether we are worth the bigger conversation.
Usually a reply the same working day · IST (UTC+5:30)