Teaching an AI to govern itself, so it could build software that governs boards.

Or: what happened when we let Claude Code loose on our board governance product, and made it prove its work at every single step.

Here's a problem almost nobody talks about until it bites them: most small and mid-size companies run their board governance on vibes. A resolution gets "passed" in a meeting, someone edits a status field in a spreadsheet from Pending to Approved, and six months later, when an investor's lawyer asks who actually signed off on this, and when, and whether anything changed between the vote and the final version, the honest answer is a shrug and a scroll through old email threads. I've watched this exact scene play out more than once.

That's the problem we're building software to fix. And the last two days gave us a strange, kind of delightful case study in how we're building it. Because we didn't just write governance software. We accidentally ran an experiment in governing the process that writes governance software.

The cast of characters

We're building on Claude Code, Anthropic's AI coding agent, the kind of tool that's earned a reputation, fair, mostly, for "vibe coding": you describe what you want, it writes code, you eyeball it, ship it, hope for the best.

We don't do that. Instead, everything routes through a product governance platform called Ceetrix, best described as an extremely strict project manager who has read every contract law textbook and refuses to let anyone leave the room. Before a single line of code gets written, Ceetrix demands: what problem are we solving (the PRD), how exactly will we solve it (the design), what specific pieces of work does that break into (the tasks), and, critically, what tests prove each piece actually works. It won't let you mark anything done unless that whole chain traces back cleanly to a real requirement. No vibes allowed.

So Claude Code doesn't get to freelance. It gets to build, but only against a spec it can't quietly reinterpret, and it has to show its work: actual test results, actual evidence, actual "here's what I'd do differently next time" retrospectives, before anything is called finished.

Yesterday: unglamorous, and necessary

Yesterday we shipped two pieces that will never win a design award but that every real company needs: a settings screen where the team can choose which AI model powers different parts of the product, and a full admin system to invite teammates, assign roles, and, importantly, handle the reality of people leaving. When someone who owned a bunch of open risks or actions departs, the software doesn't just orphan their work. It makes someone explicitly reassign it. Small thing. The kind of small thing that, skipped, turns into "wait, whose job was this?" three months later.

Today: teaching the software to actually hold a board accountable

Today's centrepiece was the feature that gives the whole product its teeth: board resolutions, the formal, on-the-record decisions a board makes. Yesterday, in our own product, a resolution was just a status field anyone logged in could edit. Passed, pending, whatever you typed. Today, it became something closer to what a resolution actually is in the real world: a decision with weight.

Here's what changed, in plain terms:

• A resolution now moves through real stages, Draft, In Review, Approved, Rejected, and can only move forward the way a real vote would.
• Getting to Approved requires two separate people to sign off, specifically the board chair and the founder, not the same person wearing two hats. We call this segregation of duties. If anything about the resolution, its wording, its owner, its decision date, changes even slightly between the first signature and the second, the system catches it and makes them both sign again. No editing a resolution after someone's already approved it and hoping they don't notice.
• Once something is Approved, it becomes permanent. You can't edit it. You can't delete it. The only way to change your mind is to formally supersede it, which creates a brand new draft resolution, visibly linked back to the one it's replacing, with a timestamped record of exactly who did that and why. It's the difference between quietly rewriting history and crossing something out in ink where everyone can still read what it used to say.
• Resolutions can now link to the actual risks, actions and decisions they relate to, so a resolution never floats in isolation, disconnected from the reality it was supposed to address.

None of this is flashy. All of it is exactly what makes the difference between "we have board minutes" and "we have a governance record an actual auditor, acquirer, or investor's lawyer could rely on during due diligence."

How it actually got built

Before any of this touched real data, it was tested four different ways: does the underlying logic work in isolation, does it work when it actually talks to a database, does it work the way a person clicking through the screen would experience it, and does the entire story, draft, submit, approve, approve again, supersede, work end to end as one continuous sequence. Then, before calling it done, it was driven against a real, temporary copy of the actual database, with real login sessions, clicking through the real workflow. Not a simulation.

At every single point where Claude Code could have taken an irreversible action, it stopped and asked first. Before committing the code. Before pushing it anywhere. Before touching the production database. Before deploying it live. Not because it couldn't technically do those things unsupervised, but because that's the actual point of the whole exercise: an AI that will happily go fast right up until the moment an action can't be undone, and then puts the pen back in your hand.

At one point, applying the database update to production failed with a cryptic cloud-provider authorisation error, the kind of message that makes your stomach drop for a second. Turned out to be nothing: a one-off network blip. Retried it thirty seconds later and it went through clean. I mention it because it's a fair reflection of the whole build. This is not magic, and it is not fragile either. It is just software, being careful.

Why this is the whole point

There's a real irony in building governance software, a tool whose entire job is to force decisions to be made carefully, on the record, reversible only through a visible formal process, using a development process that does exactly that to itself. Every requirement traced to a design. Every design traced to real tasks. Every task closed out with actual test results and an honest note on what to do better next time. Every risky, hard-to-undo action stopped for a human yes.

There's a lesson in there that has nothing to do with AI specifically. The quality of work, whoever or whatever is doing it, goes up the moment you refuse to let "done" mean anything less than "here's the proof." That was true before AI could write code. We were proud of this hygiene in every company I've helped found or been part of. It's still true now that AI can write the code. The tool has changed. The discipline hasn't, and shouldn't.

Tomorrow we start on internationalisation: the feature that lets users in multiple countries use the platform in their own language and currency. I'll tell you how that one goes too.

Following along? This is part of an ongoing build log for PoseidonGrooveAI's governance platform, built in the open, mistakes included.