The night I read a mainstream tax-prep page and knew it was wrong
I was reading up on the new OBBBA car-loan interest deduction when I noticed something off: several well-known tax-prep resources, including H&R Block's own site, described it as an "above-the-line" deduction that reduces AGI. So I checked the statute. It isn't. Qualified passenger vehicle loan interest is a below-the-line deduction under §63(b)(7), and it does not touch adjusted gross income at all. That gap, between a confident, well-written sentence and what the code actually says, is the whole reason I built StatuteGuard.
I loaded that exact claim into the demo as a sample position ("the new OBBBA car-loan interest deduction is an above-the-line deduction that reduces the client's AGI") and hit Verify. The engine blocked it and told me not to file. Then it did the part I actually needed. It animated the citation chain through the IRC graph, §163(h)(1) to §163(h)(4)(A) to §63(b)(7) to §62 and §63, and it flagged a five-way downstream cascade of what breaks if you file as drafted: AGI, state income tax, Medicare IRMAA surcharges, the 7.5% medical-expense floor, and student-loan income-driven repayment. Every one of those keys off AGI. One wrong line quietly propagates into five places.
The BLOCK verdict on the OBBBA car-loan position: the statutory citation chain plus the five-way downstream cascade of what breaks if it's filed as drafted.
What I stopped believing about AI in tax
I used to think the AI problem in tax was accuracy, that the models just needed to get better. I don't believe that anymore. The preparation problem is genuinely being solved: Thomson Reuters "Ready to Review" auto-prepares 1040s, CCH Axcess drafts advisory insights across thousands of firms, Blue J answers research questions. What almost nobody is doing is verification, the step that asks whether a drafted position is actually defensible under the statute. And the step matters more than the draft for one reason: when an AI misclassifies a deduction, the 20% IRC §6662 accuracy-related penalty lands on the human who signed the return, not on the algorithm that wrote it. A better base model does not change who signs.
None of this is abstract right now. AICPA's revised Statements on Standards for Tax Services, effective January 2024, tightened the due-care expectation for practitioners using electronic tools, and the §6662 exposure sits alongside a §6663 fraud penalty that can reach 75% of the underpayment when the facts turn bad. And after the Heppner ruling (SDNY, February 2026) raised a privilege-waiver question over a public-AI-tool research query, "where did this position actually run" stopped being a technicality.
The design decision that scared me: teaching it to say "I don't know"
I almost made the demo look smarter than it is. The tempting build is a system that always returns a crisp verdict, because a tool that answers everything demos beautifully. I took that out. Some tax questions are genuine facts-and-circumstances gray areas, and a §280A home-office deduction is the cleanest example: whether a spare bedroom is used "regularly and exclusively" for business is not something a policy engine can decide from a memo. So when I paste that position, StatuteGuard does not guess. It returns NEEDS HUMAN REVIEW and routes it to a person.
The §280A gray area escalates to NEEDS HUMAN REVIEW: the model proposes a claim, but it never decides, and a facts-and-circumstances test goes to a person.
That felt like admitting weakness until I reframed it. Honest coverage is the product. A verification layer that quietly bluffs on the hard cases is worse than useless, because it launders a guess as a check. Anything outside the encoded provision set returns OUT-OF-COVERAGE and escalates too, instead of pretending. I would rather ship a system that tells you where its competence ends than one that hides it.
Why the verdict is something you can actually read
I made one rule non-negotiable early: the thing that decides has to be readable by a human who isn't me. The only step in the pipeline that uses a language model is extraction, turning a messy memo into a structured claim. The verdict itself is deterministic policy code. (I spent a while trying to get one model to check another's work before I accepted that you can't trust an LLM to police an LLM through the same weights that produced the error.) So the decision lives in real, readable OPA/Rego policies, or an identical pure-Python twin when the OPA binary isn't on the box. A head of tax can open the §30D clean-vehicle rules and read the plain logic: block if MSRP exceeds the $80,000 SUV cap, block if modified AGI exceeds the $150,000 single-filer cap. You can read it and confirm it matches the statute. Agent advises, code decides.
The Policy Rules viewer: readable decision tables for each encoded provision, backed by the real, auditable OPA/Rego source.
The number I check before I trust any of this
Before I trust a blocker, I check whether it's trigger-happy, because a verification layer that cries wolf is the fastest way to get itself switched off. So I run the benchmark. On a 42-case labeled golden set (14 clean, 16 error, 12 escalate), the engine reached 71.4% deterministic coverage with 100% gate precision and zero false blocks, and it correctly escalated 100% of the gray areas. The clean §1031 like-kind exchange passes through untouched; the wrong OBBBA position blocks. Those numbers describe the golden set, not the open world, and I say so every time, but they are the right shape: catch the errors, never flag a correct position, escalate the rest honestly. In one local run it cleared the whole set at tens of thousands of positions a second, because verification is infrastructure, not another model call.
The golden-set scoreboard: 71.4% coverage, 100% gate precision (0 false blocks), 100% of gray areas escalated, across the 42 labeled positions.
What I keep asking heads of tax
The question I keep coming back to is not "is your AI good enough." It is simpler and harder: when your AI drafts a position and you sign the return, who checked that it matches the statute, and could you prove which provision backed it to an examiner? For a lot of teams the honest answer today is "the same model that drafted it," and that answer does not survive an audit. StatuteGuard is my attempt at a vendor-neutral layer that sits on top of whatever you already use, ONESOURCE, CCH Axcess, Blue J, or an internal model, and answers that question deterministically. If you want to see it run, the demo is here. I would genuinely like to know one thing: on your last AI-drafted position, could you show which line of the statute made it defensible?