Data Governance When Agents Write the Code
Data governance has a reputation problem: it usually means a policy document, a committee, and a diagram of who should ask whom before touching a table. That model assumes the people changing the system read policy documents and sit on committees. My system is changed, most days, by AI agents. They read fast, forget nothing within a session, and are constitutionally incapable of attending a meeting. Governance had to become something else, and what it became is the theme of this whole series wearing a database hat: policy that is not enforced by structure is a wish.
Here is what governs the data in a fintech where agents write most of the code, and a human signs the five percent that matters.
Corrections are rows, not edits
The first rule is that history is immutable. Cost bases, valuations, capital works, the ledgers that feed tax figures: none of them can be updated in place. A correction is a new row that supersedes the old one, and the old one stays, visibly wrong and visibly superseded.
This is an old accounting instinct, but with agents it stops being a preference and becomes a load-bearing wall. An agent that can UPDATE can destroy the evidence of its own mistake in the same transaction that makes it. An agent that can only INSERT leaves a trail no matter what it does. I do not enforce this by telling agents not to update. I enforce it by not granting an update path at all: the write route is an insert-only database function, and the table policies do not contain an update rule for anyone, agent or founder. When the property module shipped its valuation table last week, the review question was not "will the code behave." It was "does an update path exist," and the answer had to be no before the schema could apply.
Every fact carries its passport
The product encodes tax law, and tax law changes. Every statutory constant in the system, every rate, threshold and commencement date, lives in a register with three attachments: the value, the primary source it came from, and the date it was last verified against that source. Code that uses a constant points at the register entry. Published copy cites the same entry. When a value changes upstream, one register line changes, and everything that depends on it is findable by grep.
The rule that makes this governance rather than bookkeeping: no fact enters the system from memory. Not from mine, which goes stale, and not from a model's, which synthesises plausibly. An agent that wants to use a figure must find it in the register or stop and flag the gap. Provenance is not metadata we add for the auditors' comfort. It is the admission control for facts.
Schemas are clearance levels
The database is split into namespaces that map to trust, not to features. Application tables live in one schema behind row-level security, so every query is scoped to the fund that owns the row, whichever code path makes it. Reference data, the tax rulings and security identifiers, lives in its own schema that application code reads and never writes. Calculation functions live in another. And the audit log schema, the record of what was ingested, computed and refreshed, is readable only by the service role: no application path, agent-written or otherwise, can reach it at all.
The point of the separation is that an agent's mistake inherits the clearance of the schema it happens in, not the ambition of the code that made it. A bad write in application space is scoped to one fund by policies the write cannot skip. The audit trail that would prove the mistake happened is in a space the mistake cannot follow it into. This is the identity-plane argument from the previous essay, pushed one layer down: below the credential sits the schema, and the schema does not read prompts.
The test is reconstruction
There is a single question that all of this serves, and it is the question an SMSF auditor asks every year by profession: can you show me where this number came from? Every figure on a statement should walk backwards to a transaction, the transaction to a source document, the document to a content hash and an arrival date. When my pipeline builds its year-end pack, that chain is the product. The statements are almost a by-product of being able to prove them.
Agents made this easier, not harder, which surprised me. A human under deadline shortcuts provenance and promises to backfill it; the backfill never comes. An agent does whatever the write path permits, with perfect consistency. So if the only write path attaches the document link, every row has one, forever, including the rows written at three in the morning by a session nobody watched. Governance by schema has the property that governance by policy never achieves: it does not degrade when nobody is looking, because it was never being upheld by looking in the first place.
That is the whole design, and it echoes the place this series started. Do not ask whether the agent will respect your data. Ask what the schema lets anyone do to it on the worst day, and make the answer boring.