Services

A pilot built on a large language model takes about a week. Most pilots never reach production — and almost never because of the model. The model has nowhere to get context from, nobody in the company can say precisely what “active customer” means, and when the output is wrong there is nothing to tell you it is wrong.

So Cybrainia starts from that end. First name the decision the AI is meant to change. Then work out where the data for it comes from and how a good output is recognised. Choosing the model comes last, and it is usually the smallest decision in the project.

In practice: retrieval over data whose structure and meaning are described; a catalog and a semantic layer as the source of context instead of raw tables; evaluation running before the feature reaches users; and a cost cap, because otherwise the first invoice sets one for you.

Where the limit is: I do not train models. I build what goes around them and deploy existing ones. Designing an experiment or a model of your own needs somebody else, and I will say so straight away. And if nobody can answer “what happens when it is confidently wrong”, the feature is not ready to be designed yet — often the answer turns out to be a plain database query.

A warehouse is a company’s shared language. That is why the modelling decides the outcome, not the choice of tool — tools get replaced every few years, an agreed definition of grain outlives all of them.

Cybrainia builds warehouses in BigQuery in layers, each with one job. Raw is never rewritten. Staging cleans and types. The core carries business meaning. Marts are shaped for consumers and cheap to throw away. Transformations in dbt or in Dataform — chosen on what the client’s team can take over, not on which is better in general. Ingest in dlt, which lands data and does nothing else; schema changes that source systems make without telling anyone then break at the boundary rather than at four in the morning inside a transformation. Infrastructure in Terraform, the console for reading only.

Cost is a property of the design. An unpartitioned table is a decision to pay every time anyone touches it. I look at query cost the way I look at latency — as something the architecture is answerable for, not something finance discovers later.

Where the limit is: streaming. For fraud checks or operational alerting it is the right answer. For a report a human opens once a day it almost never is — it triples the operational surface for latency nobody uses. Before I agree to it I ask who reads the number and how fast they act on it. And my depth is on Google Cloud; I can find my way around AWS and Azure, but I will not pretend I know their sharp edges by feel.

Most companies spent the last few years getting data into a warehouse. They are now finding out that having the data is not the same as having its meaning — and that the meaning is spread across a semantic model in a BI tool, some SQL in the transformations, and three analysts.

While a human sat at the end clicking through a curated dashboard, this was survivable. It stops being survivable the moment a machine has to answer a question nobody prepared a path to. An agent gets a table called fct_subscription_events and has no way to know that “active customer” is a contested term that finance and marketing each define differently. So it guesses — fluently, and wrongly.

Cybrainia therefore keeps metric definitions as versioned text: measures, dimensions, grain, joins, and one plain sentence saying what the business means by it. In the warehouse repository, in code review, outside any proprietary format. A metric is compiled into SQL at query time; a second materialised copy of the truth drifts sooner or later, and then you have the original problem plus extra infrastructure. The catalog is generated from the models rather than typed in by hand — and it serves agents as a source of context, which is the first consumer that visibly breaks when a description is missing.

Where the limit is: this is where I am currently working, not a settled specialism — read it as a position I am actively testing. And there is no point building it over a warehouse nobody trusts. A semantic layer over models whose numbers are disputed only moves the dispute up one floor.

This is the oldest part of the work and people are surprised to find it next to warehouse architecture. They should not be: the collection layer decides whether building a warehouse above it makes sense. A nicely modelled warehouse fed by badly instrumented events is an expensive way to be confidently wrong.

Cybrainia treats GTM as the production deployment mechanism it actually is — a naming convention, a data layer somebody designed on purpose, versioning, and a change process. Without those it is a way to put code into production with no code review, and that is exactly how it behaves. With server-side GTM the browser sends one first-party event to a tag server, and fan-out, enrichment and consent enforcement happen there. Then GA4, the Measurement Protocol, the BigQuery export, and the modelling that has to follow it, because the export is not a warehouse.

Two things I repeat on every engagement. The data layer is an API: it has consumers, it has a contract, and changing it breaks things silently. And the real value of server-side tagging is not evading blockers but having one auditable place where you decide what leaves the company and to whom. Buy it for the first reason and a few months later you have the same mess, now running on Cloud Run.

Where the limit is: measure less, not more. Every event is a maintenance commitment, and the most valuable output of most engagements is the list of things that stopped being collected. Rebuilding tracking from scratch because GA4 is confusing usually just inherits the old bad habits and adds a tag server to them.