# Review gate example

Input: a proposal with a stable ID, an action, a target record and a reason; an allowed-action list; and an explicit approval for a proposal ID.

Rules:
- The proposal must identify the action, record and reason.
- The action must appear in the allowed-action list.
- The approval must name this proposal and say approve.
- Reject, missing approval or mismatched IDs block eligibility.

Output: an eligible/blocked result and the checks that explain it. Never perform the operation from this example.

Boundary: this browser exercise is not an authorization service. A deployed service must authenticate the reviewer, recheck the latest state and policy, bind approval to immutable proposal content, and prevent replay. The Enterprise Lab performs its approval checks at a separate endpoint.

---

From Curious Current · A proposal is not permission
Format: Runnable fixture + specification
Evidence: Executable teaching example of a review gate. All checks run locally; no operation is dispatched or written.
Source: https://curiouscurrent.com/lab/support-intelligence/?scenario=queue-triage

Free to download and adapt. Review and test changes in your own environment.