Statutory tax engine · India · AY 2026-27
Welcome to CLAVIS,
your tax optimisation engine.
Both regimes computed in full, every figure traced to the section it came from, and the marginal-rate traps surfaced before they cost your client money.
Most tax software answers “what is the tax?” with a chain of conditionals over a rate table. That is enough to be right most of the time, and it is why a spreadsheet gets so far. CLAVIS is built for the cases where being right most of the time is the problem: the phase-out bands, the marginal-relief cliffs, and the years where a Finance Act changed one number and every downstream figure moved with it.
Read from the running engine, just now
Sign in to read these live from the engine.
These figures come from the engine itself rather than this page, so they are only shown to a signed-in session.
Seven differences that matter
Both regimes are computed in full
- The usual approach
- Pick a regime with a rule of thumb, or compute one and estimate the other.
- CLAVIS
- Both are computed completely, on the same facts, and the recommendation is the comparison — not a heuristic that happens to usually agree with it.
Where to check it: The computation page shows both totals side by side with their own gross, deductions and taxable income.
Invariants are proved, not spot-checked
- The usual approach
- Unit tests over example returns. They catch what someone thought to write a test for.
- CLAVIS
- An SMT solver (Z3) proves properties hold for every input in a range, not for the examples someone chose.
Where to check it: The 'Z3 verified' badge on the computation, and tests/test_solvers.py.
A skipped check is never shown as a passed one
- The usual approach
- A green tick that means 'nothing went wrong', which also covers 'nothing ran'.
- CLAVIS
- Verification is tri-state. If a check did not run it says 'not checked', with a distinct glyph — because an absence of evidence is not evidence of correctness.
Where to check it: VerificationBadge in components/ui.tsx; the states stay distinct in greyscale.
A second implementation checks the first
- The usual approach
- One codebase computes the number. If it is wrong, it is confidently wrong.
- CLAVIS
- An independent clean-room implementation recomputes the winning regime and must agree to the paisa. Disagreement is surfaced, not swallowed.
Where to check it: The 'Clean-room verified' badge reports the delta in paisa.
Marginal rates are measured, not derived
- The usual approach
- Report the slab rate — so a taxpayer inside a phase-out band is told '15%' when the real cost of the next rupee is over 100%.
- CLAVIS
- The engine is re-run with more income and the difference is observed. The chart is measured points, with no interpolation between them.
Where to check it: The marginal chart states its method and its point count on the card itself.
Statutory parameters live with the rule
- The usual approach
- Thresholds hard-coded across the codebase, so a Finance Act change means hunting for every literal.
- CLAVIS
- Parameters are versioned alongside the rule that uses them, per assessment year. A rate change edits data, not Python.
Where to check it: rules/india/it_act_1961/, and LdslRule.int_param() in models/ldsl_rule.py.
Money is integer paisa, end to end
- The usual approach
- Floating-point rupees, which drift by a paisa and then disagree with the department's own arithmetic.
- CLAVIS
- Integer paisa throughout, with statutory rounding applied where the Act says to (SS.288A/288B) and nowhere else.
Where to check it: lib/money.ts brands the units so a rupee value cannot be passed where paisa is expected.
Built to be operated, not just demoed
The parts that only matter once real client data is in it
- Tenancy from day oneOne firm cannot read another firm's clients. The tenant comes from a signed token claim, never a header a client could set.
- Provenance per fieldEvery figure is extracted, derived, or missing — and says which, with the document it came from.
- Property and fuzz testingGenerated inputs and malformed documents, not just the happy path.
- Differential oracle testingTwo implementations compared across generated profiles, so disagreement is found before a client finds it.
- Print is a first-class outputBecause the delivery mechanism is a CA handing a document to a client — cards never split across a page break.
- Accessibility as a constraintNo status is encoded in colour alone; the >100% trap band is a hatch pattern, so it survives greyscale and colour deficiency.
What it does not do
CLAVIS states facts about statutory instruments and computes their tax effect exactly. It does not rank instruments by expected return, assess whether one suits a client’s circumstances, or offer investment advice — those are regulated activities and a different job. Where it reports a saving, it shows the outlay required beside it, because a saving quoted without its cost is the most misleading thing a screen like this could do.