This is a rule-ratification bounty
Like Bounty #11 (Division 36) and Bounty #12 (its revision), you won’t be checking a calculator. You’ll be checking the law itself, written out as rules — and telling us whether we’ve stated it correctly.
The language is Logical English — developed by Bob Kowalski at Imperial, and LodgeiT is a co-owner of the current version. It produces a proof tree in plain English for every answer, and it refuses to answer when it hasn’t been told enough. But a rule is only trustworthy if someone with a practising certificate has read it and agreed it states the law correctly. That’s the job.
What you are checking
The law itself, written out as rules a machine can run: cgt_a1.le. It takes a CGT event A1 disposal (contract date, acquisition date, proceeds, cost-base elements, entity kind, asset classification) and gives one of three answers: a capital gain or loss and the net capital gain for the income year; “cannot be assessed because <fact> is missing”; or “refused because <provision> not encoded”. 114 rules, 62 fictional scenarios, 163 embedded tests, every expected figure worked by hand from the Act (shown above each scenario). No software to run: read the rules against the Act.
The provisions in scope are ITAA 1997 Parts 3-1 and 3-3: ss 102-5, 102-10, 102-15, 104-10, 108-10, 108-17, 108-20, 108-30, 110-25, 110-45, 110-55, 112-20, 116-20, 116-30, 118-5, 118-10, 118-20, 118-24, 118-25, 118-30, 118-37, 118-60, 118-300, Div 115; and IT(TP)A 1997 s 102-25.
What we most want a practitioner’s view on
- Loss order (Q2). s 102-5 step 1 note 1 and step 2 note 2 leave the order of applying losses to the taxpayer. The file applies losses to non-discount gains first (scenario s7: 9,000, versus 11,000 the other way). Is encoding the minimising default acceptable, or must the order be an input?
- Break-it. Construct facts within scope where the file returns a plausible figure that is wrong. Scenarios s11 (PUA at exactly $10,000), s13 (cost base vs reduced cost base gap, s 110-45(2)), s52 (leap-year anniversary, TD 2002/10), s54 (loss-year strictness) are where we looked.
-
The 17 numbered questions in
open_questions.md(answer inline). - Enter scenario s7 in the ATO CGT record keeping tool and record its figure (we could not complete this by automation — our attempt and the expected points of difference are summarised in the brief below).
The question we value most
s 102-5 step 1 note 1 and step 2 note 2 leave the order of applying losses to the taxpayer. The file applies losses to non-discount gains first (scenario s7: 9,000, versus 11,000 the other way). Is encoding the minimising default acceptable, or must the order be an input?
This is the judgement the statute leaves open. It is worth the fee on its own. Here is scenario s7 as it stands in the file (quoted; please do not edit the file — its SHA-256 is part of the evidence chain):
s7 ordering: d1 gain 20000 (discount: held since 2020); d2 gain 4000
(acquired 2024-09-01, sold 2025-01-15: not 12 months); d3 loss 6000.
Step 1 (s 102-5): the taxpayer chooses the order; the file applies the
loss to the non-discount gain first: 4000 -> 0, remaining 2000 against
20000 -> 18000. Step 3: 18000 x 50% = 9000. Net capital gain 9000.
(Applying the loss to the discount gain first would give
14000 x 50% + 4000 = 11000: the choice matters.)
Out of scope
The file refuses these with a reason: main residence, Div 152, roll-overs, deceased estates, foreign residents at the event, indexation, events other than A1, K7, Subdiv 115-C, life insurance companies, pre-9 May 2012 foreign residency periods, substituted accounting periods, leases granted.
Provenance
Built from the statute via Tax Genii retrieval, not from ATO worksheets; independent re-derivation by a second agent caught one defect (s 110-45(2)) before release; reasoner LogicalEnglish2 bc5cb5d1… on SWI-Prolog 9.0.4, 163/163 pass, slowest query 66 ms. Full trail in the bundle.
Rules file: rules/cgt/cgt_a1.le, SHA-256 3cdb679a02e4cda09101cd8014b1b3db34de32be4603a1b4f5ff9b9953f2ad00. Any accepted verdict is bound to this hash. Please do not edit the file; its hash is quoted in run_log.md and sha_chain.txt, and any change breaks the evidence chain. If you find a defect, cite it — the fix lands in a later version, not in this file.
The four source files
Open these directly in your browser — they are text files served from this page. Read the rules against the Act; the other three give you the hand working, the open questions, and the recorded defects.
cgt_a1.le— the rule file (114 rules, 62 scenarios, 163 embedded tests). Opens as text in your browser; the canonical.leis the same bytes if you want the native extension. Do not edit it.open_questions.md— 17 numbered questions for practitioners; answer inline.scenario_table.md— every scenario, the hand working, the expected figure, and the runner result.findings_log.md— defects in the file this one replaces, each with the provision, the fix, and the proving scenario; plus defects found in our own drafts.
Reviewer pack
Three short documents to take you from a cold start to a filled-in verdict. Open them directly in your browser — they are text files served from this page.
COVER_NOTE.md— what the file is, what we are paying for, where to start. One page.HOW_TO_READ.md— how to readcgt_a1.lein ten minutes: the shape of the file, how to read one rule, the conventions worth knowing.VERDICT_FORM.md— the verdict form itself (v1.2.1), one row per rule family, with the break-it and open-question prompts. The form now ends with a separate signature question (§12) — whether you put your name to this exact file as stating the law — and you are paid for the review whatever you answer there.
The deliverable is the filled-in VERDICT_FORM.md, attached to an email to support@lodgeit.net.au. We hash what you send, so your verdict is bound to exactly what you submitted and to the file SHA-256 above.
Your deliverable
Pick a family above and send the filled-in VERDICT_FORM.md (v1.2.1) — complete only that family’s row(s) in §2, plus §3 (break-it), §11 (attestation) and §12 (signature) — attached to an email to support@lodgeit.net.au. Free-form prose is equally acceptable. You are paid for the review whatever you find, and whatever you answer in §12.
A REJECT is worth the same as an ACCEPT
If the file is sound, say so and take the fee. If it’s rotten, say that and take the same fee. A polite approval of something wrong is the one outcome we can’t use. The most valuable finding in Phase 1, by information-per-dollar, was a reviewer who rejected the brief outright. He was paid in full.
What’s involved
- One rule file, with a plain-English note above each rule saying what we think it means, plus the reviewer pack.
- No software. Every file is text. Open it in Notepad, your browser, or your mail preview. You can’t break anything.
- About 1.5–2 hours per family (14a–14d); 14e is open; 14f (~1 hr) opens once the 14a–14d findings are fixed.
- Paid within 30 days of verdict acceptance — $400 (14a), $300 (14b–14d), $150 per accepted break-it case (14e), $200 (14f), plus a finding bonus of $100 per accepted defect.
What is not in scope
You are not being asked to install anything, run anything, audit our software architecture, review our source code, or learn a programming language. You are being paid for your tax judgement. The files are text. The question is: do these rules state the law correctly?
Ask questions
“I don’t understand what this line is doing” is not a sign you’re doing it wrong; it’s a sign we wrote it badly, and we’d rather hear it than not. Email support@lodgeit.net.au any time.
Attribution — how your work gets credited
Your accepted verdict is minted into the public reviewer registry with:
- Your name and credential class
- The verdict hash (SHA-256 of your submitted document)
- The version of the rules file you ratified (SHA-256 of
cgt_a1.le) - The publication date
Default is named credit. You may opt down to initialled or anonymous when you submit. Opt-down does not reduce the prize.