Specify the operating boundary of an autonomous task.
About 45 minutes, including the exercise.
Learning objectives
Specify the operating boundary of an autonomous task.
Distinguish a meaningful intervention from ceremonial approval.
Companion reading in Better Answers, Worse Decisions: Chapter 4. The book is for separate purchase. This course does not provide the manuscript or chapter downloads.
The lesson
Delegate a defined decision, not a vague capability
“Use AI in the department” is not a decision boundary. Specify the input, permissible output, affected population and conditions in which the system must decline or escalate. A tool suited to a narrow routine decision may be unsuitable for an irreversible judgement with ambiguous evidence. The same model can occupy different roles in different workflows.
Identify the realistic alternative and the consequence of delay. Requiring an expert to approve every trivial decision can consume scarce expertise without improving outcomes. In other settings, removing independent judgement can eliminate the only path by which a consequential error is detected. The useful question is which arrangement improves service while preserving a proportionate route to correction.
Separate a veto from a signature
A person is not an effective safeguard merely because a screen asks for approval. Can that person inspect the grounds, obtain contrary evidence, decline the recommendation and bear the time cost of doing so? Does the organisation permit disagreement without treating it as a performance failure? These are operational questions about authority and resources.
Use an escalation rule with a destination and a response time. “Refer difficult cases” is incomplete if no competent recipient is available or if the original decision takes effect before review. A review pathway may also be inaccessible to the person affected. Include the practical cost of invoking it, not just its existence in a policy document.
Test the boundary
Before expanding a deployment, test cases near its limits: missing data, contradictory evidence, unfamiliar populations and a failed upstream service. A refusal or escalation can be the correct output. Do not count every abstention as a system defect while simultaneously claiming the benefits of a bounded operating domain.
Write down who may change the boundary. A quiet change in a threshold, input field or default can expand the consequences of a system without changing its brand name. Version the decision rule and the operating conditions. Review the deployment when the environment changes, not only when a calendar reminder arrives.
Invented for this course
Automatic reimbursement
A fictional organisation considers automatically approving small expense claims. Routine claims have a valid receipt, an approved category and an amount below a fixed limit. Exceptional claims include missing receipts and disputed business purpose.
Define the routine boundary using observable fields and preserve a route for correcting rejected or misclassified claims.
Escalate disputed purpose rather than pretending that a text classifier resolves the underlying policy question.
Test duplicate receipts, changed tax treatment and unavailable records. Assign authority to suspend automated approval when those tests fail.
What follows: Automation can be appropriate for the bounded routine while exceptional judgement remains a separate, staffed process.
Attempt before opening feedback
Write a delegation charter
For a fictional service, write permitted decisions, exclusions, escalation triggers, response times and the authority to suspend the system. Include one reason not to require human approval on every case.
Review criteria
The boundary can be tested against actual inputs.
Escalation has a competent destination and a time limit.
The plan compares the costs of intervention and non-intervention.
Worked feedback
A charter should say what happens when the designated reviewer is absent. It should also distinguish a pause of the automated process from a pause of the whole service: a manual or limited fallback may preserve access. No universal threshold is correct without the service’s evidence and consequences.
Optional extension · about 15 minutes, additional to core course time
Extension: a timeout does not tell you whether the action happened
Extend the Chapter 4 delegation charter with a failure after an action is submitted. Use only this fictional tabletop case; do not send requests to a real service. An AI-assisted warehouse tool may release one allocation of exactly 24 units to destination D4, using allocation version v8, under approval A17. The approval covers that one allocation, not any other quantity, destination or version. It permits submission strictly before 15:10 on the same day. A submission already accepted may finish later; expiry does not cancel it.
At 15:02 the tool submits the approved action with operation identifier R17, then loses the response. It is not known whether the service accepted or completed it. For this exercise, the normal action is not known to be idempotent: repeating a request could create another allocation. Merely attaching the same identifier does not prove that the server prevents duplicates. Status reads are permitted and do not create allocations.
The charter permits at most one retry of the unchanged action only after an authoritative service record proves the first attempt had no effect and cannot execute later, provided the approval is still valid at the new submission. It requires escalation of unresolved outcomes to the duty operations lead by 15:09. That lead may reconcile or hold the operation but cannot silently expand A17. These are invented local rules, not universal deadlines or a claim about any deployed service. Treat each row below as a separate possible outcome, not a sequence.
Four alternative readbacks of the same timed-out attempt (invented case)
Authoritative record: R17 accepted and still pending.
No final completion result yet.
C
15:05
A lagging search index returns no record for R17.
This index can omit recently accepted operations.
D
15:06
Authoritative terminal failure record for R17 confirms no allocation or other business effect occurred and the attempt cannot execute later.
The source can establish this final state; A17 and all action details remain unchanged.
Attempt first
For A through D, choose record completion, wait and reconcile, or permit the single bounded retry. State the evidence supporting each choice. Why is C different from D?
After D, the tool proposes 28 units instead of 24 while retaining approval A17 and identifier R17. Explain why proof that the first attempt failed does not authorise this changed action. What information must return to a person with the relevant decision authority?
Suppose D is not established until 15:11. What may the tool still do, and what may it no longer submit under A17? In B, why would expiry at 15:10 not prove that the pending operation was cancelled?
Write a five-field recovery record: approved action and version; attempted operation identifier; latest authoritative status and evidence time; next permitted step with owner and deadline; and confirmed final result or explicitly unresolved outcome. Give one safe test that would expose a duplicate or an unsupported completion claim.
Uncertain outcome: decisions and worked feedback
A: record the confirmed completion and do not submit the allocation again. A matching operation identifier alone would be insufficient if quantity, destination, version or completion state did not match. Preserve the record that links the approved action to its actual result.
B: the service has accepted work that may still complete. Reconcile its status; do not create a second allocation. If the outcome remains unresolved, escalate by 15:09 under the charter. C: an empty result from a lagging index leaves acceptance and completion unknown. Use the designated authoritative status source or escalate; do not turn absence from that index into proof of failure.
D: the stipulated authoritative final record rules out both a past effect and later execution of the first attempt. At 15:06, with A17 and every action detail still valid, the charter permits its single retry. Record the relationship to the first attempt and verify the resulting state. The evidence, not a change of identifier or repeated clicking, justifies this step. If the retry also times out, do not retry again automatically; retain the uncertain outcome and escalate.
Changing 24 to 28 units is a new decision outside A17, even if an interface accepts it or the proposed quantity seems small. Supply the original approval, changed quantity, reason, current allocation version and prior-attempt evidence to the authorised decision-maker. Reconcile the first attempt before any new allocation. An operation identifier can help correlate records; it is neither permission nor a duplicate-prevention guarantee.
At 15:11 the first attempt may be known to have failed, but A17 no longer permits a new submission. While the outcome was unresolved, it should already have been escalated by 15:09. Status reconciliation and escalation remain permitted; obtain a valid decision before any later submission. Conversely, B may still complete after 15:10 because the charter limits submission time, not execution time. Expiry is not a cancellation acknowledgement. Do not report that work was stopped without evidence of its actual state.
A useful isolated test lets the service complete the first action but deliberately suppresses its response. The learner should find the matching completed record and leave the number of allocations at one. A second test can return a lagging empty index while an accepted operation is pending: the correct record remains unresolved, with an owner and next check. Assert the final effect count, not just the number of clicks or messages. These tests assess the stated recovery boundary; they do not prove every failure is covered.
Sources and scope
RFC 9110 (2022), section 9.2.2, distinguishes idempotent requests and cautions against automatically retrying non-idempotent requests without evidence that repetition is safe or the original was never applied. NIST AI RMF 1.0 (2023), GOVERN 2.1 and 3.2, supports explicit responsibilities and oversight roles. The course combines those questions in an original delegation exercise. Neither source supplies this charter, a duplicate-prevention implementation, or an end-to-end exactly-once guarantee.
This is an open self-check, not a secure examination or certificate. Answers and explanations are available below. Nothing you enter is sent to a server.
Keep your working notes
These notes remain only in this tab. They are not submitted or saved automatically. Download a copy before leaving. Use fictional or public information, not confidential personal or client details.