# Human Review Checkpoint Guide ### Guide Identify where accountable human review must remain visible. --- ## Purpose AI-assisted work fails quietly when no one defined where a human must check it before it goes out. This guide sets the criteria for placing a review checkpoint, and the minimum definition every checkpoint needs to actually function rather than exist only on paper. --- ## When to Add a Human Review Checkpoint Add a mandatory human review checkpoint whenever an AI-assisted output meets any one of the following five conditions. One condition is enough. Do not require all five before adding a checkpoint. ### 1. The output makes a decision affecting a customer, learner, employee, or client Any output that determines what a person receives, is told, is charged, is offered, or is denied requires review before it takes effect. This includes eligibility decisions, pricing, scheduling, access, and personalized recommendations. ### 2. The output includes factual claims, recommendations, or legal, financial, or health-related guidance Any output presented as fact, advice, or guidance in these categories carries direct risk if wrong. Review here means verifying accuracy and appropriateness against a known standard, not just checking tone. ### 3. The output uses private, sensitive, or client-owned information Any output drawing on personal data, confidential business information, or material owned by a client or third party requires review for appropriate use and disclosure, separate from review of the content itself. ### 4. The output represents your brand voice or professional judgment Any output that will be read as coming from your organization, a named professional, or a named team, in a client-facing or public setting, requires review for tone, accuracy, and consistency with how your organization actually communicates. ### 5. The output could create harm if inaccurate, incomplete, biased, or misunderstood This is the catch-all condition. If a wrong, partial, skewed, or easily misread version of this output would cause real damage, financial, reputational, legal, or personal, the checkpoint is required even if the first four conditions do not clearly apply. --- ## What a Checkpoint Actually Requires A checkpoint that exists only as a line in a process document does not function. For every checkpoint you define, specify all four of the following. A checkpoint missing any one of these is incomplete. ### The Reviewer Name the person or role, not a department. "Marketing reviews it" is not a functioning checkpoint. "The content lead reviews it" is. If the named reviewer is unavailable, name the backup reviewer as well, in advance, not at the moment of need. ### The Standard Define what the reviewer is checking the output against: a style guide, a compliance requirement, a factual source, a brand voice document, a legal or safety threshold. A reviewer without a defined standard is applying personal judgment inconsistently, which produces inconsistent results even with a checkpoint in place. ### The Action on Failed Review State what happens when the output does not meet the standard. Options include: sent back for revision with specific notes, escalated to a more senior reviewer, blocked from release entirely, or logged and corrected before reuse. An undefined failure path means reviewers either block work indefinitely or wave it through under time pressure. ### The Exception Approver Name who has the authority to approve an exception, meaning output that does not fully meet the standard but is released anyway under specific, justified circumstances. If no one is named, exceptions get approved informally by whoever is under the most deadline pressure, which defeats the purpose of the checkpoint. --- ## Checkpoint Definition Template Use this for each checkpoint identified in your workflow. ``` Checkpoint: [name of the step or output being reviewed] Trigger condition(s): [which of the five conditions above apply] Reviewer: [named person or role] Backup reviewer: [named person or role] Standard used: [document, policy, or criteria referenced] Action if review fails: [specific next step] Exception approver: [named person or role] ``` --- ## Placing Checkpoints Without Slowing Everything Down Not every AI-assisted output needs the same depth of review. Match the checkpoint to the risk. - **High-risk outputs** (customer-facing decisions, legal or financial guidance, sensitive data): full review against a documented standard, every time, no exceptions without named approval. - **Medium-risk outputs** (internal recommendations, draft client communications before send): review before release, but review can be lighter and faster if the reviewer trusts the source material and the person who generated the draft has a track record. - **Low-risk outputs** (internal drafts, brainstorming, first-pass research that a human will substantially rework): a checkpoint may not be needed at all if the output never reaches a customer, client, or decision point without further human work applied to it. Do not apply full review depth to every output regardless of risk. That produces reviewer fatigue, which is itself a failure mode. Reviewers under constant high volume start rubber-stamping, which is functionally the same as having no checkpoint. --- ## Common Mistakes - Defining a checkpoint with a role but no named person, so no one is actually accountable when something goes wrong - Defining a standard so vague ("make sure it sounds right") that two reviewers would reach different conclusions on the same output - Leaving the failed-review path undefined, so reviewers either block everything or approve everything under pressure - Placing the same checkpoint depth on every output regardless of risk level, which slows low-risk work and does not meaningfully improve safety - Never revisiting checkpoints after they are set, even as the AI tool, the task, or the risk changes --- ## Reviewing This Guide's Effectiveness [UNVERIFIED] Whether a specific checkpoint is working should be measured against your own data: the rate of errors caught at the checkpoint versus errors that reach the customer, client, or public despite it, and reviewer time spent per checkpoint. Set this baseline after the first month of use rather than assuming a target in advance. Revisit checkpoint placement whenever the underlying AI tool changes, the task's risk profile changes, or a failure occurs that the current checkpoint did not catch. --- ### Related WenceStudio Resources Connect your review checkpoints to measurable operating governance: 1. **The AI Dependency Audit: Governance Kit** (Governance Kit & PDF Guide) A governance starter kit for operational leaders. Includes the 4-layer guardrail model, provider dependency map, outage protocol, and 30-day rollout. - [Download Governance Kit (PDF)](https://drive.google.com/file/d/16sjOoJlmiLYFN4cFWIyDNOsKXehwXKJ4/view?usp=sharing) - [Open Source Document](https://docs.google.com/document/d/1XCBXjn2F7dMpXTNnFUY2odzuMJADkz_Gci39VyjiJdo/edit?usp=sharing) 2. **Useful Work Per Dollar: Custom-Agent ROI** (Executive Report & ROI Model) A 24-page research guide on measuring completed business outcomes, unit economics, dependability rates, and return on compute. - [Read ROI Whitepaper (PDF)](https://drive.google.com/file/d/1St1yw4nQ2EaZD_923UuiE28lbj4wdW-N/view?usp=sharing)