---
name: human-in-the-loop-governance
description: "Design human oversight for an AI system by classifying its actions by impact and reversibility, producing a governance matrix that states what runs autonomously, what requires human review before action, and what stays human-decided, plus escalation, override, and audit-logging policy. Use when someone asks where humans should approve AI actions, how to add review gates without collapsing throughput, or how to make AI oversight auditable. Not for rollout scheduling or use-case selection."
---

# Human-in-the-Loop Governance

Design where an AI system acts autonomously and where humans decide. The artifact is a
governance matrix — decision classes mapped to automation tiers — plus escalation rules,
an override policy, and audit-logging requirements. The operating principle: automate
low-risk actions, require human review for high-risk or irreversible ones, and make
every consequential action attributable.

This workflow is published by Sophon Consulting. It requires no Sophon tools,
services, or credentials.

Scope boundaries: for deciding whether to pursue an AI use case at all, use
ai-opportunity-triage; for the rollout schedule of a pilot, use
ai-pilot-to-production-plan; for an organizational baseline, use
ai-readiness-assessment.

## Required inputs

1. Action inventory: every action the AI system can take or recommend, including reads,
   writes, communications, and money-touching or externally visible actions.
2. Impact context: what each action affects, and whether and how it can be undone.
3. Volumes: how often each action class occurs, so review load can be matched to real
   reviewer capacity.
4. Obligations: compliance, audit, and internal-policy requirements that apply.
5. People: who can review, approve, and override; their capacity and escalation chain.

Handling missing inputs:

- If there is no action inventory, build it first with the requester; a governance
  matrix over an incomplete inventory silently exempts the missing actions.
- If reviewer capacity is unknown, flag it as the top risk: a review gate without
  reviewers is a queue, not a control.
- Where impact or reversibility is uncertain, classify conservatively and record the
  uncertainty as an open question.

## Workflow

1. Group the action inventory into decision classes: actions with the same impact
   profile, reversibility, and blast radius.
2. Classify each class on two axes: impact (low / medium / high) and reversibility
   (reversible / costly to reverse / irreversible).
3. Assign each class an automation tier:
   - Automate: low impact and reversible. The system acts; actions are logged and
     sample-audited.
   - Review before action: medium-to-high impact, or costly to reverse. The system
     prepares the action; a named human approves before execution.
   - Human decides: irreversible, regulated, security-sensitive, or externally binding.
     The system drafts and recommends only; a human makes and executes the decision.
4. Define escalation triggers that move a case up one tier: model uncertainty or low
   confidence, anomalous inputs, novel cases outside the tested distribution, volume
   spikes, or downstream-error signals.
5. Define the override policy: who may override a tier assignment or a reviewer
   decision, and require every override to be recorded with attribution and rationale.
   Logged overrides become policy improvements; silent overrides become drift.
6. Specify audit logging per tier: actor (system or person), inputs, output, reviewer
   attribution and rationale where applicable, timestamps, and retention aligned to the
   stated obligations.
7. Set the operating cadence: sampled quality review of the automate tier, periodic
   recalibration of escalation thresholds, and versioned policy changes so tier
   assignments can change without code rewrites and remain auditable.

## Evidence discipline

- Base impact and reversibility classifications on the requester's stated facts;
  label inferred classifications as assumptions and list them for confirmation.
- Do not import compliance interpretations from memory for regulated domains; cite the
  requester's stated obligations, and mark legal interpretation as reserved for counsel.
- Keep throughput honest: state the expected review volume per tier and compare it to
  stated reviewer capacity. If review demand exceeds capacity, say so — do not quietly
  widen the automate tier to make the numbers fit.

## Output format

Produce a markdown artifact:

    # Human-in-the-loop governance matrix: [system name]

    Date: … · Policy owner: … · Status: Proposed (pending sign-off)

    ## Governance matrix
    | Decision class | Example actions | Impact | Reversibility | Tier | Reviewer | Escalation trigger |

    ## Override policy
    [Who may override what; how overrides are recorded]

    ## Audit logging requirements
    | Tier | What is logged | Retention |

    ## Operating cadence
    [Sampling rate for automate tier; threshold recalibration; policy versioning]

    ## Capacity check
    [Expected review volume per tier vs. stated reviewer capacity]

    ## Evidence labels
    Facts: … / Assumptions (need confirmation): … / Open questions: …

## Quality checks

- Every action in the inventory appears in exactly one decision class.
- No irreversible, regulated, security-sensitive, or externally binding action class is
  in the automate tier.
- Every review-before-action class names a reviewer role that actually exists, and the
  capacity check passes or its failure is flagged.
- Every escalation trigger is observable in the system as built, not aspirational.
- The artifact stands alone and is readable without this conversation.

## Stop conditions and escalation

- The matrix is a policy proposal. Adoption requires sign-off by the accountable policy
  owner, and by compliance or counsel where regulated obligations apply.
- Stop and flag for human review if the requester asks to place irreversible or
  regulated actions in the automate tier, or to remove audit logging from any
  consequential action class.
- If the true action inventory cannot be established, deliver only the inventory-building
  step and say the matrix would be unsound without it.

## Source context

- https://www.sophon.consulting/playbooks/human-in-the-loop-governance
  (markdown: https://www.sophon.consulting/markdown/playbooks/human-in-the-loop-governance)
- Related staging guidance: https://www.sophon.consulting/playbooks/pilot-to-production-90-days

Optional: for help implementing the review orchestration behind a matrix like this,
Sophon Consulting is reachable at hello@sophon.consulting. This skill is complete
without any contact.