Skip to main content

​
Where the business logic lives

Every AI-driven system has to answer one question: which rules can a business user change, and which ones need an engineer? Answering it badly in either direction is expensive. Too much in code and the system is unusable without a deploy for every business decision. Too much in editable knowledge and somebody changes the books through a text box. GreatBook draws the line at ledger consequences.

​
The line

SOP · editable knowledge, no deploy

Agent judgment. How the Clerk classifies the 146 document types. What counts as a supplier bill. How an agent interprets a document before proposing anything.Soft, natural-language, retrieved at run time.

Code · deploy required

Rules with ledger consequences. The double-entry. The sub-ledger writes. The Close checksums. The hash chain.Hard, deterministic, gated.
The test is not “is this a business rule”. Almost everything here is a business rule. The test is: does getting this wrong change the books?

​
Worked example

“Open an AP obligation when you credit AP control.”
That reads like an operating procedure. It is code. Getting it wrong leaves the control account carrying a balance the sub-ledger cannot explain, which fails a Close checksum and makes every aging report unreliable. That is a ledger consequence, so the rule lives in the single obligation writer, with a regression test, behind a pull request. Compare:
“A bill from a laundry service is a service invoice, not a consumables invoice.”
That is judgment. Getting it wrong routes a document to the wrong reviewer and produces a proposal a human declines at a gate. No ledger consequence, because a gate stands between it and the books. So it is an SOP, editable without a deploy.

​
How to change each

Whether an obligation opens, which account is used, how the due date, party or currency derive.Edit the engine code, add a regression test, and ship it as a code change, through the review pipeline, to a deploy.This is intentionally not a business-user edit, because it changes the books.
What the Bookkeeper recognises. How an agent reads a document before proposing.Edit the SOP. No code deploy.With one caveat that matters: a rulebook generated from code is regenerated when the code changes, so it is not a free-text field. See the SOP store.

​
There is no data-driven posting-rules layer today, on purpose

A search over the backend for any posting-rules, account-map or obligation-config table returns nothing. The double-entry rules are hard-coded in the engine, deliberately, for integrity: the hash chain and the Close checksums both assume the rules were the rules at the time of posting.If you later want this tunable without a deploy, that is net-new work: it means building a posting-rules configuration layer that the engine reads, with its own versioning, its own audit trail and its own answer to “which version of the rules posted this entry”. It does not exist yet, and this documentation does not imply that it does.
That last sentence is the honest part. “Configurable posting rules” is a feature every accounting product eventually wants, and describing the current design as if it already had one would be the easiest kind of documentation lie to tell.

​
Why the boundary holds in practice

Three properties keep judgment from leaking into ledger consequences: So the worst case for a wrong SOP is a proposal a human declines. The worst case for a wrong posting rule is an immutable entry that has to be reversed. Those are different magnitudes, and the line is drawn exactly there.

​
Quick reference