Pragmatic Loop All insights

Practical field note · no client result claimed

02 / HUMAN CONTROL

Put human approval where consequence meets uncertainty.

A review queue is not automatically a safety control. It becomes useful when the system knows why review is required, presents decision-ready evidence, and prevents action until an accountable person decides.

Human-in-the-loop is a design claim, not a checkbox.

The person must have the authority, evidence, and time to change the outcome before the consequential action occurs.

01 / REVIEW TRIGGER

Use uncertainty and consequence together.

Uncertainty alone does not determine whether review is needed. A low-confidence internal tag may be harmless and reversible; a moderately confident payment, legal notice, customer message, access change, deletion, or publication may not be.

UncertaintyConsequenceReasonable default
LowLow and reversibleAutomate with validation, logging, and sampling.
HighLow and reversibleRoute to review or a safe fallback based on volume and cost.
LowHigh or difficult to reverseKeep an approval gate until the environment proves a narrower policy safe.
HighHigh or difficult to reverseDo not act automatically; require accountable review and preserve evidence.

Other triggers can be deterministic: missing required fields, arithmetic mismatch, duplicate risk, protected category, amount threshold, new destination, changed policy, or an unavailable source. Model confidence is only one signal.

02 / ACTION BOUNDARY

Separate prepare, decide, and act.

A controlled workflow can let software collect authorized input, extract or classify it, apply deterministic checks, and prepare a proposed action. The external write remains disabled until the decision endpoint receives an authenticated approval that matches the reviewed version.

  1. 01
    Prepare

    Generate a proposed result with source references, validation signals, and a stable version.

  2. 02
    Queue

    Explain why review is required and assign it to an accountable role.

  3. 03
    Decide

    Approve, reject, correct, or request more information with a recorded reason.

  4. 04
    Act

    Execute only the approved version through a separately authorized, idempotent connector.

Version boundary

If the proposed content or source evidence changes after review, the old approval must not authorize the new action.

03 / REVIEW PACKET

Do not make the reviewer reconstruct the workflow.

A useful review item presents the original source or safe reference, structured extraction, proposed action, confidence or policy signals, validation failures, duplicate history, material changes, destination, and consequence. It also states what will happen after approval.

  • Why did this item enter review?
  • Which source and version support the proposal?
  • Which fields or claims are uncertain?
  • Which deterministic rules passed or failed?
  • Has the same business event appeared before?
  • What exact external action will approval enable?
  • Can the reviewer correct the proposal rather than only accept or reject it?

04 / DECISION RECORD

Approval needs identity, intent, and scope.

Record the accountable reviewer, timestamp, item and proposal version, decision, reason or correction, policy signals shown, and downstream action reference. Avoid turning the audit trail into a copy of unnecessary personal or sensitive source data.

An approval record should answer: who decided, what they saw, which exact action they authorized, and whether that action completed.

05 / QUEUE FAILURE

The human step can fail too.

Queues become unsafe when ownership is vague, items age silently, reviewers lack context, corrections bypass validation, or urgent work is approved without reading. Treat backlog age, unassigned items, repeated overrides, and approval-to-action mismatch as operating signals.

A human gate that cannot stop the system is decoration. A human gate that stops everything forever is also a failed design.

06 / REVIEW CHECKLIST

Before calling a workflow human-controlled.

  • Is the review trigger explicit and testable?
  • Does the external action remain disabled before approval?
  • Can the reviewer see the source, proposal, policy signals, and consequence?
  • Does approval bind to a stable proposal version?
  • Can the reviewer reject, correct, or request more information?
  • Are reviewer identity, decision, reason, and action outcome recorded?
  • Are unassigned and aging items visible?
  • Does a changed proposal require a new decision?

INSPECTABLE REFERENCE

Document Gate

A verified portfolio build showing typed extraction, confidence and policy checks, duplicate blocking, auditable local decisions, seven passing tests, and zero external actions. It uses synthetic data and is not client work.