On 31 July I presented a paper at IEEE IRI 2026, the conference on information reuse and integration. The paper is an industry-track case study of an accounting system where an AI agent writes to the general ledger, and the talk went the way talks go: twenty minutes of me, then the part that actually matters.
Four questions came back. I want to write them down while the answers are still the ones I gave in the room rather than the ones I polished afterwards, because the polished version is always less useful.
1. Why not just use ChatGPT or Claude directly?
This one comes first every time, and it is a fair question rather than a naive one. If a model can read a bank statement and describe the journal entry, why build anything underneath it?
Here is the difference, stated as plainly as I can. Ask a chatbot to post a journal entry and you get text that looks like a journal entry. Ask our system and you get a row in an immutable ledger that provably balances, because deterministic code wrote it and a set of structural checks verified it before it landed.
A bare model has no system of record. It has no invariants. It has no ownership model that says which component is allowed to write where. And it cannot be unit tested, because you cannot unit test a prompt. You can evaluate a prompt, which is a statistical claim about a distribution of outputs. That is a different thing from a test, and an auditor knows the difference even if they would not put it that way.
What the model is genuinely good at is deciding what you meant. That is the hard, unstructured half of accounting, and handing it to a model is the actual innovation. It just never decides what the books say.
2. How is an invariant different from a unit test? You already have thousands of tests.
The best way I have found to answer this is with a hundred dollars.
You transfer 100 from savings to checking. The unit test asks: did checking go up by 100? It did. The test passes, green tick, ship it. But the code forgot the other half. Savings never went down. You have created 100 out of nothing, with every test green, because the test only checked what it was told to check.
An invariant asks a different question, and it asks it after every ledger operation rather than once per test case: do all debits still equal all credits across the entire book? That fails immediately. It does not care which function ran or what the author of that function thought they were doing.
The line I keep coming back to: unit tests check that the code did what you asked. Invariants check that the books still make sense.
The paper reports five bugs that unit tests passed and invariants caught. That is not five sloppy functions. Each of those five times the function did exactly what it was asked to do and left the ledger broken anyway, which is precisely the class of bug a test suite written by the same person who wrote the code will never find.
3. The model is nondeterministic. How can it be anywhere near a general ledger?
It is not. That is the whole answer, and the rest is showing where the boundary sits.
The model interprets. Deterministic code writes. Invariants verify. Nondeterminism is real and it does not go away because you disapprove of it, so the design question is where you let it land. Interpretation is a good place: if the model misreads an ambiguous line item, that is visible, correctable, and cheap. The ledger write is a terrible place, so it never happens there.
The second half of the answer is the ownership rule, which is the part the IRI audience found more interesting than I expected. Any module can read any table. Each table has exactly one module allowed to write to it. So when a sales invoice is wrong there is exactly one place to look, one file, not the entire system. It also contains the blast radius: a defect in one industry module cannot corrupt the sales ledger, because it never had write access to it in the first place.
The alternative, which most systems arrive at without ever choosing it, is a document that eleven people can edit, where fixing a defect starts with reading the version history and guessing.
4. Is that actually reuse, or is it configuration with better marketing?
The sharpest question of the four, and the right one to ask at a conference about reuse.
My answer is the chef and the recipe. A trained chef already knows knife work, heat, and timing. Hand them a recipe for a dish they have never cooked and they will make it tonight, because the recipe carries what is specific and the chef carries what is general. The model is the chef. The module manifest is the recipe. The shared database is the kitchen. Adding an industry means writing one more recipe, not sending the chef back to culinary school.
The concrete instance in the paper is a generated module for a tattoo parlour: 8 tables, 18 actions, 48 of 48 tests passing. Across three generated modules there were 19 human decisions in total, and every one of them was a business preference rather than an accounting decision. How long a deposit is held, for example. Nobody had to decide how double entry works, because that is in the chef.
So is it reuse? What gets reused is the interface contract and the accounting core. What varies is a manifest. I think that is a stronger claim than configuration, because configuration implies switches on a fixed system, and this generates a module that did not exist. But I would rather argue about the label than lose the distinction, which is that conventional ERP answers a new industry by hiring a second chef and building a second kitchen.
The question I expected and did not get
Nobody asked whether this generalises outside accounting. I would have struggled with it, honestly. Accounting has unusually crisp invariants: debits equal credits, and the whole discipline has spent five centuries agreeing on what correct means. Not every domain has a rule that clean, and the parts of this architecture that depend on having one are the parts I would be most careful about promising elsewhere.
If you were in the room and asked something I have mangled here, tell me and I will correct it.