Appendix A — Accountability-Unit Canvas
Use this canvas to design or test one existing human–AI workflow. Complete it with the people who understand the work and can act on the outcome. Start with a live process, not an imagined future state.
1. Name the Result
What result does the unit deliver? State the recipient, the outcome, and the condition that makes the result acceptable. Avoid naming an activity alone.
What is outside the boundary? State the cases, decisions, and consequences that remain elsewhere. A boundary is credible when people can recognize an exception rather than negotiate one after the fact.
How will the result be recognized? Name two or three observable conditions—quality, timeliness, rework, customer response, reliability, or another measure that fits the flow. The point is not to create an abstract score. It is to give a recipient and a reviewer a common description of what acceptable work looks like.
2. Name the Human Accountability Core
Who is the usual named human core? In most units, this is the process owner. Record why that person has enough context and authority for the normal result.
What must that person escalate? List material business trade-offs beyond the unit. Name the accountable executive who decides them.
What would make this person a scapegoat? Identify any decision, information, or control that the person would need to answer for but cannot influence. Repair that condition before expanding the unit.
What support is required? List the people, data, time, tools, and decision rights without which the named person cannot carry the result. The question is practical: if an exception occurs tomorrow, can this person see the relevant context, act within the boundary, and reach a legitimate decision-maker when the boundary is crossed?
3. Describe the AI Workflow
What is the AI-enabled action? Be specific: retrieve, classify, summarize, draft, compare, route, or flag.
What can the workflow prepare but not decide? State the human judgments that remain and the condition that triggers review.
What is the recovery action? Describe what happens when the workflow is wrong, incomplete, unavailable, or outside its boundary.
Where does the workflow begin and end? Mark the trigger, intended result, and point at which a person reviews, accepts, or hands off the work. State what AI must not decide. This line is as important as the list of supported actions; it gives reviewers a way to recognize a boundary crossing before a fast workflow becomes an unauthorized decision.
4. Make Context Usable
What context does the workflow need? List rules, examples, customer information, historical decisions, known exceptions, and sources of organizational memory.
Who keeps the context usable? Name the knowledge maintainer and define how a correction becomes a reusable rule, example, or exception pattern.
What must stay local or restricted? Identify context that is too specific, sensitive, or unstable to travel with the workflow.
How will stale knowledge be noticed? Identify a trigger for review: a recurring override, a change in inputs, a customer complaint, a process change, an unexplained drop in outcome quality, or another signal that fits the work. Organizational memory is not a storage project. It has to be maintained in the workflow.
5. Establish Traceability and Control
What must be reconstructable? Identify material inputs, outputs, review actions, changes, exceptions, and recovery actions.
What is the review condition? State what the review owner checks, when a result may be accepted, and when it must be returned or escalated.
What will the unit learn from failure? Record the decision path that turns a repeated exception into a revised rule, context item, or control.
When is a control no longer enough? Identify the condition that requires the workflow to stop or move upward: repeated overrides, a material customer impact, a missing source of context, an unresolved conflict between two rules, or another event appropriate to the work. An escalation trigger is not an admission that the unit failed. It is the boundary that prevents a local workaround from becoming an enterprise problem.
6. Draw the Accountability Chain
| Question | Answer |
|---|---|
| What complete result is being carried? | |
| Who is the named human core? | |
| Who runs the process? | |
| Who reviews consequential output? | |
| Who maintains reusable context? | |
| Which decisions stay inside the unit? | |
| Which decisions go to the accountable executive? | |
| Which conflict must rise to enterprise arbitration? |
7. Test the Unit
Run an ordinary case and one realistic exception. Then ask: could a new colleague find the context, understand the result, see what the workflow may do, challenge an output, and find the person who can decide the next action? If not, the unit is not yet durable.
Review the canvas after any material change in customer consequence, operating scope, authority, or available context. Do not treat it as a static planning document. The canvas is valuable only while it remains connected to the decisions it describes.
Unit Readiness Conversation
Before the pilot leaves its bounded route, bring the process owner, review owner, knowledge maintainer, and accountable executive together. Review one ordinary case, one exception, and one recovery action. Decide whether the result boundary, authority, context, and controls are usable under normal pressure. The goal is not unanimous enthusiasm. It is a clear decision to continue, revise, or stop.
Use the conversation to expose a mismatch that the canvas alone may not reveal. A process owner may know the work but lack access to a necessary source. A review owner may be able to reject an output but lack a route to correct the underlying rule. A knowledge maintainer may collect material without a decision about what becomes reusable. An accountable executive may be asked to resolve a business conflict too late, after a customer or employee has already carried its consequence. Each mismatch is a design finding. Do not disguise it as a training issue.
The group should leave with one named next action. It may be to narrow the boundary, add a review condition, clarify a decision right, remove unsuitable context, or stop the pilot. The point is to make an explicit choice before ordinary pressure turns an unresolved condition into an informal workaround.
The readiness conversation is also a way to test whether a role description has become too abstract. The process owner should be able to state the result being kept moving and the condition that would show the process has crossed its boundary. The review owner should be able to state what evidence would justify rejecting or returning an output. The knowledge maintainer should be able to state what will be captured when the case teaches something and how another qualified person will find it. The accountable executive should be able to state which resource, customer, quality, or risk trade-off cannot be settled in the process and how it reaches a decision. If these answers are generic, the unit is not ready for a stronger automation claim.
Record the First Exception
For the first material exception, capture the case type, the result at risk, the workflow action, the missing or misleading context, the human judgment used, the authority boundary, the recovery action, and the rule to test next. This record is the beginning of organizational memory. It should be short enough that the next team will actually use it.
Use a compact structure: result at stake; trigger; AI-supported action; human judgment; context; exception; recovery; learning; and next check. The record should not be used to rank individuals or assign blame. Its job is to make a specific failure pattern visible enough to change the next cycle. If a unit cannot create this record after a material exception, it probably lacks either the context, traceability, or authority required to learn.
Companion Resources
The canvas is deliberately compact. Teams looking for current meeting-ready worksheets on roles, workflow, organizational memory, human judgment, capacity allocation, and a 90-day roadmap can visit theunclej.com/ai-organization/toolkit. These are current companion resources, not a promised book-specific download; availability and format may change. The work still begins with the live process, the named result, and the people who can act on its consequence.