How It Works

Filings

A filing is not a stored record. It is the story a group of ledger events tells, replayed from the hash chain. OpenBooks does not transmit filings to any agency.

A filing is a projection

A filing is not a row in a table. There is no filings record that gets created, updated, and marked complete. A filing is the story a group of ledger events tells, and it is assembled by replaying those events in order.

When an organization's filing history is displayed, the system reads the ledger, selects the entries concerning that filing — filing.drafted, filing.submitted, filing.accepted, filing.rejected — and folds them into a current picture. Close the page and the picture ceases to exist; open it again and it is rebuilt from the chain.

The lifecycle

The stages are the event types, and each is a fact appended at the time it occurred rather than a status overwritten in place:

filing.drafted — a draft was prepared for a given form and period.
filing.submitted — an officer advanced the draft. This is a human act by a named person; see Officer Actions.
filing.accepted / filing.rejected — an outcome was recorded.

Because every stage is an entry rather than a mutation, the sequence is legible after the fact: when a draft was prepared, who advanced it, how long it sat, whether it was rejected and re-drafted. A status column would have shown only the last of those.

Why derive instead of store

Storing a filing as a mutable record would reintroduce, in the most consequential place in the system, exactly the problem the ledger exists to solve. A stored filing has a status field, and a status field can be set. It could be set to “accepted” by a bug, or by a script, or by someone who preferred that outcome, and nothing about the resulting row would look wrong.

A derived filing has no such field to set. To make the projection say a filing was accepted, an filing.accepted entry must exist on an append-only chain, hashed in sequence, attributed to an actor. There is no back door, because there is no door: the only way to change what a filing appears to be is to append a new fact about it, in public, under someone's name.

OpenBooks does not transmit

Stated plainly

OpenBooks does not transmit filings to any government agency, and has no integration with any regulator's filing system. There is no code path that submits to the Hawaii Campaign Spending Commission, to the IRS, or to anyone else. No acknowledgement is received from any regulator, because nothing is sent to one.

Where a filing.submitted entry appears on a ledger, it records that an officer advanced a filing inside OpenBooks. It does not mean the filing reached an agency. An organization that owes a report to a regulator must still file it with that regulator by whatever means the regulator requires, and the duty to do so — and the signature on it — belongs to the officer.

This is stated at length because the opposite is a natural inference from the word “filing,” and it concerns a legal obligation. Getting it wrong would mean an organization believing a report had been filed when it had not.

What is not built

Declared absence

There is no filing generation engine. The system recognizes some form codes as labels — including the Hawaii Campaign Spending Commission's preliminary report — but a label is what it is. There is no form schema, no field mapping, no rendering, and no calculation behind any form code. Nothing is generated.

There is no readiness score. A filing readiness percentage requires inputs the system does not compute today, and no such computation exists. Where a percentage appears on a filings screen in the application it is a hardcoded placeholder, not a measurement, and it should not be relied on by anyone.

The parts of this concept that are real are the ones above: filings derived from an append-only chain, and a lifecycle recorded as facts rather than statuses. The generation and readiness layers are design, not implementation.