The rule harvest

Summary

Status. The harvester is on the roadmap. It is worthless until there are resolved findings to harvest, so it follows the findings table and pre-flight checks now in development.

Paying a frontier model to rediscover the same deterministic error on every return, forever, is the same mistake as asking it to add up a column. The rule harvest is how NGTAX.AI stops paying twice: each resolved finding that a deterministic check could have caught becomes one — tested, cited and reviewed by a human — and runs in pre-flight on every return after it.

The loop is how the check library gets written. The library is the asset.

The observation

Much of what an examiner agent catches is not judgment. Schedule L out of balance. M-1 not tying to book income. A depreciation convention wrong for the in-service date. Estimated payments that do not match the deposits in the bank. A Form 5472 threshold crossed with no form attached. These are rules. A model will catch them on most returns; code catches them on every return, for free, in milliseconds.

The pipeline

resolved findings → triage → candidate check → human review → merged check
                    (codeable?)  (code + test +             (runs in pre-flight)
                                  citation)

Triage. When a finding is resolved, it is marked codeable if a deterministic check over the ledger and the return could have caught it with no judgment. Balance, calculation and form-omission findings usually are. Election and position findings usually are not. The resolver suggests; the CPA who just read the finding confirms — a model deciding its own obsolescence is a poor incentive.

Generation. Offline, a harvester reads a cluster of codeable findings of one class and proposes a check. A proposal must arrive with four things or it is rejected automatically:

1. the check itself — a pure function of the ledger, the return and the entity facts that returns findings;
2. a failing test built from the actual return that produced the finding, with figures anonymised;
3. the authority the check enforces;
4. the findings it claims to subsume.

Review. Every generated check is reviewed by a human before it merges. This does not relax as confidence grows. A check that runs on every return is higher-stakes code than anything the loop produces for one return: a wrong check is a wrong figure on a thousand returns, the same way every time, with no model in the path to catch it.

Promotion. Once merged, the check runs in pre-flight, and the findings it subsumes are linked to it. The next return never reaches the examiner with that error.

What this does to the loop

Rounds per return decay toward a floor as the library grows. Our planning model, which we will replace with measured data as returns accumulate, looks like this:

The floor is deliberately not zero. One independent examiner pass stays on every return, because its job is the finding nobody has written a rule for yet.

We track rounds per return as a product metric. It is the clearest measure of whether the harvest is working.

Every check carries its motivating case

Every check in the library ships with the finding that motivated it as a test case. A check without a motivating finding fails the build. This keeps the library honest — every rule exists because a real return needed it — and makes each rule explain itself to the next person who reads it.

Every check is also versioned, and the version is recorded in the provenance of every return that passes it.

Why this is defensible as a business

Anyone can call a frontier model against a trial balance. The accumulated, tested, cited library that makes the model unnecessary for most findings is what decades-old tax software actually sells. The loop is how that library is written in a season rather than a decade — and every firm on the platform makes it better for every other.

Open questions we are working through

Cross-firm learning. A rule learned from one firm's return improves every firm's. The rule is abstract and carries no taxpayer data, but how the derivation is treated under IRC §7216, which governs the use of tax return information, needs counsel's view before harvesting runs across firms. Until then, harvesting runs only within the firm whose returns produced the findings, and only with the consent §7216 requires.

Training on return data. For the same reason, we do not train or fine-tune models on client return data. The compounding asset is the reviewed check library, not a model trained on taxpayers' information.