The idea in one paragraph
LodgeiT uses three kinds of intelligence, and each does only the job it is good at. Rules written in Logical English do the law and the arithmetic, deterministically, and say when they cannot answer. Language models explain, retrieve, ask for missing facts and draft; they never decide a figure the rules can prove. Qualified humans decide whether the rules state the law correctly, and their verdict, bound to the exact file they read, is what makes the rules trustworthy. The bounty programme is how we pay for that judgement.
Logical English is the executable legal specification, the surface a practitioner reviews, and the oracle our product code is checked against. It is not the production runtime.
Who does what
| Task | Rules | Model | Qualified human |
|---|---|---|---|
| State the law as executable rules | drafts with help | drafts with help | ratifies |
| Compute a figure | yes | never, where the rules cover it | checks by hand in review |
| Say “cannot be determined: missing X” | yes | turns X into a question | — |
| Refuse out-of-scope cases | yes | says the answer wasn’t rule-checked | agrees the scope is right |
| Explain an answer in plain words | supplies the proof | yes | — |
| Find and read legislation | — | as a research aid | reads it themselves |
| Decide the rules state the law | — | never | yes |
Why the model never computes where rules exist: in one test a chain of three models reached the right answer only because the third caught an arithmetic error the second had missed. [measured] Nothing deterministic checked it. The rules would have.
The pipeline
- Statute to rule file. Drafted from the Act, never from forms, worksheets or calculators. (The Division 36 work began because a product followed an ATO worksheet that diverges from s 36-15 in one kind of year. [measured])
- Measure. Every embedded test runs on a pinned reasoner. Rules, scenarios and tests are counted by command. Zero rules that no test reaches.
- Independent re-derivation. A separate agent that has not seen the expected answers works a sample of scenarios from the statute alone. On the CGT file this caught a cost-base defect (s 110-45(2)) before release. [measured]
- Human review (a bounty). Practitioners read the rules against the statute and return a verdict on a form.
- Revise. Every finding gets a recorded disposition: adopted, turned into a refusal, stated as a precondition, put back as a question, or rejected with a reason.
- Review again if the file changed materially.
- Pin. The accepted file is identified by its SHA-256 and the reasoner by its full commit, archived.
- Use. Products and Tax Genii run the pinned file and show its SHA with every answer that used it, labelled “under review” until the verdicts are in.
What a reviewable rule file looks like
- Three-way answers. A proven figure; or “cannot be assessed”, naming the missing fact; or refused, with the reason. Never a guessed figure. Facts that change the answer (residency, asset character) are required inputs, not defaults.
- A declared scope in the header, and a refusal with a reason for everything outside it.
- One plain comment per rule, “If … then …”, naming the subsection. The one readability aid a reviewer asked for by name. [reviewer]
- What is not law is marked (“Mechanical”, “Implementation note”) so reviewers know what not to ratify.
- Expected figures come from the statute, worked by hand before the file is run, with the working shown. The file’s output is never copied into its own tests.
- Counts are measured, with the command stated.
- Rule shape is measured too. A file can be legally right and still not run; memoisation, for example, made Division 36 eight times slower and made the CGT file possible at all. [measured] Each file is measured, not assumed.
- No real client data. Fictional taxpayers, round figures.
The human review: why it is paid, what it asks
Reading rules against a statute is slow and unfamiliar even for experienced practitioners; round one of Division 36, about 90 lines, took one reviewer four hours. [reviewer] The fee is set to the scope and does not depend on the verdict: a REJECT is worth the same as an ACCEPT. A polite approval of something wrong is the one outcome we cannot use.
We ask, rule by rule, whether the comment states the subsection correctly and whether the rule does what the comment says; for scenarios traced by hand; for unstated assumptions and cases that should refuse but don’t; and, the question we value most, a fact pattern where the rules give a plausible figure that is wrong. We do not ask anyone to install software or read code.
AI and the reviewer
Reviewers may use AI to find provisions or test their understanding. What we pay for is their own qualified judgement. The review is designed so a model-only verdict is not enough: the break-it fact pattern is theirs and we run it; the form asks which provisions they read and which scenarios they traced; every verdict gets a paid follow-up round, which is where understanding shows (in Division 36 round one, two of five verdicts changed after follow-up [measured]); and the form carries an explicit attestation.
Words we use
A file is “under review” until the verdicts are in and every finding is dispositioned; never “certified” before then. A difference from an ATO tool is “a gap we have raised”, not “the ATO is wrong”.