How the reviewer gate works

The reviewer gate is the architectural boundary between the reasoning core (L2) and the customer’s data path (L4). It is not a UI affordance and not a confirmation dialog. An output without an approval record in the audit log has no path across the boundary, regardless of which surface the operator is on or which permissions the application layer believes are in place.

What the gate enforces

Nothing reaches the customer’s systems without an approval record. The gate is below the application layer, not inside it.

Before any Yig output writes to the customer’s systems, the audit log at L3 must contain:

• A draft identifier — a stable reference to the specific output presented for review.
• A reviewer record — the name and identifier of the person who reviewed it.
• A reviewer action — accepted, rejected, or accepted-with-edits.
• A timestamp — when the action was taken.
• A diff — the change between the draft and the approved version, if the reviewer made edits.

If any of these are absent, the output remains a draft. It does not ship.

This is enforced at the architectural layer. It is not a setting that can be relaxed. There is no “skip review” mode, no “auto-approve if confidence is high” toggle, and no administrative override that allows an output to ship without a reviewer record.

What “reviewer” means

A machine-generated approval has no audit value. A named human’s signed approval has all of it. The two are not interchangeable.

A reviewer is a named, authorised human, provisioned outside the agent’s runtime — so “the agent did it” is never a sentence the agent gets to write about itself. Authorisation is explicit, not inherited from role membership alone. The operator assigns which humans are authorised to review which workflows.

A reviewer cannot be an agent. A reviewer cannot be a scheduled job. A reviewer cannot be the same session that produced the draft.

The audit value of a reviewer record comes from a specific human, on a specific date, making a specific judgment about a specific output. We do not pretend a machine-generated approval has any of that.

Approval records persist; the agent’s working state does not. The reason that pairing is structural is set out in what we don’t cache and why: the gate’s record is one of the few pieces of state an external reviewer can verify.

What happens when a workflow completes without approval

When the agent finishes drafting and no reviewer approves, the output is logged as a draft and held. It does not time out. It does not auto-approve. It does not silently discard.

The draft waits until a reviewer acts on it. If the draft is superseded — because the workflow is run again — the original draft is marked as superseded in the audit log, not deleted.

This means every draft is traceable. An auditor can see every draft that was produced, every draft that was approved, and every draft that was rejected or superseded.

The gate and the yellow flag

The yellow flag surfaces uncertainty; the gate enforces approval. They are not the same component, and one cannot substitute for the other.

The yellow flag (see The yellow flag) marks sections of a draft where the agent’s confidence is below threshold. It communicates uncertainty to the reviewer. The reviewer decides how to resolve the flagged sections before approving.

The reviewer gate enforces that approval happens. It does not know or care whether any flags were raised. It requires only that a reviewer record exists.

Together: the yellow flag ensures the reviewer sees where judgment is needed; the gate ensures the reviewer acts before anything ships.

What the gate records are used for

The reviewer gate records are the primary evidence of human oversight in a Yig run. They are designed to be sufficient — without access to the agent runtime — for:

• An internal controls review by the finance team.
• An external audit of the close process.
• A compliance spot-check by a security or governance team.
• A post-incident investigation if an output turns out to be wrong.

The record answers the three questions every audit wants answered: what was produced, who reviewed it, and what did they decide.

What the gate does not do

The gate does not validate the correctness of the output. The reviewer validates correctness. The gate records that validation happened.

The gate does not restrict who can run a workflow. Running and reviewing are separate authorisations. An analyst can run a workflow that only a controller can approve.

The gate does not guarantee the reviewer read every line. That is a question for the organisation’s review procedures.

The organisation’s review procedures live above the gate; the gate lives below them, immovable. Any review process the audit lead wants to run sits on top of the gate’s record. None can substitute for it. If a close cycle ever ships an output without a reviewer record, the architecture failed — and that is the failure the architecture is designed to prevent.