Academy
3. Why Code Beats Guessing: The Reliability Argument
Explain why having arithmetic performed by generated code on real rows — with a verification step comparing the summary to computed data — is more reliable than letting a language model approximate.
When you ask a language model to read a table of 10,000 rows and give you a total, it does not actually add the numbers. It predicts what the answer probably looks like — it approximates. That is fine for writing a paragraph, but dangerous for arithmetic. OUPI takes a different path: your natural-language question is translated into real code (Python or SQL), and that code runs on every row of your actual dataset inside an isolated sandbox. The number you get back is computed, not guessed. This is the core reliability argument: arithmetic performed by code on real data will always beat a language model's statistical approximation.
Code alone is not enough — the answer you read is a plain-language summary written by the model after the computation. A model could still misquote a figure when translating a result table into a sentence. OUPI adds a verification step: every number that appears in the summary is compared back to the computed data. If a figure in the text does not match the result table, the platform flags the mismatch with a warning. This means a wrong number cannot slip into the final answer unnoticed. You get the readability of natural language with the precision of a spreadsheet formula.
So what can still go wrong? Interpretation. The model may misunderstand which column you mean by 'revenue' or which date range 'last quarter' covers. That is why OUPI keeps the generated code and the full result table visible alongside the summary. You can inspect exactly what was computed and how. If the interpretation was off, you refine your question — name the column as it appears in your data, specify the period and grouping explicitly — and re-ask. The reliability chain is: code does the math → verification checks the summary → you check the interpretation.
To reduce interpretation errors, phrase your question the way your data is structured: use exact column names, state the period ('Q2 2025'), the grouping ('by region'), and ask one thing at a time. If a column name is ambiguous, the engine will state its assumption — correct it and re-ask.
Before any code runs, it passes through a security check: the generated code is inspected for suspicious patterns, blocked from accessing the network or file system, and executed in a sandbox. Your question itself is screened for prompt-manipulation attempts. Your data never leaves the platform during this process. This means the reliability guarantee is not just about accuracy — it also ensures that the code running on your rows is safe and contained.
Save queries you trust so you can re-run them on refreshed data later without re-validating the logic each time. Share them with your team to standardise how key metrics are computed across the organisation.
Open OUPI Data, pick a dataset you know well, and ask a question whose answer you can verify manually (e.g. 'how many rows have region = Europe?'). Check the summary number against the result table and the generated code. Notice how the three match — that is the verification chain in action.
Language models approximate; code computes. OUPI converts your question into real code, runs it on every row in a secure sandbox, writes a human-readable summary, then verifies every number in that summary against the computed result. Mismatches are flagged automatically. The only subjective step — how your question was interpreted — is made transparent through the visible code and result table. This three-layer chain (code → verification → transparency) is what makes natural-language queries on your data reliable, not just convenient.