The grader

Most review steps cannot fail. The person who did the work decides when it is done, writes the description of what done meant, and hands both to a reviewer who now has no independent standard to check against. The review is real work by real people, and it still cannot come back negative in any way that costs anything, because everything it would need to disagree with was authored by the thing it is reviewing.

The grader takes the standard out of the hands of the work. Criteria are written before the work starts, by someone other than whoever will grade against them, and the grader can record a verdict but cannot touch what it is grading against. That constraint is the whole shape. A grader that can edit its own criteria is a formality with extra steps.

It answers questions about a real permission matrix: which roles exist, what each one may do, which abilities belong to exactly one role, and who may perform a given action. Every answer comes from a tool call you can watch it make.

Watch for one distinction in particular. Asked about something that does not exist, it will tell you the action is absent rather than that nobody is allowed to do it. Those two answers sound alike and mean opposite things — one is a typo, the other is a security property — and an agent that blurs them will eventually report a misspelling as a guarantee.

It also has no tools for history: it can tell you who is permitted to record a verdict, but not what verdicts were recorded. Ask it for that and it will say so plainly rather than improvising, which is the behaviour worth having.

The matrix is not a diagram we drew for this page. It is derived from the public role definitions of the delivery plugin that builds our work, by reading the tool list declared in each file. The files are checksummed when they are read, so the matrix and its source can be shown to correspond.

The agent was built with these tools:

• list_roles

  List the three agent roles the delivery system defines — planner, engineer, verifier — with what each is for and how many catalog actions it holds. Use this first when a visitor asks what the roles are or how the system is organised.

• who_can

  Given a catalog action such as record_evaluation or create_acceptance_criterion, return exactly which roles are permitted to perform it. This is the tool that answers separation-of-powers questions. Returns null when the action does not exist, which is different from no role being able to do it.

• role_actions

  Every catalog action one role may perform, and a link to the public file the list was read from. Use this to show what a role can and cannot do. Returns null for a role that does not exist.

• exclusive_actions

  The actions only a single role may perform. This is where the separation actually lives — an action two roles share constrains nobody. Use it when asked what stops a role from marking its own work complete.

• render_chart

  Draw a small chart of figures ALREADY RETURNED by another tool in this same turn, when a picture makes the answer clearer than a list — comparing several values, or showing a sequence. Call your data tools first; this tool reads no data of its own. Every value is checked against what those tools returned and the chart is refused if a figure cannot be found among them, so use returned figures exactly and never round, scale or estimate them. Needs at least two points. Use "bar" to compare labelled things and "line" only when the points are in a genuine order, such as time. The chart supplements your written answer; it never replaces it.

This is the same separation we run on ourselves, which is why it was available to demonstrate. The agent that verifies our work against acceptance criteria is not able to write or change those criteria; the agent that writes them does not grade. You can confirm that in the files above without taking our word for any of it — and the agent to the right will tell you the same thing, from the same source.

The shape transfers wherever a standard is supposed to constrain the work but is held by whoever is doing it. Change approvals, deployment permissions, expense sign-off, clinical or safety review, vendor assessments — anywhere the check exists on the org chart and the authority to move the goalposts sits on the same desk.

The work is the same three pieces:

• — criteria recorded before the work starts, where they can be read by everyone
• — a grader with the authority to record a verdict and no authority to change the standard
• — a trail that shows what was judged, against what, and when it was written

The honest test of whether this fits you is not technical either. It is whether anything has ever been marked done that everyone quietly knew was not, and whether the review step that let it through would have been able to stop it if it had tried. If the answer to the second part is no, the review is not the problem — the arrangement is.

• — Expense claims arrive already checked against the written policy, with the clause a claim failed named rather than flagged, so the review is the exceptions instead of every line.
• — A supplier onboarding pack is checked against your requirements before anyone opens it, so the review starts from what is missing rather than from page one.
• — An incoming contract is checked against your fallback positions, and what you see first is which clauses depart from them and how far.
• — Before a proposal leaves the building it is checked against the things you have said every proposal must carry — the pricing basis, the assumptions, the exclusions — by something that did not write it and cannot decide this one is close enough.