Worked example · the review gate

Nothing is done because the AI says it is.

The Hub is one board holding every project I work on and every job inside them, with a chat into each project's AI right there. That part is convenience. The part that matters is what it refuses to do: a piece of work cannot be marked done by the thing that made it. Something else has to check it first, and that check leaves a record.

The short version

I write down the job
What I want, in plain words. Every project's jobs sit on the same board.
The AI plans it, then builds it
Fenced into that one project and nothing else on the machine.
Something that didn't build it checks it
A test runs on its own, then a second reader goes over the change.
Only then is it done
And actually shipping it is still a separate decision I make.

What actually happensFive words, and a job can't skip one.

It starts as a job, in my words
A title and a description of what I want. That's the whole interface. I can type it straight into the board. Until anything else exists, the job sits in the first word: draft.
Once it moves, I can't quietly rewrite what I asked for
The board will only let me edit a job while it's still a draft. The moment a plan exists, editing it through the board is refused outright. That sounds petty until you've watched someone move the goalposts after the fact. Including yourself. What I asked for stays on the record, so the finished work can be measured against it.
A plan gets written before any code does
The AI writes down what it intends to do and how it will be checked, and that plan is a file I can read. A job with a plan and nothing else reads as planned. Nobody has changed anything yet.
The AI writes the code — inside a fence
Every single action it takes is checked before it happens, against a list of what's allowed. Anything not on that list is refused by default. It can read and edit files inside that one project and nowhere else; it can't reach my keys or my logins, can't install anything system-wide, can't call out to the internet except a short list of package sources, and can't push anything anywhere. When a job has a build report, it reads as built, and built is not done.
A check runs on its own and leaves a receipt
The plan has to say how the work will be proven. That gets run as a real command, and its result is written to a file: passed or failed, and whether the thing it ran finished clean. The board reads that file. It does not read anyone's opinion of how it went. A job only reads as checked when that file says it passed, a failure leaves it sitting at built, visibly.
Then something that didn't build it reads the work
This is the step the whole thing is built around. The reviewer is a separate pass, started fresh, and it's told not to take the build report's word for anything: read the actual change, re-run the check yourself. The reason is simple and it applies to people too. Whatever reasoning produced a mistake will also explain the mistake away. For anything security-related, or anything the first reviewer couldn't settle, the question goes out again to an AI from a different company, on the grounds that two models from the same family tend to be wrong in the same direction.
It also checks whether the check was worth anything
A test that can't fail is worse than no test, because it produces a green tick for free. So the review looks at the check itself: if it passes no matter what, or fails without saying why, that's recorded as a problem with the check, not just with the code. And a pass on its own is never enough to ship. The work still has to do what the job asked for.

Doesn't hold up
It goes back to be built again, with the specific findings attached. The job does not advance.

Holds up
The review is written down and kept next to the work, and the job finally reads as reviewed.
Done is a thing on disk, not a status someone set
The board never asks anything how it's going. It works that out from what's actually there: a plan file, a build report, a passing result, a written review. Nothing can announce itself finished. It either left the evidence behind or it didn't.
Shipping is a separate decision, and it's mine
A clean review doesn't release anything. It hands me the command and stops. Merging is a deliberate step I take, and even then nothing gets pushed anywhere without me saying so. Same principle as the review gate, one level up: the thing that decided it was ready isn't the thing that lets it out.

What "done" actually means here

Most dashboards let you drag a card to Done. This one won't, and that's the point. Everything below is checkable. It's worked out from what's actually there, not from anybody's say-so.

Five words the board is allowed to say

A job moves through five words, in order: draft, planned, built, checked, reviewed. Each one has to be earned by something real turning up, a written plan makes it planned, finished work makes it built, a test that passed makes it checked, a written review makes it reviewed. There's no button for any of them.

There are four more I can set myself, and they're all admissions rather than wins: blocked, shipped, abandoned, superseded. There's no word that means "the AI said it was fine."

Passed means a test actually ran

A check only counts as passed if the test it ran finished clean. Anything else is a fail, and the board shows it as one. That's the difference between "it says it worked" and "it worked", and it's the whole reason I trust a board full of work I didn't do by hand. I'm never reading a report written by the thing I'm asking about.

What it can't touch while it's working

Everything the AI tries to do gets checked before it happens. Some things are refused no matter what: getting at my saved passwords, taking charge of the whole machine, installing things everywhere, sending work out to the internet, or going online at all beyond a short list of places it's allowed. I can't wave those through by approving them, because they get checked before any approval does. Underneath that, it's fenced into the one project it's working on. Anything outside the fence is refused, even when the request is dressed up to look ordinary.

And it fails the safe way. If the guard breaks, gets confused, or sees something it doesn't recognise, the answer is no. The AI won't even start working unless that guard is confirmed switched on, no guard, no work.

It's still being built, and I'd rather say so

I use this every day and it changes most weeks. Today the fence is about what the AI is allowed to ask for, a locked room it physically can't walk out of is designed, but not built yet. The board can't move a job along by itself either. The only thing it ever writes into a project is the words I typed.

What's coming is mostly about handing over a little more rope, carefully: granting wider permission on purpose for one particular job, instead of the single flat rule everything lives under today, and being able to add to and edit the smaller jobs the AI breaks the work into, rather than only the one I wrote. It's a tool I'm actively building, not a finished product, and I'd rather show you something that moves every week than a screenshot of something that stopped a year ago.

The same shape, in a business

Strip out the code and the pattern is this: work isn't finished because the thing that produced it says so. Something independent looks first, and what it found is written down where you can read it. That's not process for its own sake. It's the only honest answer to the question everyone actually has about automation, which is: how would I know if it got it wrong?

Point that at an invoice run and it means no invoice leaves until the totals have been checked against the source by something other than whatever generated them. Point it at your inbox and it means a reply is drafted and held, not sent, until it's been read against the rule it was supposed to follow. Point it at a quote and it means the pricing gets verified before the customer sees a number. Same rule every time, and when a check fails, the work sits there visibly unfinished instead of quietly going out wrong. It's the same idea as I automate the work, not the accountability — the gate exists so someone stays answerable for what goes out.

Interested in something like this? If there's something you keep doing by hand, let me know and I'll tell you what it would take to automate — the work moves to the AI, the accountability stays with you. And if it isn't worth building, or if something off the shelf would do it better, I'll tell you that instead.

Tell me about it

Running a business and suspect there's more than one of these in your week? The diagnostic is built for exactly that.