Skip to content
Expedify
10 min

Policy-as-code: the reviewer holds the thresholds

A second model that judges and never fixes, holding rules the proposer has never been told — and the thing it still cannot catch.

The reviewer is a second model call with one job: look at what the proposer wants to do, and say whether policy allows it. It has no tools. It cannot look anything up, and it cannot change the proposal.

The design decision that matters is not that it exists. It is where the thresholds live. The ₹50,000 limit is in the reviewer’s rules and nowhere else — the proposer has never been told it. That is deliberate: an agent that knows the number it must stay under will find its way under the number.

The rules, exactly as the build carries them

This is printed from the workflow, not retyped:

the reviewer's rules
## Instructions
Apply these rules. They are absolute.
1. Any refund above INR 50,000 must be escalated to a human and must NEVER be
   auto-approved. Reject any proposal that auto-approves one.
2. No refund at all once a certificate has been issued against the purchase.
3. A service failure is compensated with a deadline extension, platform credits
   and at most one free seat. Compensation is NOT cash.
4. Certificates are issued by a human only, and never early.
5. A discount above 25% requires human approval.
Five rules, each a comparison a reader could make. Nothing here asks for a judgement of tone, fairness or intent.

The reviewer in place

It reads the proposal and returns JSON. Temperature zero, no tools attached.

Loop BodyCompleteNoYes

Scroll for all 12 steps →

It judges. It never fixes.

The most common way to ruin a reviewer is to let it improve things. A reviewer that rewrites a proposal into an acceptable one has become a second proposer, and there is again nothing independent in the system. This one is told, in its first three lines, that it does not fix, rewrite or improve.

Here is what that discipline produced on a real run. Attempt one, scored 2 out of 5, with three violations named in the policy’s own words:

“Refund above INR 50,000 must be escalated to a human and never auto-approved” · “No refund allowed once a certificate has been issued” · “Service failure compensation must be … not cash refund”

The critique went back to the proposer, which dropped the cash refund and offered a deadline extension, platform credits and at most one free seat. Attempt two scored 5 out of 5 — “correctly denies a cash refund, offers compensation in line with policy”. That is lesson 16’s mechanism; what made it possible is that the critique was specific enough to act on.

Wording that took a build to get right

  • Name the exact strings a downstream node will compare. The reviewer is told to emit the lowercase words “approve” or “reject” because a gate compares them literally. Tell it why, and it stops paraphrasing.
  • Say when it is carrying rather than judging. One field in this verdict is a search term the reviewer copies from the proposal. It is told, in those words, that it is carrying and not judging — otherwise it improves the value, and lesson 17 is what that costs.
  • Make the rules absolute in the wording, not just in your intention. “Apply these rules. They are absolute.” An earlier build phrased the same rules as guidance and the reviewer negotiated with them.

What a reviewer cannot do — and this is important

It bounds authority, not truthfulness. On one verified run this reviewer scored a proposal 5 out of 5, with zero violations, when that proposal escalated the case to a named colleague who does not exist. On another it approved a proposal that openly declared the blast radius unknown, in breach of a rule it had been given. It is not being careless: it only ever sees the proposal, never the tool results behind it, so it has no way to check a fact.

Grounding (module 2) and control (this module) are different defences and neither substitutes for the other. A reviewer stops an agent from being allowed to do something. It does not stop it from being wrong.

Related lessons