An AI governance system of record
What a bank, credit union or insurer would keep if it had to show an examiner every AI use case, who approved it, against which version of the record, and what has changed since. Sixteen screens from a recorded run on a fictional credit union.
I built this in 2026 as a product bet. There is no language model anywhere in it. The intelligence is in versioned rules, hashes and a database that enforces who may decide what. Every use case is declared through an enumerated intake, tiered by rules that print their trace, gated by named people whose decisions bind the exact hash of the record, and mapped to controls from SR 11-7, the NIST AI Risk Management Framework, the NAIC bulletin and the EU AI Act. Reports go to the board and to examiners with the drift since the last one, and the whole record exports with a verifier that needs nothing but Node.
The tenant, the people and the data are fictional, and every screen says so in its top bar. The screens below are from the product's own manual, captured by the test rig in workflow order.
A fresh tenant
Six tiles at zero and an audit trail that already holds two events: the tenant and its first user. Everything that happens from here lands in that trail.
The institution declares itself
A credit union with a federal charter, regulated by the NCUA, operating in two states, no EU exposure, assets in the one to ten billion band, the NAIC bulletin not adopted. Declared by a named person on a date. The profile decides which duties apply at all.
Intake with a live tier preview
Every field is an enumeration. Before anything is saved, the versioned rules compute the tier and print which ones fired: R4 decides Tier 2 because the chatbot is member-facing and handles personal information. A tier is not a legal determination, and the screen says so.
The rules, in the open
The rules with their notes, and what each tier requires: which gates, what review cadence, what windows. The rule set carries a version date, so a tier computed last quarter can still be explained next year.
Six use cases, six tiers
A chatbot, fraud and AML scoring, an office copilot, loan document extraction, collections prioritisation and marketing propensity, each with its state, tier and model type, and whether it sits inside a vendor's product.
Vendors and systems
Three vendors and six AI systems, linked to the use cases they serve. The inventory is the first thing an examiner asks for.
What a control status means
Automated is a machine-verified file inside its window. Attested is a named person's dated statement, or a gate decision whose hash still matches the record. Design means a document was linked. Gap means nothing on file. Record-derived statuses say what was present, never whether it is true, and are counted apart.
A gate waits for a person
Once a use case is submitted, the intake-approval gate offers Decide. The decision binds the exact hash of the record as the reviewer saw it.
The database says no
The administrator tries to approve the gate and the database refuses it by policy. Who may decide which gate is enforced below the application, not in a settings page that can drift.
Three gates, fresh
Intake approval, validation sign-off and deployment approval, each decided by the Risk Officer on a date, each against the hash it was decided on. In production since, next review due.
The record changed, re-read
A decision submitted against a hash that no longer matches comes back as stale. Nothing is recorded against a version of the record the reviewer did not see.
Overriding the rules, on the record
A named person can override the computed tier with a reason of at least twenty characters and no conformance claims. The override is voided on its own when the intake changes.
A report is released
Version 1, with its snapshot hash and manifest hash, two gate decisions by the Risk Officer, the versions of the catalogue, rules and engine it was built with, and seven limitations the engine prints on every report whether anyone wants them or not.
Drift since the last report
Version 2 lists what moved since version 1: a use case retired, evidence added, a review overdue. The board sees change, not a fresh snapshot with no memory.
The record leaves with its own verifier
The whole tenant record, rows, hashed texts, the events chain, evidence files and released bundles, exported as one bundle with a verifier that runs with Node alone, without the product or its database.
What a board member sees
A reader role: the record and the released reports, nothing to edit. The same numbers the governance lead sees, with no way to change them.
Why it is built this way
Governance tools fail in one of two ways. They become a spreadsheet with a login, where every status is a claim somebody typed. Or they become a model-driven assistant that explains compliance in confident prose nobody can audit. This one refuses both. A status is automated only when a machine verified a file inside its window. A gate decision is worth something only while its hash matches the record. A report carries its own limitations, printed by the engine, because the honest version of a governance record is the one that says what it does not know.
The same ideas run through the case studies: approvals as rows the system re-verifies, rules written down where a machine can read them, and a person on the exception path.