Correctness Is an Architecture, Not a Feature
Every BI and AI vendor claims accuracy. Most can't deliver it because correctness has to be built in, not bolted on. The three architectural commitments that separate Operations AI from everything else.
Correctness Is an Architecture, Not a Feature
Every analytics and AI vendor in marketing tech tells you their numbers are accurate. The accurate part isn't the claim. The accurate part is whether the architecture can deliver it. Most can't.
This page is for technical buyers, CTOs, and anyone trying to evaluate whether an Operations AI vendor (us included) actually has the substrate to claim correctness. It's also for our investors, who keep asking what's underneath. Written by Rick, who built it.
The short version: there are three architectural commitments that separate Operations AI infrastructure from everything else. None of them are decorations. All three have to be true from day one, because retrofitting them later means rebuilding the product.
Why "accurate" is the wrong word
Almost every marketing data vendor says they're accurate. Triple Whale, Northbeam, Whatagraph, Looker, Hex. The platforms themselves (Meta, Google, TikTok) say they're accurate. They can't all be right, because they report different numbers for the same campaigns.
The pattern is consistent. A vendor pulls data from upstream providers, applies some transformations, renders a number. The number is faithful to the input. The input was already wrong, because it was pre-aggregated by the platform with assumptions the vendor doesn't control.
"Accurate" in that frame means "we didn't introduce new errors." That's a low bar. The bar that matters: did the architecture prevent errors from being introduced upstream in the first place?
That's the difference between accuracy as a feature claim and correctness as an architectural property.
The three architectural commitments
Operations AI infrastructure requires three things to be true. They're not features. They're architectural decisions made at day one of the product that can't be added later without rebuilding.
1. Generative semantic infrastructure (numbers correct by construction)
The naive approach to combining provider data: pull pre-aggregated metrics from each platform's API, normalize date ranges, render in dashboards. This is what 95% of marketing analytics tools do.
The problem: pre-aggregated metrics are already wrong. Meta computes ROAS using its own attribution model. Google uses a different one. When you average their pre-aggregated ROAS values across timeframes or campaigns, you're averaging averages, with implicit assumptions about weighting that don't survive scrutiny.
Generative semantic infrastructure flips this:
- Pull source events, not pre-aggregated metrics. Raw conversion events, spend events, impression events.
- Normalize them into a shared semantic model. "Campaign" means the same thing whether the source is Meta, Google, or TikTok.
- Compute derived metrics (CTR, CPM, ROAS, MER, ROAS-by-cohort, etc.) from formula every single time. Never average a pre-averaged number.
- Make the formulas explicit and inspectable. The same formula produces the same number, anywhere it's used, with traceable inputs.
This is unglamorous engineering. It's also the difference between numbers that are correct by construction and numbers that look correct most of the time.
We call this layer "generative" because the metrics are generated on demand from source data, not stored and shipped from a cache. It's also why you can ask Nylo for "ROAS by audience cohort by week for Q1" and get a defensible answer, even if nobody pre-built that cut.
2. Agent reasoning over a domain model, not over provider APIs
The naive approach to AI in marketing: wire an LLM directly to provider APIs (Meta API, Google API, etc.) and let it reason over them. This is what most "AI marketing assistants" do today.
The problem: agents that reason over providers entangle the reasoning with the provider's data shape. When Meta changes its API (which it does, regularly), the agent breaks. When you add Pinterest, you retrain the agent for Pinterest's shape. The agent is married to the providers.
Domain-model reasoning flips this:
- Build a shared domain model (campaigns, audiences, KPIs, funnels, products, customers). Provider data feeds into the model after normalization.
- Agents reason over the model, not the providers. "Why did campaign X underperform?" gets answered by reasoning over the unified campaign model, not by reading Meta's campaign API directly.
- When you expand to a new provider, the model expands; the agent inherits the expansion. When you expand to a new vertical (pricing, inventory), the agent layer comes along.
This is why we use a Domain-Driven Design pattern under the hood. It separates concerns cleanly. The agents see business reality. The provider integrations are plumbing.
The practical consequence: when Meta breaks something next quarter, the agents don't notice. When you want to expand from marketing to pricing, the agent layer is reusable. Most vertical-AI tools rebuild from scratch in that scenario.
3. Execution-ready from day one
The naive approach to AI marketing tools: ship the analysis and recommendation, leave the action to humans in another tool (Meta Ads Manager, Google Ads, etc.). This is what most "AI-powered marketing" products do.
The problem: it sounds responsible. It actually creates a structural gap. The recommendation lives in one product. The action lives in another. Humans bridge the gap, slowly, manually, with friction.
Execution-ready architecture flips this:
- The integrations that pull data in are the same integrations that send decisions out. Reading Meta data and writing Meta budget adjustments share infrastructure.
- The system can take actions (with human sign-off, or auto-fire on pre-approved rules). It's not a separate workflow tool wired in months later.
- The decision and the action share the same domain model. Auditable, traceable, reversible.
The honest disclaimer: we roll out execution channel by channel. Today particularly strong in Google Ads budget pacing. More channels in coming months. Nobody honest claims everything is closed-loop on day one. But the architecture supports it on day one, which is the difference between a product that will have closed-loop in 12 months and a product that will need to be rebuilt to have closed-loop in 12 months.
Why these three together matter
Any one of these commitments is interesting. All three together is the category.
- Semantic correctness without agent reasoning: you have clean numbers, no help interpreting them. (BI tools, slightly upgraded.)
- Agent reasoning without semantic correctness: you have an articulate AI assistant making confident statements about wrong data. (Most "AI for marketing" products.)
- Both without execution: you have great analysis trapped inside a viewing tool. Decisions still happen elsewhere. (Most analytics tools.)
Operations AI is the convergence. All three architectural commitments, simultaneously, from day one. That convergence is what we mean when we say correctness is an architecture: the property emerges from how the system is built, not from after-the-fact validation.
This is also the defensibility argument for investors. Each commitment individually is hard to build. The three together create a moat because retrofitting any one of them into a system built without it means rebuilding the product. Companies whose architecture started with "AI on top of pre-aggregated data" can't add semantic infrastructure underneath without breaking their existing product.
How to evaluate vendors who claim Operations AI (including us)
If you're shopping for Operations AI infrastructure, here's the three-question diligence checklist:
- "Show me how you compute ROAS for a specific campaign across last quarter." A vendor with generative semantic infrastructure can show you the source events, the normalization, and the formula. A vendor without it shows you the dashboard.
- "How does your agent know what 'underperforming' means?" A vendor with domain-model reasoning can show you the business model the agent references. A vendor without it shows you a prompt.
- "Can the system take an action in Google Ads right now?" A vendor with execution-ready architecture can demo a budget adjustment with sign-off, end to end. A vendor without it tells you it's on the roadmap.
Three questions, fifteen minutes, you'll know whether the architecture is real.
We pass all three. Other vendors will too over the next 12-24 months as the category matures. The diligence questions stay relevant.
What we don't claim
Clarity matters here.
- We don't claim every channel is closed-loop today. Google Ads budget pacing is. More channels are rolling out.
- We don't claim semantic correctness solves attribution philosophy. ROAS reconciled against margin truth is still a model. The model is transparent and inspectable. That's the strongest honest claim.
- We don't claim agents are smarter than your best PM. They're more consistent than your average PM and more available than any of them. That's the value.
If any vendor claims more than this honestly, ask the three diligence questions.
Frequently asked questions
Is this just a fancier data warehouse? No. A data warehouse is storage and querying. Operations AI infrastructure includes semantic correctness, agent reasoning, and execution. The warehouse is one piece (mostly hidden) of the stack.
Does the architecture matter to my CMO? Indirectly. The CMO cares whether the ROAS number they're shown is defensible in a board meeting. The architecture is what makes it defensible. The CTO or technical buyer cares directly.
Why publish this? Doesn't it help competitors? Possibly. The architectural commitments are hard to retrofit, so the head start matters more than the secrecy. And if competitors do build to the same standard, the market for Operations AI grows, which helps us.
Is this patentable? Probably parts of it. We don't lead with patent-pending as defensibility. Patents are a checkbox. Architectural correctness is the moat.
What's the closest reference architecture to compare to? Stripe's approach to payments infrastructure is closest in spirit. They built correctness into the data model at the substrate, then everything else (API, dashboard, agent) inherits it. Our take is the same pattern applied to marketing decisions.
See the architecture in action
If you're evaluating Operations AI infrastructure and want to do real diligence on the architecture, a 30-minute call with Rick (our CTO) is the fastest path. He'll demo the three commitments live.
More on the category frame: What is Operations AI? | Operations AI vs Dashboards
Operations AI is the category we're building at Nylo. Marketing today, operations in every data-driven business area tomorrow. If you're a technical buyer or investor and want to push back on any of these architectural claims, we want to hear from you.