Core Concepts

The AI Treasurer

The automated layer that classifies transactions against governing rules and prepares work for officer review. What it does, what it refuses to do, and what is not built yet.

Supervision, not delegation

The organizing idea is that an officer supervises decisions rather than performing bookkeeping. Transactions are classified against the organization's governing rules as they arrive; each classification carries a confidence score and the reasoning that produced it; work that clears the threshold is applied, and work that does not is put in front of a person. The person's attention is spent on the ambiguous cases, which are the only ones where judgment was ever required.

The design point that follows from this — and it is the load-bearing one — is that the automation never becomes the accountable party. Fiduciary duty is not delegable, and a system that let an officer say “the software decided” would be worse than useless to the officer, because it would be worse than useless to the regulator asking the question. Every decision surfaces with its reasoning attached precisely so that approving it is an informed act rather than a ritual. See Reasoning and Evidence and Officer Actions.

In the application the automated layer addresses the officer in the first person — “I could not confidently categorize this charge.” That is deliberate. A system that reports its own uncertainty in the first person is easier to hold to account than one that emits passive status text, and stating uncertainty is the behavior most worth encouraging.

What runs deterministically

Three parts of this are implemented and contain no model inference at all. This is a design choice, not a gap:

• Policy evaluation. An organization's written commitments are parsed into rules, and transactions are evaluated against those rules by ordinary code. No language model participates at evaluation time. A rule that fires must be reproducible; a rule whose outcome depended on a model's mood on a given afternoon would not be a rule.
• Filing derivation. A filing is replayed from ledger events rather than stored, so it is a pure function of the chain. See Filings.
• Explanation. Explanations are read back from what was recorded at decision time. Nothing is generated after the fact. The reasoning behind that constraint is in Reasoning and Evidence, and it is the most important sentence on that page.

What is designed but not operating

This section exists because the alternative is to let a reader infer more than is true.

The automation is organized around four roles — a categorizer, a reconciler, an anomaly-detector, and a filing-drafter — and the categorizer is implemented as a cascade that tries deterministic rules first, then vector similarity against prior decisions, then a local language model, blending the signals and penalizing disagreement between them.

That code exists in this repository. It is not, today, running continuously against live production data. The table that would hold recorded agent decisions is not yet provisioned in the production database, and the automated surfaces in the application render representative sample data rather than a live decision history. What is genuinely live in production is the ledger itself, the hash chain over it, the nightly checkpoint, and the public verification endpoints — the parts described in The Hash Chain and Verification.

What it does not do

These are boundaries, not unbuilt features. They are not on a roadmap.

• It does not move money. There are no payment rails. It cannot initiate a transfer, pay a vendor, or issue a refund. It reads financial events and classifies them.
• It does not sign or submit anything officially. It prepares; a person approves; and OpenBooks does not transmit filings to any agency at all. See Filings.
• It does not make political or editorial statements. It classifies transactions against rules. It holds no view about the organizations it serves, and it is non-partisan and non-sectarian by construction.
• It does not overrule a person. An officer's correction always wins, and the correction is recorded as a new ledger entry rather than an edit.

Why no model runs at explanation time

The strongest temptation in a system like this is to generate an explanation on demand: ask a model, at the moment a human opens a record, why the decision was made. The output would be fluent and it would usually sound right.

It would also be an invention. A model asked after the fact does not recall the decision; it reconstructs a plausible account of one. Presented in an audit trail, that reconstruction is indistinguishable from a record — and an audit trail whose contents are indistinguishable from plausible fiction is not an audit trail. So explanations are read back from what was stored at decision time, and where nothing was stored, the system says so rather than filling the space.