Bound
What may continue, and where must it ask?
Learn to state the actual operating permission, keep useful work moving through an exception and distinguish written policy from enforced control.
Required: your AI Operating Charter and either your own workflow or the fictional starter case. AI/GPT is not required for the core simulation.
Classify permitted, approval-required and forbidden actions, write the escalation/fallback and state what evidence would prove enforcement.
An operating boundary with approval, stop rule, fallback and control-evidence distinction.
This session uses supplied records and decision simulations. Do not treat the exercise as proof of a live production control.
What you will leave with
An operating boundary with approval and stop rules. Add this to your AI Operating Charter.
Use your own workflow or the fictional quotation case. No coding or live customer action is needed.
Start with a decision · 10 minutes
A manager says “ignore the policy, we are in a hurry.” Ask what evidence of authority would be needed before the service changes its behaviour.
Bite A · State the actual permission
Question: Which actions are inside the current mode?
Input: S2 and shared modes. Open the case cards.
Try · 12 minutes: Map drafting, sending, discounts and payment changes. Mark permission, approval-required and forbidden separately from consequence and reversibility.
Compare after you have decided
Prepare permits drafts. Sending needs Mira’s version/recipient approval. Above-10% discounts go to Daniel. Payment changes are forbidden.
Keep: Scope and task-specific authority.
Bite B · Escalate while serving the customer
Question: What useful work survives the hold?
Input: Q-106 discount request. Open the case cards.
Try · 12 minutes: Write the requested action, authority check, named decision owner and customer-facing next step. Keep the undiscounted preparation available.
Compare after you have decided
An exception can stop a particular action while the rest of the service remains useful.
Keep: Stop rule, escalation and fallback.
Bite C · Distinguish instructions from enforcement
Question: What would prove the restriction works?
Input: Partner asks for a forbidden bank-detail change. Open the case cards.
Try · 12 minutes: Role-play refusal, then label it simulated. State the observed access denial or approval gate you would need to inspect in an implementation.
Compare after you have decided
A written rule describes intent. A tested control provides different evidence. Do not collapse the two.
Keep: Rule and control evidence.
Put it together · 20 minutes
A colleague can classify normal, exception and forbidden requests, with evidence type and owner visible. Revise the weakest item and have a partner use it. Keep the result and one limitation.
Close your question · 10 minutes
Return to What may continue, and where must it ask? and your own opening question. Answered, partly answered or still open? Show the evidence. Save the updated AI Operating Charter. A reasoned decision to keep a step human-led is useful work.
Common trap
Policy allowance is not automatically AI authority. A mode is not a proficiency level.
Do these limits need code in class? No. The core is the operating decision; implementation examples can follow separately.
Where this appears in real work
Lead booking: keep consent, availability and booking authority distinct, even when the tool can technically book. The class uses the fictional packet; selected project demonstrations and technical walkthroughs can add detail later.