Tax Compliance AI Verification

Your tax AI doesn't have an accuracy problem. It has a verification problem.

StatuteGuard is a vendor-neutral layer that proves AI-drafted tax positions against the encoded statute, deterministically. Paste a position from any platform and it returns a hard PASS, BLOCK, or NEEDS-REVIEW with a statutory citation chain and a filable IRC §6662 audit record. Agent advises, code decides.

71.4%

Deterministic coverage

42-case labeled golden set

100%

Gate precision, 0 false blocks

42-case labeled golden set

20%

IRC §6662 accuracy penalty

Lands on the human who signed

A runnable demo, not a deployment. All positions are synthetic; the statutory logic is grounded in primary law. Not tax or legal advice.

The preparation problem is being solved. The verification problem is not.

The industry raced to automate drafting. Thomson Reuters "Ready to Review" auto-prepares 1040s, CCH Axcess Expert AI drafts advisory insights across thousands of firms, and Blue J answers research questions. What no one automated is the highest-penalty step: is this position actually defensible under the statute?

The real failure mode is not bad grammar. It is confident misclassification: a plausible, well-written position that puts a deduction on the wrong line. When an AI misclassifies a deduction as above-the-line instead of below-the-line, the 20% IRC §6662 accuracy-related penalty applies to the human who signed the return, not the algorithm that drafted it. The §6663 fraud penalty runs up to 75%. US business tax-compliance already costs more than $126B a year, and the IRS large-corporate audit rate has climbed from 8.8% to 22.6% (WP#1 solution research, 2026).

You cannot trust an LLM to police an LLM through the same weights that produced the error. An in-model self-check runs the exact reasoning that misclassified the position in the first place. The durable answer is verification that lives outside the model.

Agent advises, code decides.

StatuteGuard inverts the trust model. An AI may draft, but a deterministic policy engine decides whether the position is defensible. The only LLM step is extraction, turning messy natural language into a structured, typed claim. It abstains when it is unsure. Everything downstream is code the model cannot override. We call it neuro-symbolic: neural extraction, symbolic verification.

Stage	What runs	Who decides
Extract	LLM reads the position memo and proposes a typed claim, reporting its confidence. Below the confidence floor it escalates instead of resolving.	LLM (advisory only)
Retrieve	GraphRAG traverses the IRC cross-reference knowledge graph to pull the provisions in play and their typed relationships.	Deterministic
Verify	Real OPA/Rego policies (or an identical pure-Python twin) test the claim against the encoded statute.	Deterministic
Gate	PASS (defensible), BLOCK (contradicts the encoded statute), NEEDS-REVIEW (genuine gray area), or OUT-OF-COVERAGE (not encoded in V1).	Deterministic
Audit	Writes a filable IRC §6662 due-diligence record as JSON plus a printable HTML certificate.	Deterministic

Because the verdict is policy code and not a model call, you can read the Rego and confirm it matches the statute. The verification layer runs as infrastructure, measured at tens of thousands of positions per second (roughly 40k to 60k across runs, machine and run dependent), not as a per-position model inference.

The provisions encoded in this version: OBBBA QPVLI (§163(h)(4) / §63(b)(7)), §199A QBI, the §163(j) business-interest limitation, §1031 like-kind exchange, §280A home office, the §30D clean-vehicle credit, and the §62/§63 AGI distinction. Everything outside that set returns OUT-OF-COVERAGE and routes to a human. StatuteGuard does not claim to encode the full IRC.

What it catches, shown three ways

The demo walks a BLOCK, a PASS, and an escalation, all on synthetic positions. The screenshots below are real captures of the running app.

The anchor: an OBBBA car-loan-interest position drafted as above-the-line

A drafted statement reads: "The new OBBBA car-loan interest deduction is an above-the-line deduction that reduces the client's AGI." It is plausible, well written, and wrong. Qualified passenger vehicle loan interest is a below-the-line deduction under §63(b)(7); it does not reduce AGI. Per the demo's own README, mainstream tax-prep guidance (including H&R Block's site) has mislabeled it above-the-line. StatuteGuard returns BLOCK: DO NOT FILE, animates the citation chain §163(h)(1) → §163(h)(4)(A) → §63(b)(7) → §62/§63, and flags a 5-way downstream cascade of what breaks if filed as drafted: AGI, AGI-coupled state tax, Medicare IRMAA premiums, the medical-expense deduction floor, and student-loan income-driven repayment.

