AI & Governance
9 min read · Aug 12, 2026
Every system we build gets a human checkpoint before anything ships, executes, or gets published — not because the tech can't be trusted, but because accountability shouldn't be automatable. Here's how we design for that, concretely.
PROJECX Product & Governance Team
Published Aug 12, 2026

Illustration — PROJECX
{ 01 }
Models are good at sounding certain even when they're wrong, and the systems built around them inherit that confidence by default. A drafted email reads as sent. A flagged listing reads as removed. A summarized incident reads as resolved. If the interface doesn't force a visible gap between “the model produced this” and “this is now true,” that gap disappears in practice — and the first time it matters is usually the worst time to notice.
So before we design any feature, we ask a blunter question than “is the model accurate enough?”: what happens the one time in a hundred it's wrong, and who is standing between that output and the real world?
{ 02 }
A checkpoint isn't a warning label or a line in the terms of service — it's a specific point in the product where a person has to look at something and choose, and the system can't proceed without that choice. Concretely: the model's output is shown as a draft, never auto-submitted; the reviewer sees the evidence behind the conclusion, not just the conclusion; and the action being approved is named in plain language, not buried in a confirm dialog.
CHECKPOINT — MADHMOUNNOW
Every enforcement action MadhmounNow recommends is drafted, evidenced, and queued — never sent. A named reviewer at the regulator confirms it before it goes out.
{ The system can recommend. The system can draft. The system can flag. It cannot decide — that’s the line we don’t let it cross, on anything we ship. }
{ 03 }
A checkpoint that only says “approve or reject” is a rubber stamp waiting to happen — reviewers stop reading carefully once the system is right often enough. So we design for slower failure instead of faster approval: showing confidence honestly instead of rounding it up, logging who confirmed what and when so a decision stays traceable months later, and routing anything the model is uncertain about to a person by default, rather than requiring someone to notice it should have been.
CHECKPOINT — AUTONOMOUS INBOX
Anything the model isn't confident about doesn't get answered. It gets escalated, logged, and routed to a person at Hub71, the same day.
{ 04 }
Every checkpoint is a place where we could ship faster by removing a human step, and we've had that conversation with more than one client who wanted exactly that. We've said no more than once. A system that's occasionally wrong and always unsupervised isn't a faster version of the same product — it's a different, riskier product wearing the same name.
The teams we work best with are the ones who'd rather have a slower system they can stand behind than a fast one they'd have to explain. That's the trade we keep making — and it's the reason “AI never has the final say” isn't a slogan on our homepage. It's a constraint we design against, on every product, every time.
Written by
PROJECX Product & Governance Team
The people who design the review flows, audit trails, and escalation paths behind every product we ship — writing about the decisions that don't make it into the release notes.
Topics
Continue reading
Not a poster on a wall — the four calls we actually make under pressure.