Anyone on your team can now produce a confident, chart-filled analysis in about thirty seconds. So can someone on another team. Same data, same AI assistant, different answers, and sometimes no obvious way to tell which one is right.

This is the new reality now that we're on year four of ChatGPT's introduction to the market. We see chatbots and new AI platforms showing up across the board, each making promises that sound vaguely similar.

The truth is that there's a time and place for each of them, from frontier models like Claude to the chatbots popping up throughout your tech stack.

What we want to do here is draw one line clearly: the difference between products built to help you talk to your data and what we do, which is decision intelligence.

The promise everyone is selling

Restaurant executives are hearing the same pitch in different words. Talk to your data. Ask your data a question. Chat with your POS. AI in the office suite, AI in the browser, AI bolted onto software you already pay for. Somewhere in your building, someone has already pointed a chat window at the data warehouse to see what happens.

Keep all of it. We mean that. We use Claude for administrative work every day at SignalFlare. Copilot makes moving through files in SharePoint faster. If a tool makes your people better at documents, email, and research, that's real value and you should take it.

But look closely at what "talk to your data" promises. The promise is access. And access assumes the only thing between you and a good decision is the awkwardness of turning a question into a data query.

That used to be the hard part. It isn't anymore.

A better model won't fix this

The natural response is to assume this is a timing problem. The models keep getting better. Wait a year and the gap closes on its own.

It doesn't, because the problem isn't in the model. Meaning lives outside it — in how your data is structured, what your terms actually mean in your business, which method applies to the decision you're making. No amount of model improvement reaches that layer, because none of it is written down anywhere the model can read.

The chat window also didn't get harder to build over the last four years. It got easier. Which means the interface you're being demoed isn't the thing you'd be buying, and the questions worth asking are all about what sits underneath it.

What your POS knows

Say you want to understand performance trends across your stores. You have options. Use the assistant built into your POS. Or load the data into a warehouse with an agentic AI feature and ask it there.

Your POS holds transaction data, which is a necessary ingredient towards utilizing AI to get the insights you want. The next ingredient is context. The AI doesn't know that Wagyu Burger v3 and Wagyu Burger v4 are the same item. It doesn't know which of your stores are comparable, or that the Dallas remodel closed the patio for six weeks, or what your team means when they say "traffic."

Without context, you can ask a chatbot to try to give you traffic trends with the data as is, but you won't get an answer. You will get a fluent guess, formatted like an answer. In order for the AI to accurately orchestrate choosing which columns to query, how to interpret them, and then how to reason over the results of the math, it must know your business, your industry, your data definitions, and what methodology to use per the decision you're working towards.

So while access is no longer the bottleneck, developing and maintaining derived meaning (aka context) from your data and knowledge very much is.

The complexity of context

Context isn't a document you write once and hand to a model. It's layered, and each layer takes work most brands haven't been resourced to do.

• Clean, structured data. Before meaning comes hygiene. Data arrives from your POS as nested JSON or normalized tables full of pointers, in whatever shape that vendor chose. It has to be extracted, flattened, and made queryable before anyone can ask it anything. Duplicate locations across five systems have to resolve to one store. Voids, comps, discounts, and zero-price modifiers have to be handled consistently or your product mix is quietly wrong. None of this is analysis. It's the floor under analysis, and it's where most internal AI projects die.

• Vocabulary. What is an item, a store, a daypart, a comparable location, a net sale. Sounds trivial until you find four definitions of check average living in three departments and one spreadsheet. This is what an ontology does: it's the agreed structure that says a check, a ticket, and a transaction are the same object, that this SKU and that SKU are the same menu item, that these forty locations are one brand. Without it, every question gets answered against whatever the system happened to guess.

• Relationship. A university location behaves nothing like an airport location. A store with three competitors inside a mile isn't the peer of one with none. Weather, seasonality, local events, trade area demographics — these change what a number means, and none of them live in your POS.

• Method. Knowing that sales dropped is not knowing why, and knowing why is not knowing what to do. Whether you should move price on an item depends on elasticity, and elasticity comes from a model that has to be built, validated, and re-validated against what actually happened.

What nobody puts in their marketing materials is that context decays. You launch an LTO. You remodel forty stores. You migrate POS systems and every item ID changes. Menus get rebuilt twice a year. Every one of those events quietly breaks the mapping underneath your reporting, and if nobody owns keeping it true, the answers drift while looking exactly as confident as they did before.

That's the work. It's slow, it's unglamorous, and it's the reason most AI pilots stall at the demo.

Most of the work happens outside the AI

There's a common misconception that a good enough model makes the rest of this unnecessary.

When you ask Navigator a question, the question doesn't go straight to a language model. It gets classified first: what kind of question is this, and what should answer it. Some things have to come out the same way every time you ask — a revenue figure, an elasticity, a forecast. Those go to code and to statistical models fitted on your data.

So we have to use large language models (LLMs) for what they're good at: language. Interpretation, synthesis, and explanation are all great use cases for LLMs, not arithmetic.

The routing system that we've built is the difference between a system you can defend and one that can confidently cost you millions. In most agentic products, a language model sits on top as both the interface and the decision-maker, which puts the one component capable of making things up in charge of deciding when accuracy matters.

Behind the routing sits everything that isn't AI at all: ingestion pipelines running daily, transformations, validation checks, entity resolution, mapping to the ontology, models being refit as new data lands, monitoring for when something upstream breaks. Our engineering team spends far more time on that than on anything model-related. The AI is the last mile.

(For the architectural version of this argument — routing, governance, and why the substrate is the product — see Mike Lukianoff's "It's Time for Decision Intelligence.")

From data to decision intelligence

This is all prerequisite work that somebody has to do, and there's no way to skip it.

Mapping your data into a model of how restaurant data behaves. Agreeing on definitions. Testing methodologies against what actually happened. That work is what we sell.

We call it decision intelligence: your data, advanced analytics, AI, and human judgment in one place, pointed at a specific decision.

So when Navigator tells you how demand will respond to a price move, that number comes from a statistical model running on your validated data. It's computed, not generated. No language model is guessing at it.

ROI

A tool that helps you talk to your data is a helper. When it's wrong or expensive, that's your problem. Connect an agent to a warehouse, let it write its own queries, and eventually one runaway job produces a five-figure compute bill for the month. Nobody did anything wrong, exactly. That's what it means to be the accountable party in a system where the tool is only a helper.

This is where the investment in context pays off. Every hour spent structuring data is an hour nobody spends again — once the system knows what a comparable store is, it knows for every question after that. Nothing has to go exploring to rediscover what your team already knows, and the expensive part of AI is the exploring.

Your usage still varies, and our credit system reflects that. What doesn't happen is the runaway, because the paths a question can take are defined in advance. Variable, but bounded.

The real return isn't measured in compute anyway. [Real example with a dollar figure.] Your team still makes every decision. Our job is making those decisions defensible, because nobody wants to stand in a boardroom and say the pricing came from a chatbot.

What starting right looks like

Most restaurant AI projects start as a pilot on top of raw data and quietly stall. Nothing to trust, no methodology, and six months later, no decision anyone can point to and say AI made that one better.

Start from the other end. Start with the decisions. Your data gets standardized first. The metrics come from tested models. The recommendations come from methodologies that have been run across dozens of brands. You begin with a few curated experiences and our people working alongside your team, and the platform earns more responsibility over time. Every decision gets logged with its outcome, so the next one starts smarter than the last.

So keep the tools that make your people faster. Use them for everything they're good at.

But when the answer has to be true about your business, with real money riding on it, talking to your data isn't the job. The job is being able to defend the number. That's decision intelligence, and it's the only thing we do.