Why Was It Allowed?

A new treasurer is going through the reserve account and finds a transfer from four years ago. Eleven thousand dollars, moved from operating. She asks the question every successor eventually asks: why was this allowed?

In most books the answer is the amount and the date. The person who knew the rest has moved away, or died, or does not remember. The minutes might say. The email might say. The decision itself is gone, because it was never written down where the books could hold it.

A community association is built to meet this question. It holds money for people who do not manage it. A volunteer board governs it, and a statute dictates much of what it may do with the funds. The board turns over. The books have to outlive the people who keep them.

We built the books so that the answer is never in anyone's head.

The decision comes first

Every entry in the ledger passes one enforcement choke point before it exists. The guards that apply to that kind of entry run, and the point writes its answer, allow, block, or override, before the entry is attempted. It writes it again once the entry exists. The record names each guard that ran, its outcome, and its reason codes. It carries a digest of the rules in force at that moment, who approved and under which settings, and a hash of its own content. The database refuses to create an entry that has no decision attached, whatever tried to write it: a person, a background job, or a maintainer who never knew the rule.

The record shows when it has been touched

Each decision's hash includes the hash of the decision before it. Edit or remove one and every link after it breaks. Every night at two in the morning the chain is recomputed and its head is sealed into an immutable snapshot, and earlier seals are checked against it. A verifier that can rewrite its own checksums is not a verifier, so ours cannot.

The money cannot take another route

Each association has its own processor account and its own ledger. Dues settle in the association's own balance and sweep to one pinned bank. A vendor payment goes only against an approved bill of that association, to the vendor's registered bank. CommunityPay holds none of the funds.

The new treasurer opens the transfer. She sees the guards that ran and passed, the fund policy in force that day, the two board members who approved it, and the settings under which they did. The answer is on the page, and it is the answer the system recorded when the money moved, not the one someone remembers.

What the Record Holds

Everything below is in production today.

• Eighteen enforcement guards, each flow running the ones that belong to it: the bill's approval live and unspent, the vendor's license and insurance in force, each fund balanced on its own, the period open, the processor balance able to fund the payment.
• Eight database triggers and twenty-nine constraints hold the ledger's critical rules below the application, and a probe reads the database's own catalog to confirm they are installed.
• A decision written twice, before and after the entry, and a third kind of record when an entry fails after an allow, so a failure is as visible as a success.
• Law or policy, recorded. Every threshold a guard applies is recorded with its source: a statute, with its citation, its pinpoint, and the hash of the text on file that day, or the association's or the platform's own policy. A figure is never recorded as law unless a statute stands behind it.
• A hash chain per association, sealed nightly, with earlier seals re-verified against it.
• Money permissions that start off, granted to each administrator one at a time, with a fresh authenticator code and an email to the board. A text-message code never counts.
• Two-factor sign-in as a setting on each seat, on by default for every new administrator, board member, or holder of a money permission.
• Three checks for the highest-risk acts. Changing the payout bank, or confirming a vendor's new bank, takes the sign-in, a fresh code, and a PIN that belongs to the association.
• A three-business-day wait on a replaced vendor bank, during which the real vendor asks where its money is. A different board member can end it early, after a call to a number already on file.
• One pinned payout bank per association. A vendor's bank can never be it, and automatic payouts pause on their own if the processor's default ever differs.
• Reserve money leaves the reserve only by a board-approved transfer. Operating and reserve funds each balance on their own.
• Everyone with authority is emailed on every vendor payment and every top-up.
• Emailed invoices pass 23 checks before anything is submitted for approval. The inbox never approves and never pays.
• Authority comes only from membership in the association. Staff status grants none.
• A release that cannot ship a wrong statement. Every deploy re-derives the financial statements from the ledger under 32 checks, and a failing check stops it.
• The books leave with the association: one export with the decision identifier beside every entry, a hash for every file, and one digest over the manifest, checkable without us.
• Figures that print from their sources, each with a digest and the date it was read.

What It Does Not Do

A stolen password and a stolen authenticator still look like a valid user. The controls make that case slow and visible: a waiting period, a transfer limit, a call to a number already on file, an email to everyone with authority. They do not make it impossible. The record is built to show what happened, not to promise that nothing did.

A board does not read a ledger's architecture. It reads a treasurer's report in the month the treasurer is new. The architecture is what lets that report answer the next question, the one nobody has asked yet, in the year nobody who was there is.