Evidence that the system computes what your business computes.
Most platforms help you build and leave correctness to manual testing. Tavuni treats the source you already trust as the answer key, checks against it value by value, and shows the effect of every change before it ships.
The formula engine, then the generated system.
Check 1 — the formula engine. Every formula is recalculated and compared with the value the workbook itself stored: 2,993 formulas, 2,992 exact, 0 different.
Check 2 — the generated system. The Business Graph is executed over the extracted records with every calculated field blanked first, so each value must be derived from the model alone: 2,870 values across 590 records, 2,869 matched, 0 different.
Rounding is reported, not hidden. A value sitting exactly on a rounding midpoint — where Excel’s 15-digit convention and IEEE-754 legitimately disagree — is shown on its own line (1 here), never folded into the pass rate.
- Values checked
- 2,870
- Matched
- 2,869
- Rounding edge
- 1
- Different
- 0
The generated system, run on 590 records with every calculated field blanked first, agrees with the workbook’s own stored results on 100.00% of values. The one value sitting exactly on a rounding midpoint is reported separately, never folded into the pass rate.
The check is not the product grading itself.
The reference values are the ones the spreadsheet application stored when the file was last saved. For the bundled example, those values were computed by a third-party Python formula engine — a different language, a different author, a different codebase. If Tavuni had produced its own expected numbers, a perfect score would prove nothing.
A workbook saved without stored results has no answer key. Tavuni then reports “not measurable” — deliberately different from 0% — rather than inventing one.
See the effect on real records before anyone publishes.
A change is a set of operations on the model. It is validated, applied to a copy, run against the records the business already has and shown as a diff with its impact — then it waits for a person.
In this example the proposal is produced by deterministic code (local-heuristic (rule-based-v1)); no language model is called.
- 1 · Request
Add a manager approval when order value exceeds $10,000.
- 2 · ProposalRequire Manager approval for orders over $10,000Assumptions it states, so a person can disagree:
- The threshold applies to Order.orderTotal (Order Total).
- Reusing the existing "Manager" role.
- The comparison is strictly greater than the threshold.
- 3 · Diff
- addedAdded rule "Orders over $10,000 need Manager approval": Order.orderTotal > 10000money or approvals
- addedAdded process "Order approval" with 4 stepsmoney or approvals
- 4 · Effect on real records89 of 120 Orders records (74.2%) would be affected.Combined order total of the affected records: $3,566,077.
- 5 · A person decidesThe assistant cannot publish. A person approves — and the change becomes version 2, with its author recorded — or discards it.
Verification is how Tavuni itself is built.
Over 3,000 backend tests
Run on both SQLite and PostgreSQL, because the same assertions on two engines find defects neither shows alone.
Browser tests on a production build
The suite drives a real browser against the production build and a real database, not a development server.
Versions and rollback
Every published model version is kept with its author, and configuration deployments can be rolled back.
Value-by-value verification applies where an independent reference exists — today, a spreadsheet’s stored results. For a model configured directly in the platform, Tavuni does not yet produce per-customer evidence that the approved requirements are met.
See it work on a real workbook, in your browser.
The example operations workbook opens in Tavuni with no account and nothing uploaded. Every number on this site comes from that same pipeline.