StatuteGuard verdict screen showing BLOCK: DO NOT FILE on the OBBBA car-loan interest position, with the statute-grounding stage rendered in 7 microseconds, six statutory nodes from §163(h)(1) through §63, and a five-panel downstream cascade for AGI, state income tax, Medicare IRMAA, the medical-expense floor, and student-loan IDR.

The extraction step took 5.93s; the deterministic grounding rendered its verdict in microseconds.

A clean §1031 exchange passes

A compliant like-kind exchange of investment real property returns CLEARED: safe to file as drafted, with its own two-node citation chain (§1031(a)(1) and §1031(a)(2)-TCJA). This is the discipline that matters: a correct position is never wrongly flagged. Gate precision is 100% with 0 false blocks on the golden set.

StatuteGuard showing CLEARED, safe to file, on a §1031 like-kind exchange of investment real property, with a two-node statute-grounding graph for §1031(a)(1) and §1031(a)(2)-TCJA.

A §280A gray area escalates

A home-office position where the file does not establish exclusive business use is a facts-and-circumstances test, outside deterministic coverage. StatuteGuard returns NEEDS HUMAN REVIEW rather than bluffing. The LLM proposes a checkable claim and reports confidence; below the floor, the position is escalated, never resolved by the model.

StatuteGuard running the pipeline on a §280A home-office position whose file does not establish exclusive use, with the caption noting the gray-area position routes to NEEDS HUMAN REVIEW.

You can read the policies yourself

The Policy Rules viewer shows the deterministic statutory logic as readable decision tables next to the real OPA/Rego source. This is the point of a verification layer you can defend: you confirm the code matches the statute, rather than trusting a model's summary of it.

StatuteGuard Policy Rules panel showing decision tables for §280A home office and the §30D clean-vehicle credit, including the MSRP caps and modified-AGI caps, above the real OPA/Rego source comments.

Every verdict writes a filable record

The audit stage produces a Form SG-6662 due-diligence workpaper: the source, the primary statutory authority, the extracted claim, the determination narrative, and the full citation chain, ready to print or save as PDF and retain in the client file. It supports a §6662 reasonable-cause position; it is not advice.

StatuteGuard printable due-diligence certificate, Form SG-6662, for the blocked OBBBA position, showing the source workpaper, primary source, extracted claim, a due-diligence determination checklist, the determination narrative, and the statutory citation chain.

Measured on a labeled golden set, evaluated locally

Run Benchmark replays a 42-position labeled golden set (14 clean, 16 error, 12 escalate). The scoreboard reports 71.4% deterministic coverage, 100% gate precision with 0 false blocks, 100% error-catch completeness, and 100% correct escalation of gray areas, with every verdict matching its label. These describe the verification layer, not a model error rate, so they hold as base models improve. During the build the verdicts were cross-checked against OPA 1.17.1 and matched the pure-Python twin exactly on all 42 cases.

StatuteGuard golden-set benchmark scoreboard: 71.4% deterministic coverage, 100% gate precision with zero false blocks, 100% error-catch completeness, 100% gray areas correctly escalated, and 58,648 positions per second, above a per-case table of expected versus actual verdicts.

These numbers are measured on a fixed 42-case labeled golden set of the encoded provisions, not an open-world guarantee.

Where a verification layer fits

StatuteGuard does not compete with your drafting tool or replace a compliance platform. It sits on top of whatever you already use and checks the one thing they cannot: whether the drafted position holds against the statute.

Question	Drafting AI (ONESOURCE, CCH Axcess, Blue J, ChatGPT)	LLM self-check	StatuteGuard
Primary job	Prepare and draft positions	Re-read its own draft	Verify a drafted position against the statute
Who renders the verdict	A language model	The same model, same weights	A deterministic policy engine (OPA/Rego)
On a genuine gray area	Produces confident prose	Produces confident prose	Escalates to a human (NEEDS-REVIEW / OUT-OF-COVERAGE)
Filable §6662 record	No	No	Yes, a printable due-diligence workpaper
Reads any platform's output	Tied to its own product	Tied to its own model	Vendor-neutral by design

What this demo does not do

