Deterministic by design

The single most important thing to understand about Ronja if you’ve been burned by AI tools that confidently state wrong numbers: Ronja never lets the model author a number.

The guarantee — numbers are computed, never generated

When you ask Ronja a quantitative question, the language model’s job is to write text: a DuckDB SQL query or a Python program. That text is handed to a real compute engine, executed, and the result returned to you is the engine’s actual output. There is no path in the system where the model supplies the numeric answer directly.

Concretely: the agent’s query tool takes the SQL the agent wrote, runs it on DuckDB, and returns the engine’s real output — the actual rows the query produced. Its Python tool does the same: the result you see is taken verbatim from what the code evaluated to, not from anything the model asserted. The prompt even tells the agent that the query result is rendered to you directly, and to summarize the numbers rather than restate them — so the model is deliberately kept out of the answer-authoring path.

Every one of those executions is recorded. A run is written as an exec_runs telemetry record: a row is created before execution and stamped when it finishes, carrying query, AI-call, and token counters that are bumped from the running container’s own calls — the real work it did, not a number the model claimed. Because the query and the run are both recorded, every result is reproducible from the exact query that produced it.

This is the core difference from a chatbot that guesses figures. Ronja’s numbers come out of an engine you could re-run yourself, and the trail to reproduce them is recorded.

The honest limit — correct execution isn’t correct interpretation

Here is the part that matters for trust, and that a serious evaluator will test: a query can execute perfectly and still answer the wrong question. The engine runs exactly what it was given — but the agent can pick the wrong column, the wrong filter, or the wrong interpretation of what you asked. Determinism guarantees the number is real; it does not guarantee the meaning is what you intended.

A real example. Analyzing a customer’s data, Ronja initially reached for a country column to break results out by geography — but that column didn’t exist; the geography lived in a column called market. It caught this by inspecting the schema before writing the query, and corrected. That’s the failure mode, and it’s genuine: this risk is mitigated, not eliminated.

How Ronja reduces interpretation risk

Ronja doesn’t claim the interpretation problem away — it puts guardrails around it and makes the residual risk auditable rather than hidden:

• Mandatory schema inspection. Before writing SQL, the agent has tools to see a table’s real columns, types, statistics, and most-frequent values — and it’s instructed to use them. The rule is explicit: verify that a table actually contains what you asked about before querying it.
• An explicit “list_price is not revenue” rule. The prompts name this exact class of mistake — a column whose name sounds like the thing you want but isn’t. The agent is told not to silently substitute a plausible-looking column for the real one.
• A plan or methodology gate before it computes. In Build mode, the agent writes a plan and waits for your go-ahead before creating anything. In Deep analysis, it pre-registers the question, its hypotheses, and its confirm-or-refute criteria — naming which tables and columns it will use — before it sees the numbers, so the analysis can’t drift into rationalizing whatever the data happened to show. In that mode, a well-justified “we can’t reliably answer this with the data” is treated as a success; manufacturing a confident answer the data can’t support is the one real failure.
• End-to-end traces. Every execution links to a full trace — the tree of steps, with per-step status, timing, and the SQL that ran against which tables. So you can see exactly which query produced any number, and check whether the interpretation behind it was right.

The plan and methodology gates are covered in Standard, Deep analysis, and Build; traces are covered in Monitor runs and traces.

The right mental model

Think of Ronja not as an oracle that emits truth, but as a sharp analyst colleague who shows their work and can be checked. The arithmetic is always real — computed by an engine, recorded, reproducible. The judgment about which arithmetic to do is subject to the same review any good analyst’s would be, and Ronja is built to make that review easy: it inspects the schema first, states its plan before it computes, and leaves a trace behind every number.

That honesty is the point. A promise that the model simply never makes mistakes collapses the first time an evaluator finds a misread column. “The numbers are computed and reproducible, and the interpretation is guardrailed and auditable” is a claim that holds up — which is exactly why it’s the one worth making.