Skip to main content
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:
  1. Tables referenced by cited SQL exist.
  2. Distinct inexpensive SQL queries rerun to the same rows.
  3. Numbers in the answer appear in summaries, outputs, or result cells.
  4. SUM, AVG, or TOTAL is not applied suspiciously to text.
  5. Exact-case filters do not overlook known mixed-case labels.
  6. The SQL aggregate matches aggregate wording in the question.
  7. A meaningful column named in the question was not dropped from the SQL.
  8. A likely shared-column join was not missed.
  9. Date grouping did not produce a NULL bucket.
  10. Values from a multi-aggregate row are labelled with the correct result column.
These checks are fixed Rust functions over the question, answer, catalog, and evidence. The dispatch is explicit and ordered:

Flow

  1. The model returns an answer with no more tool calls.
  2. The harness runs the deterministic verifier.
  3. 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.
  4. 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=0 disables it).
  5. If any deterministic warning remains, the default-on self-check may make one stricter, tool-free model call from existing results (FELLA_SELF_CHECK=0 disables it).
  6. 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.
For high-stakes use, inspect the query, rows, and source data yourself.

Test the failure shape, not just the happy path

Verifier tests construct a small EvidenceItem without starting the app:
The real regression came from a ledger whose dates were written as 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.