It is a runnable demo, not a deployed pipeline. It proves the mechanism; it is not a production system with customers.
The ONESOURCE, CCH Axcess, and Blue J connectors, the live LLM calls, and the Neo4j graph are simulated or stubbed. The demo runs on cached-replay extraction and an in-memory JSON graph so it works offline; FastAPI and Neo4j are the documented production swap.
Every position shown is synthetic. The statutory logic is grounded in primary law (IRC and the Federal Register); the positions are illustrative, not real taxpayers or clients.
It encodes a specific provision set, not the full IRC. Anything outside it returns OUT-OF-COVERAGE and routes to a human.
The benchmark numbers hold on the 42-case labeled golden set of the encoded provisions. They are not an open-world guarantee of "zero errors" or "guaranteed compliance."
It supports a §6662 reasonable-cause and due-diligence position. It is not tax or legal advice.

Questions a tax and compliance team actually asks

How is this different from our tax-prep software or an AI research tool like Blue J?

Those tools draft and prepare. StatuteGuard verifies. It is a vendor-neutral layer that sits atop the platform you already use: paste a position from ONESOURCE, CCH Axcess, Blue J, ChatGPT, or an internal model, and it returns a hard PASS, BLOCK, or NEEDS-REVIEW against the encoded statute. It does not prepare returns or replace a compliance platform; it checks the position-level errors the drafting tool cannot see.

Can I trust an AI to check another AI's work?

No, and StatuteGuard does not ask you to. The only LLM step is extraction, turning messy language into a structured claim. The verdict is rendered by a deterministic policy engine (real OPA/Rego, or an identical pure-Python twin), which the model cannot override. You cannot trust an LLM to police an LLM through the same weights that produced the error, so the decision lives outside the model in policy code you can read against the statute.

What happens when a position falls in a gray area the rules don't cover?

It escalates to a human instead of guessing. A genuine facts-and-circumstances question (a §280A home office, for example) returns NEEDS-REVIEW; a provision not encoded in this version returns OUT-OF-COVERAGE. Both route to a reviewer rather than a confident bluff. On the 42-case labeled golden set, gray areas were correctly escalated 100% of the time; coverage is stated honestly at 71.4%.

Does our client data or the position leave our environment?

The demo runs fully locally with no API key, using cached-replay extraction by default, so no position or client data has to leave the perimeter. That local, closed, auditable posture is deliberate after the Heppner ruling (SDNY, February 2026) raised a privilege-waiver question over a public-AI-tool research query. The architecture is designed to be privilege-safe, not to send positions to an outside service.

Does it connect live to ONESOURCE, CCH Axcess, or Blue J?

Not in this demo. The ONESOURCE, CCH Axcess, and Blue J REST connectors, the live LLM calls, and the Neo4j graph are simulated or stubbed; the demo runs on cached replay and an in-memory JSON graph so it always works offline. The verification mechanism is real and vendor-neutral by design; the production build documents FastAPI, Neo4j, and live connectors as the swap-in path.

What do the 71.4% coverage and 100% precision numbers actually mean?

They are measured on a fixed 42-position labeled golden set of the encoded provisions, not an open-world guarantee. On that set: 71.4% of positions were resolved deterministically without escalation, gate precision was 100% with 0 false blocks, and every verdict matched its label. These describe the verification layer's coverage and precision, not a model error rate, which is why they hold as base models improve. It supports a §6662 due-diligence position; it is not tax or legal advice.

Technical Research

The research behind this demo — the architecture, the verification design, and the enterprise blueprint.

Full solution

Explore the Tax Compliance AI Verification solution →

Put a verification layer between your AI and your signature

The 20% penalty lands on the person who signs, not the model that drafted. A deterministic verifier is how you prove which statutory provision backed which position.

If your team is weighing how to verify AI-drafted tax positions without trusting one model to police another, we would genuinely like to compare notes on how you are thinking about it. The problem is industry-wide and the answers will be too.

Verification assessment

Map where AI-drafted positions enter your filing workflow
Identify the highest-penalty provisions to encode first
Review your current §6662 due-diligence evidence trail
Assess post-Heppner privilege exposure of your AI tooling

Build a deterministic layer

Encode your priority provisions as readable OPA/Rego policy
Stand up the PASS / BLOCK / NEEDS-REVIEW gate on your platform
Wire vendor-neutral connectors to the tools you already run
Generate filable §6662 records with a full citation chain

Connect via WhatsApp Email Our Team