Verified AI work

The agent that does the work shouldn't grade it

Self-assessment by a language model is not a check. It is the same reasoning that produced the work, asked a second time in a friendlier tone.

5 min readVerified AI work

Ask a model to produce something, then ask the same model whether it is good. It will say yes. It will say yes with reasons, and the reasons will be plausible, and the whole exchange will feel like quality assurance while containing none.

This is not a flaw in any particular model. It is what happens when the checker shares the producer's assumptions, its blind spots, and its interpretation of the task.

What you’ll learn

  • Why self-review inherits the original error
  • The separation rule, and where it has to be strongest
  • What a verifier needs that a producer does not have
  • Why rejection has to be a real outcome

Self-review inherits the error

Consider the ways work goes wrong. It can be internally inconsistent, factually wrong, or wrong about what was being asked.

A model reviewing its own output catches the first category reasonably well. Internal inconsistency is visible in the text.

It catches the second category unevenly, because the same knowledge gaps that produced a wrong fact will also fail to flag it.

It essentially never catches the third, and the third is the expensive one. If the producer misread the task, the reviewer — being the same reasoning, holding the same reading — will assess the work against the misreading and find it excellent. The output is a coherent, well-executed answer to the wrong question, accompanied by a confident self-assessment.

Important: The most costly AI failures are not incoherent. They are coherent, well-formatted, and about something adjacent to what you asked for. Coherence checks cannot find them, and self-review is mostly a coherence check.

The separation rule

The rule Brainis holds: the producer of a deliverable never solely verifies it, and high-risk work uses a different model family.

Two clauses, doing different jobs.

Never solely verifies. The producing agent may self-check, and self-checking is useful for cheap classes of error. It cannot be the last step. Something else has to sign off before the work counts as done.

A different model family for high-risk work. Two instances of the same model share more than parameters. They share training data, tokenisation, and characteristic failure modes. For high-risk work, the second opinion has to come from a genuinely different lineage, or the correlation between the two judgments is high enough that the check adds little.

This is the same logic behind not letting an author copy-edit their own book, extended one step further: not letting an author's identical twin, raised on the same books, do it either.

What a verifier needs

Independence is necessary and not sufficient. A verifier also needs three things the producer does not.

The criteria, not the intent. The producer works from intent, which is interpretable. The verifier works from acceptance criteria, which are checkable. Independent quality agents verify work against acceptance criteria and can reject it — the criteria being written before the work started is what makes the check meaningful rather than aesthetic.

Access to the state, not to the reasoning. Give the verifier the producer's chain of thought and you have reintroduced the correlation you were trying to break. Give it the deliverable and the state of the world, and it evaluates the artefact rather than the argument for the artefact.

Authority to reject. A verifier that can only annotate is a commentary layer. Rejection has to stop the work from counting.

Your own acceptance criteria become verification checks — authored once, composed into libraries, enforced per domain. This is the part that turns verification from a generic quality gate into something that knows what your company means by good.

Rejection has to be real

The failure mode of every quality layer is that rejection becomes advisory, then becomes a warning, then becomes a colour on a badge that nobody reads.

Three properties keep it real.

Done means verified. Work is not done until it is verified, and unverified work does not appear anywhere as complete. Not "complete, pending review" — that state is where things go to be forgotten.

The seal pins the revision. The verified seal renders only for the exact revision that was checked. Changed work shows "verified at rev N, changed since" rather than a stale seal. A seal that survives an edit is worse than no seal, because it certifies something that is no longer there.

Findings land on exact lines. A rejection that says "quality issues" produces an argument. A rejection that says "this line contradicts the criterion, here" produces a fix.

What independence means when both are models

A fair objection: if the verifier is also a model, what exactly has been separated?

Three things, and each is worth stating because "independent" is otherwise a word doing no work.

Different lineage. Different training data and different architecture produce different failure modes. Two models from the same family agreeing tells you less than two from different families agreeing, because the first pair's errors correlate.

Different inputs. The producer sees the intent and the tools. The verifier sees the artefact, the state, and the criteria — not the producer's reasoning. Withholding the reasoning is deliberate: an explanation of why the work is right is persuasive to a reader, and the verifier is not supposed to be persuaded.

Different objective. The producer is optimising for a deliverable. The verifier is optimising for finding the criterion that fails. Those are not the same task wearing different labels, and the asymmetry is what makes rejection a normal outcome rather than an exception.

None of that makes the verifier correct. It makes it wrong in different ways than the producer, which is the entire value of a second opinion in any field.

The cost, honestly

Independent verification costs more. Two model calls where there was one, plus the work of writing criteria before starting, plus the friction of work that gets rejected and has to be redone.

It is worth it for a specific reason: without it, autonomy has no ceiling you can trust. Every step up the autonomy ladder is a step further from human review of individual outputs, and the thing that has to take up that slack is a check that does not share the producer's blind spots. A company that skips this can still use AI to draft. It cannot safely use AI to act.

The verification layer is on Verify, the agents and what governs their access are on the agent fleet, and evidence graphs covers what a verification leaves behind once it passes.

Verified AI workVerify

Brainis Team

Notes on the company loop — company state, decisions, governed autonomy and verified work — from the people building Brainis and running on it.

Bring Brainis the company you want to build.

Start from an idea. Connect what exists. Either way, leave with the next move — and a system that delivers it.