Automated review steps: what finds problems and what approves them

A review step does one of two things. It finds: it reads a change, runs a check, and reports what looks wrong. Or it approves: it takes responsibility for letting the change go. Automation can find tirelessly, at any hour, across everything you point it at. It cannot be accountable. An approval is a decision made by a named person who can be asked why, so an automated step should feed that decision and never replace it.

We keep the two apart on purpose. A finding is cheap to produce and cheap to dismiss, so we want plenty of them and we want them to carry evidence. An approval is expensive and rare, so we want it to be deliberate and recorded. When a step blurs the two, for example an AI reviewer whose pass counts as sign-off, we call it automated QA and we do not call it approval.

Most entries in our website gate ledgers are manual evidence rather than runnable commands. Only a handful of gates carry a command that a machine can re-run. That is useful as a record of what a person checked, and it is weaker than it looks, because nothing re-verifies it later. Likewise, none of our hosted CI jobs run the website tests or the build checks. We run those locally.

Our content pipelines are defined as Swfte workflows with an AI fact-check reviewer and no human step. That is automated QA, not approval, and we have no evidence in the repository that they are running today. In our Cortex application repository, hosted CI stopped running for a period and we ran the same gates locally from one script. An AI pull-request review workflow exists there, but we have no posted review on record, so we claim nothing about it.

Nexus puts two kinds of gate around a coding agent. The first is a policy gate on each tool call. It runs on the machine, in the middle of the agent's work, and answers allow, deny or ask. You can run it in an audit mode first and move to enforcement once you trust the rules. The second is the completion gate, run with the nexus gates command, which checks that the gates you wrote for a task have recorded evidence.

Inside Cortex, a chat assistant can call tools to start verification, read gate results and read the audit trail for a coding task. All of that is built in the product. We use completion gates ourselves, as described above. We do not claim that Nexus gates are the thing standing between a pull request and our main branch. A gate finds that a rule was broken. Who accepts the change is still a person.

Start with checks that fail loudly and never need judgement: a build that stops when a rule is broken, a scan for leaked secrets, a test that must pass. They are cheap, they run every time, and they teach the team to trust a red result. Then add read-only review of changes, where an agent reads a diff and reports numbered findings with evidence. Only after that consider anything that looks like a decision.

Resist the temptation to start with an automated approver. The value of a review step is in the problems it finds early, and the value of an approval is that someone owns it. If you automate approval before you have good findings, you collect sign-offs that nobody would defend. If you have good findings and a person who reads them, you can decide later which low-risk approvals to delegate, under limits.

This is how we would review a pull request that changes an approval flow. It is design intent, not a description of a review we have run. A read-only agent reads the diff and produces numbered findings: a check that could be skipped, a path with no recorded decision, a test that cannot fail. Each finding names the file and the evidence behind it.

A person then triages the findings, closes the false ones with a reason, and asks for fixes to the rest. Each fix gets a line in a closure table. The gates run, including the build checks, and a second person approves the merge, because the change touches approvals. If we have a real example from our own work, it will replace this one: <real example of an AI-assisted review catching a defect - founder to fill>.

A person decides which findings matter and which are noise. A person accepts a risk, or refuses to, and records why. A person approves the merge and the release. A person decides whether an automated step is trustworthy enough to rely on, and reads its failures when it is not. In our own practice, some decisions are reserved to the owner outright, and the page on approvals describes them.

Nothing here lets a reviewer, human or automated, approve its own work. The reviewer that wrote the code should not be the one that clears it. That separation is a design aim, and the platform does not yet enforce it as a rule, so for now it lives in how a team is organised.