Imagine asking your AI analytics assistant:
“How much revenue did we make last month?”
It generates SQL, runs the query, and confidently reports $100,000. Your finance team’s report says $80,000. The difference? For this report, finance excludes canceled orders and subtracts refunds. The model did neither.
Nothing crashed. The query executed successfully. You just got a convincing answer that overstated revenue by $20,000.
The model knew how to add up orders. It didn’t know what your business counts as revenue.
Why a bigger model doesn’t solve the whole problem
A powerful general-purpose model might write sophisticated SQL, but it still needs to know which calculation you’re asking for. “Revenue” could mean total order value, sales after refunds, or something else defined by your reporting team. Those interpretations require different queries.
Your database doesn’t necessarily make the answer obvious. Refunds might live in a separate table. An order might appear multiple times as its status changes. Several columns might contain amounts that look relevant but represent different things.
Without that context, the model has to choose an interpretation. Sometimes it chooses correctly. Other times, it produces a perfectly reasonable guess to how it assumes things are done. Assumptions are bad.
With this approach, expect many angry stakeholders and lots of wrong answers.
Give it the knowledge your analysts already use
The next step is to add a knowledge harness that retrieves the relevant company documentation before the model writes SQL.
Start with schema metadata. Explain what each table contains, what its columns mean, how tables connect, and what one row represents. For the revenue question, this tells the model where orders and refunds live and how to relate them without counting the same sale twice.
Then supply canonical metric definitions. These should state the approved calculation, including exclusions, reporting dates, and other business rules. Instead of asking the model to interpret “revenue,” you give it the definition your finance team actually uses.
Finally, provide historical SQL that has been reviewed for correctness. These examples show how the documented rules translate into working queries against your database.
The assistant now has much of the information an analyst would consult. It no longer needs to invent a definition or infer every relationship from column names.
Run the same benchmark again with the model unchanged. Look for mistakes the added context resolves, then inspect the remaining failures. You should see significant improvement already.
Use a specialized model to apply that knowledge more reliably
The harness addresses missing knowledge. It doesn’t guarantee correct execution of that knowledge.
Suppose the model now knows it must subtract refunds. If an order has multiple refunds, joining the order directly to each refund can repeat the original sale amount. The model has followed the instruction to include refunds, but introduced a different error in the calculation.
You can add a model specialized on your company’s analytics workload. Fine-tune it on business questions, the context supplied by the harness, and analyst-verified SQL. Include reviewed corrections that demonstrate how to avoid recurring mistakes.
For the revenue example, training examples can show when to aggregate refunds by order before joining them to sales. Vary the questions across dates, customer segments, and reporting breakdowns so the training reinforces the underlying calculation rather than one fixed query.
Why this adds something beyond better prompting
The future is AI built for you
A harness tells the model what your business means by revenue. Specialization helps it turn that definition into the right calculation, even when the question changes. You need both: up-to-date business knowledge and a model trained to apply it.
That’s the approach behind Marc1: specialized models paired with the context you already rely on. The harness supplies the knowledge, the model is primed to use it.
We believe that’s where the industry is headed. Asking questions and getting answers is useful, but the real value comes when you can make decisions based on the answers that actually understand you and your business.