Hold at the human decision boundary

Verifiedon 2026-07-302026.7.1

Generation is not permission

A model can classify a message and draft a reply without having authority to send it. The human gate belongs immediately before the irreversible external action, after the system knows the exact destination, content class, route version, and likely impact. Putting approval earlier—at “turn on the integration”—creates a stale blanket permission. Putting it later—after delivery—turns review into a postmortem.

This lesson uses a synthetic support request and a disposable reviewer destination. It does not teach provider-specific approval UI or claim that an OpenClaw channel automatically enforces these controls. Check the current OpenClaw documentation index, the official releases, and the exact adapter documentation before implementation. The course review boundary is OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4.

Define an approval record

An approval is a bounded decision, not a boolean flag. Store:

• decision ID and source event ID;
• approver identity and role;
• exact operation: deliver-draft, not send-anything;
• exact destination and destination class;
• content classification and redacted content fingerprint;
• route version and policy rule;
• decision (approve, reject, request-change, or hold);
• created and expiry timestamps;
• reason, owner, and provider receipt reference after delivery.

The approver must see enough to make an informed decision: what will happen, where it will happen, what data class leaves the system, and what uncertainty remains. They do not need the full customer conversation if a redacted summary is sufficient. Minimize exposure: include a short synthetic summary and a link to restricted evidence only when access is authorized. Never put tokens, private URLs, or copied customer text into a shared escalation message.

Approval must be bound to the exact destination. If the draft changes materially, the classification changes, the route version changes, or the expiry passes, the approval is invalid. A timeout resolves to hold, never send. Rejection resolves to no delivery and should not be retried automatically.

Worked example: support triage with uncertainty

Synthetic request evt-test-0042 is classified billing-question, and a draft says: “We need more information before we can investigate.” The proposed destination is reviewer-test-room. The classifier is 82% confident, and the account context is intentionally absent. The escalation should say: “Decision needed: approve or revise the redacted billing-triage draft for the disposable reviewer room. Uncertainty: account context is unavailable. Owner: support-approver. Decision time: 15 minutes. Safe interim state: hold; no external delivery.”

The approval record does not need the synthetic message body. It needs the event, classification, destination, draft fingerprint, and decision. If the approver chooses approve, the delivery adapter rechecks expiry and destination immediately before the outbound attempt.

{
"decisionId": "appr-test-009",
"eventId": "evt-test-0042",
"operation": "deliver-draft",
"destination": "reviewer-test-room",
"dataClass": "synthetic-support",
"routeVersion": "v3",
"decision": "hold",
"uncertainty": "account-context-unavailable",
"expiresAt": "2026-07-30T12:15:00Z"
}

Lab: run the approval boundary

Use a disposable test workflow with five stages: receive, classify, draft, approval, and delivery. Start with a synthetic event and verify that the draft can be created while the outbound adapter is disabled. Generate a redacted approval request. Test four branches:

1. Approve before expiry: recheck route, destination, and approval; record a delivery intent and provider receipt.
2. Reject: record the reason and suppress delivery; do not requeue the rejected draft automatically.
3. Approval expires: hold and escalate to the owner; never treat the expired record as consent.
4. Destination changes after approval: invalidate the approval and require a new decision.

Expected output is a state transition for each branch and no external side effect in the hold, reject, or changed-destination cases. If the provider returns an ambiguous result, combine this record with Lesson 4’s idempotency key and keep the state unresolved until reconciled.

Escalation is a decision handoff

A good escalation answers four questions: what decision is blocked, who owns it, when is it needed, and what happens safely in the meantime? It does not dump the entire transcript on the next operator. Use a concise format:

Decision: approve, revise, or reject synthetic draft EVT-0042
Target: reviewer-test-room (disposable)
Uncertainty: classification is provisional; account context unavailable
Owner: support-approver
Decision by: 2026-07-30T12:15Z
Safe interim state: HOLD — no external delivery
Evidence: decision record DR-0042; route v3

The operator should be able to find the evidence without receiving data they do not need. If no owner acknowledges within the time budget, keep the route held and escalate to the disable owner. “No answer” is not approval.

Failure cases and rollback

The common shortcut is to have the model write “approved” into its own output. That is not an independent human decision. Another failure is an approval screen that omits the destination, so a human approves a draft without knowing where it will go. A third is approving a generic request and letting the adapter choose a destination later. Make the action, destination, and content fingerprint immutable after approval.

Rollback is immediate hold: revoke pending delivery authority, disable the outbound route if the boundary was bypassed, preserve the redacted record, and notify the named owner. If a real message was delivered unexpectedly, do not erase evidence or attempt a second corrective send without approval. Open an incident record and rotate credentials if they were exposed. The learner artifact is the state table, redacted approval, and escalation handoff; Lesson 6 will use them during offboarding.

Source receipt

Primary source: OpenClaw docs index. Version receipt: OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, checked 2026-07-30. OpenClaw releases and exact provider documentation must be re-reviewed when adapter permissions or delivery behavior changes.