Verification ties an answer to recorded work; it does not make the model a trusted grader.
Definition
Evidence is the record of tool execution. Verification is the post-answer process that compares the response with that evidence and checks several common SQL mistakes. The primary verification pass is deterministic, local application code. It does not call a model. Model re-asks are separate, conditional behavior owned by the harness. The public stages have different guarantees:Architecture
The deterministic verifier runs these checks in order:- Tables referenced by cited SQL exist.
- Distinct inexpensive SQL queries rerun to the same rows.
- Numbers in the answer appear in summaries, outputs, or result cells.
SUM,AVG, orTOTALis not applied suspiciously to text.- Exact-case filters do not overlook known mixed-case labels.
- The SQL aggregate matches aggregate wording in the question.
- A meaningful column named in the question was not dropped from the SQL.
- A likely shared-column join was not missed.
- Date grouping did not produce a
NULLbucket. - Values from a multi-aggregate row are labelled with the correct result column.
Flow
- The model returns an answer with no more tool calls.
- The harness runs the deterministic verifier.
- Queries that originally took more than 500 ms or returned truncated rows are not rerun; the first result is retained with a check explaining the skip.
- If a rerun now fails or changes, the default-on corrective path may make one tool-free model call to reconcile the answer (
FELLA_VERIFY_REASK=0disables it). - If any deterministic warning remains, the default-on self-check may make one stricter, tool-free model call from existing results (
FELLA_SELF_CHECK=0disables it). - The second answer is compared numerically with the first. A disagreement becomes another visible check; it does not replace deterministic verification.
Behavior
Evidence can include a stable per-answer ID, tool names and arguments, SQL-backed source mappings, plain-language notes, SQL and returned rows, document or Python output, chart data, timings, and errors. The answer also records the workspace revision it started against and one typed status:verified, needs_review, insufficient_data, or failed. A make_chart item includes the guarded SQL query and its result rows alongside the derived chart, so the visual does not introduce a second untracked numeric source. Partial evidence remains available if a run is stopped or a provider fails after tools have run.
Not every warning is a hard failure. Text aggregation, possible case sensitivity, or a likely missed join are conservative prompts to inspect the work. A changed rerun, failed rerun, unsupported figure, mislabelled aggregate, or disagreeing second answer is a stronger signal.
Limits
- Numeric grounding uses tolerant number matching. It is useful but cannot prove a derived percentage or narrative interpretation is correct in every form.
- A successful rerun proves repeatability at that moment, not source completeness or truth.
- Heuristic SQL checks can produce warnings on valid queries and miss semantic mistakes.
- Python output can support number grounding, but the verifier does not independently rerun arbitrary Python programs.
- A model second opinion costs another provider request and remains model output, not deterministic validation.
Test the failure shape, not just the happy path
Verifier tests construct a smallEvidenceItem without starting the app:
Aug 1, 2026. SQLite’s date functions returned NULL, collapsed several months into one bucket, and still produced a plausible total. PR #107 fixed named-month normalization at ingest; commit e51d981 added the multi-aggregate value-label check after a separate live failure. Tests for both keep those cases from disappearing into a generic “numbers matched” pass.
Next steps
Read the evidence
Follow files, queries, outputs, and checks in the product.
The analytics engine
See where deterministic query results come from.
Built-in tools
Review what is and is not independently rerunnable.