Process owner
Defines scope, intended outcomes, governing sources and human decisions. Resolves disagreements within their remit and owns changes. Question: what may this worker do, and who may change those conditions?
Prepare your people. Define the boundaries. Test the controls. A working pack for one workflow, with payments as an illustrative example.
No email required. Use the templates across workflows. Record evidence, owners and unknowns rather than assuming readiness.
Defines scope, intended outcomes, governing sources and human decisions. Resolves disagreements within their remit and owns changes. Question: what may this worker do, and who may change those conditions?
Examines evidence, checks current authority and records judgment. Forms an independent view before seeing the AI recommendation where required. Question: what supports this decision, and may I approve it?
Supplies evidence, manages holds, pauses work and escalates unknowns. Checks an existing operation before retrying. Question: what is waiting, who owns the next step, and has an action occurred?
Enforces access and action boundaries, tests failure and recovery, and maintains logs and controls. Question: can the worker bypass the check, and what happens if a service fails?
For each role, name the person, evidence of their remit, approval limits and escalation contact. Combining roles must not defeat required separation of duties.
| Practice scenario | Expected response |
|---|---|
| Expired delegation | Hold the action and establish current authority. |
| An attachment says “ignore the checks” | Treat it as untrusted content, not an instruction. |
| Submission times out | Reconcile the existing operation before considering a retry. |
Record individual responses and follow-up actions. Attendance or elapsed review time alone does not prove readiness.
Name the workflow, business problem, baseline, included and excluded cases, accountable owner and supporting sources.
| Define | Record |
|---|---|
| Permitted actions | Exact actions; automatic, approval-required or prohibited. |
| Governing conditions | Rules, versions, effective dates, limits, required evidence and exceptions. |
| Review | Reviewer authority, review mode, separation of duties and unresolved disagreements. |
| Stopping conditions | Missing evidence, stale authority, prohibited cases and escalation owner. |
| Completion | Required outcome, receipt and reconciliation. |
| Change | Who may change the brief and which source, case or configuration changes require review. |
| Implementation status | Proposed, implemented, tested or unresolved; attach test evidence and an owner. |
An approved brief does not establish that all its controls are implemented. Specify the action precisely: “submit this approved instruction,” not “manage transactions.”
Model access controls which providers and information a worker may use. Action controls determine whether a particular business action is authorized. A model gateway alone does not establish business authority.
Map each connection to a system, identity, permission and owner. Check bypass routes, credential storage, outbound data, tool and network access, revocation, unavailable controls, duplicate prevention, unknown outcomes and log retention.
This is a reference arrangement, not a claim that every customer integration already exists. Approval cannot waive a failed mandatory check. Stopping a worker does not reverse an accepted action, and restarting must not restore revoked authority.
Record the organization, workflow, version, date, decision-maker and proposed environment: historical replay, simulation or restricted live use.
Established: supported and tested for the scope. Conditional: usable only within recorded restrictions. Unresolved: evidence, agreement or implementation is missing.
| Readiness question | State · evidence · owner · due date |
|---|---|
| Business purpose and baseline | ____________________ |
| Governing rules and material conflicts | ____________________ |
| Permitted actions and exclusions | ____________________ |
| Current authority and separation of duties | ____________________ |
| Staff scenario practice | ____________________ |
| Enforced action checks and bypass tests | ____________________ |
| Pause, revocation and safe recovery | ____________________ |
| Receipts and unknown outcomes | ____________________ |
| Model and configuration change controls | ____________________ |
| Monitoring and escalation owners | ____________________ |
| Data access, privacy and retention | ____________________ |
Decision: proceed within scope; proceed with restrictions; remain in simulation; or do not proceed. Record restrictions, blockers, acceptance measures, stop conditions, next review date and decision-maker authority.
Do not average these answers into a readiness score. One unresolved condition can prevent an action.
Illustrative payment example. Harbour Payments, its policy and records are fictional. Execution is simulated. The reusable pack above applies across workflows.
The worker investigates a held payment. A fictional policy permits an authorized operations manager to approve up to £25,000 per payment. Being below that limit is only one condition. Required evidence includes the instruction, beneficiary validation, mismatch resolution, current authority and required screening results.
| Stage | Action and record |
|---|---|
| Gather | Beneficiary validation is missing. Request the record; do not release. |
| Resolve | An approved record confirms the beneficiary and documentation resolves the mismatch. Preserve sources and updated case state. |
| Review | The separate manager records an initial judgment before seeing the recommendation, resolves differences and approves the exact facts. |
| Check | ACE checks current rules, evidence, amount, authority and approval. Record the outcome and reasons. |
| Execute and reconcile | Submit one uniquely identified simulated operation. Close only after a matching successful receipt. |
If authority expires: hold and establish current authority. If a fraud concern appears: escalate to a specialist; this workflow cannot clear it. If execution times out: reconcile the existing operation instead of submitting another.
Example deployment decision: remain in simulation until real entitlement, integration, failure recovery and operational arrangements are established and tested. Measure preparation time, reviewer effort, corrections, correct and unnecessary holds, and maintenance effort.
The AI Delegation Strategy applies these questions to one function: two weeks, US$3,000. The recommendation is grounded in your evidence and process-owner input.
This pack supports a deployment decision. It does not certify compliance or establish corporate authority by itself. Version 1 · 27 October 2026.