Human Approval Checkpoint

This entry has no operable specimen yet; the illustration is an editorial sketch. Before applying it to a product, still verify: whether the reviewer genuinely has the authority and grounds to reject, whether there is enough time to read the consequences, whether approvals and rejections are correctly written to an audit log, and whether high approval frequency produces approval fatigue that hollows out the checkpoint.

{
  "states": [
    "pending",
    "approved",
    "rejected",
    "expired"
  ],
  "a11y": [
    "The pending content presents its concrete consequences accessibly, not only through button labels",
    "Both the approve and reject controls are reachable by keyboard, and default focus is not placed on approve in advance",
    "State changes (pending, approved, rejected) are announced as text, not conveyed by color alone"
  ],
  "motion": "No emphasis animation is needed; appearance and dismissal can reuse the motion settings of whatever container hosts it (such as a modal dialog)"
}

{
  "id": "human-approval",
  "type": "interaction",
  "name": {
    "zh": "人工审批检查点",
    "en": "Human Approval Checkpoint"
  },
  "aliases": [
    "审批检查点",
    "人工确认关卡",
    "approval checkpoint",
    "human-in-the-loop checkpoint"
  ],
  "granularity": "flow",
  "intents": [
    "confirm-action",
    "require-approval"
  ],
  "tags": [
    "human approval",
    "checkpoint",
    "pause",
    "reversibility",
    "audit trail"
  ],
  "definition": "An explicit pause point set into an automated or agentic process: the system stops before taking an action with real consequences and hands the decision to continue to a person; the action only takes effect once that person approves it.",
  "boundary": "This is a concrete interaction mechanism, distinct from the philosophy-level question of whether human autonomy should be preserved at all — that is a design-goal tradeoff, while this entry only covers how the interface implements the decision point once preserving human control has already been decided. It is also not the same as a modal dialog: a modal dialog is just one blocking presentation form that anything requiring the person to deal with it first can use (such as collecting required information), and it does not inherently carry an 'approval' meaning; a checkpoint can be presented through a modal dialog, or through a non-blocking form such as a to-do item that only takes effect once clicked. Nor is it the same as the error-prevention principle: error prevention is about reducing the likelihood that mistakes happen at all, while a human approval checkpoint is only one concrete mechanism for realizing error prevention — introducing human judgment before an action takes effect — not the principle itself.",
  "signature": [
    "The action does not take effect until approved, and the process stays in a recoverable, paused state",
    "The checkpoint shows the concrete effect the action will have once it takes effect, not just the action's name or type",
    "Approving and rejecting are equally easy and equally clear on screen, with neither made more convenient than the other"
  ],
  "when": [
    "An automated or agentic process is about to take an action with real, hard-to-undo consequences",
    "The reviewer genuinely has grounds to judge the specific outcome and standing to say no, rather than rubber-stamping",
    "The action can wait for human review without missing a critical deadline or causing extra loss"
  ],
  "when_not": [
    "The reviewer has neither the time nor the expertise to judge the content, so signing off would only be theater",
    "The action is easy to undo, and real-time error prevention or after-the-fact auditing already covers the risk, so pausing only slows down routine work",
    "The same low-risk action is repeatedly sent for approval, producing approval fatigue that leads reviewers to click through mechanically"
  ],
  "tradeoff": "Buys the chance to catch a mistake before an irreversible or costly action takes effect, keeping a key judgment with a person, at the cost of slowing the flow down; if the reviewer never really sees the consequences, or approving is easier than rejecting, the checkpoint degrades into rubber-stamping theater — producing a false sense of safety rather than real oversight.",
  "comparison": {
    "focus": "Handing the decision to continue, before an action takes effect, to a person",
    "mechanism": "Pausing the process, showing the concrete consequences about to occur, and offering equally usable approve and reject exits",
    "cost": "Slowing down the flow, plus needing deliberate design to keep the reviewer from clicking approve without thinking"
  },
  "sources": [
    {
      "id": "hax-toolkit-library",
      "title": "Microsoft HAX Toolkit · Guidelines for Human-AI Interaction",
      "url": "https://www.microsoft.com/en-us/haxtoolkit/library/",
      "claim": "HAX guideline G16 (Convey the consequences of user actions) calls for making it easy for people to see what their actions will lead to, and G9 (Support efficient correction) calls for letting people efficiently correct or undo the system's wrong judgments; together they support requiring a checkpoint to show concrete consequences and keep an equally convenient reject path.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.microsoft.com/en-us/haxtoolkit/library/",
        "status": "available",
        "checkedAt": "2026-09-16T05:43:24.829Z",
        "jobId": "spn2-7cb34684fb905780ab4c35f6e41f0ec7680b9b7e",
        "url": "https://web.archive.org/web/20260916054347/https://www.microsoft.com/en-us/haxtoolkit/library/",
        "timestamp": "20260916054347"
      }
    },
    {
      "id": "copilot-boundaries-checkpoints",
      "title": "Microsoft Support · Design Copilot Boundaries and Checkpoints",
      "url": "https://support.microsoft.com/en-us/microsoft-365-copilot/design-copilot-boundaries-and-checkpoints",
      "claim": "The guide recommends identifying what will be shared, acted on, or automated, setting checkpoints for decisions that affect other people or commitments, and requiring human review before an agentic workflow carries incomplete information forward into the next step.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://support.microsoft.com/en-us/microsoft-365-copilot/design-copilot-boundaries-and-checkpoints",
        "status": "available",
        "checkedAt": "2026-09-16T05:44:25.107Z",
        "jobId": "spn2-c57115c93bd4062a42d1ab0063b5ec1b741ed1e4",
        "url": "https://web.archive.org/web/20260916054449/https://support.microsoft.com/en-us/microsoft-365-copilot/design-copilot-boundaries-and-checkpoints",
        "timestamp": "20260916054449"
      }
    },
    {
      "id": "eu-ai-act-article-14",
      "title": "artificialintelligenceact.eu · Article 14: Human Oversight",
      "url": "https://artificialintelligenceact.eu/article/14/",
      "claim": "Article 14 requires that the person responsible for oversight has the ability to decide, in a given situation, not to use, to disregard, override, or reverse the system's output, and to intervene in or interrupt the system's operation through a stop button or a similar procedure; this is the regulatory expression of the veto power a human approval checkpoint should preserve.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://artificialintelligenceact.eu/article/14/",
        "status": "unconfirmed",
        "checkedAt": "2026-09-16T05:44:26.310Z",
        "error": "save-request-failed"
      }
    }
  ],
  "relations": [
    {
      "target": "error-prevention",
      "kind": "realized_by",
      "condition": "The action has real consequences and a possible mistake needs to be caught before it takes effect",
      "reason": "A human approval checkpoint is one concrete way of realizing the error-prevention principle: it turns the goal of 'reducing the likelihood of mistakes' into an actual pause point in the flow that a person must pass through.",
      "basis": "editorial"
    },
    {
      "target": "modal-dialog",
      "kind": "composes_with",
      "condition": "The checkpoint needs to block the current flow through the interface to present the pending content",
      "reason": "Checkpoints often use a modal dialog to block the main flow and show the pending action, but a modal dialog is only one presentation form; the approval semantics, the equally available approve/reject exits, and the approval record are requirements of the checkpoint itself and do not go away just because the presentation form changes.",
      "basis": "editorial"
    },
    {
      "target": "trust-calibration",
      "kind": "composes_with",
      "condition": "The reviewer needs to judge whether this particular automated output is trustworthy, rather than waving it through unconditionally",
      "reason": "If the reviewer's trust in the automated result has not been properly calibrated, automation bias follows — approving without reading; the checkpoint needs to be designed together with trust calibration, or it collapses into a rubber-stamping ritual.",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "The checkpoint shows the reviewer the pending action",
      "instruction": "Present the concrete effect the action will have once it takes effect (for example, the content about to be sent, or the record about to change), not just the action's name or type.",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "The reviewer has to choose between approving and rejecting",
      "instruction": "Give the approve and reject controls equal visual weight, position, and click path; rejecting must not take more steps or be harder to find than approving.",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "The reviewer completes an approval or rejection",
      "instruction": "Log the specific content approved or rejected, the reviewer's identity, and the time, for later audit.",
      "strength": "recommend",
      "basis": "editorial"
    }
  ],
  "behavior": {
    "states": [
      "pending",
      "approved",
      "rejected",
      "expired"
    ],
    "a11y": [
      "The pending content presents its concrete consequences accessibly, not only through button labels",
      "Both the approve and reject controls are reachable by keyboard, and default focus is not placed on approve in advance",
      "State changes (pending, approved, rejected) are announced as text, not conveyed by color alone"
    ],
    "motion": "No emphasis animation is needed; appearance and dismissal can reuse the motion settings of whatever container hosts it (such as a modal dialog)"
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "This entry has no operable specimen yet; the illustration is an editorial sketch. Before applying it to a product, still verify: whether the reviewer genuinely has the authority and grounds to reject, whether there is enough time to read the consequences, whether approvals and rejections are correctly written to an audit log, and whether high approval frequency produces approval fatigue that hollows out the checkpoint.",
  "image": {
    "src": "/images/human-approval.webp",
    "alt": "A fictional FIELDNOTES automated task panel paused at a checkpoint, with a preview block of the pending change in the center, two equally weighted buttons side by side below it, and a small pause icon nearby."
  },
  "searchTerms": [
    "人工审批",
    "检查点",
    "暂停",
    "可逆性",
    "审计留痕"
  ]
}