Use this resourceModels
- Purpose
- Agree on process purpose, deliverables, and handover before writing role descriptions, work manuals, and assessment rules. Six diagrams show how to use the same result requirements from execution to evaluation.
- Conditions for use
- Check that the subject, objective and constraints fit the task. Confirm any conditions that the article does not specify.
- Models
- Elements, relationships and assumptions
- Evidence and validation limits
- Use the model to map work, design role documents, and review assessments. Check the effects against actual deliveries and business outcomes. No separate external-validation result is recorded for this article. Publication does not establish effectiveness; check the evidence, assumptions and limits in the text.
- Version
- V1.0 · Revised 2026-11-11
- Original diagrams and files
- Figure 1 Overview — Processes, Workflow, and Three Management Documents
- Figure 2 A Process Has a Purpose, a Workflow Has an Objective
- Figure 3 Handover — Acceptance and Readiness to Start
- Figure 4 Design Three Documents from One Result Standard
- Figure 5 Prepare People and AI to Work to the Same Standard
- Figure 6 Assess Performance with Evidence of Results
- Download the six-page editable atlas (Draw.io, Chinese)
This is a readable, citable knowledge resource, not an installed Skill. When using it with AI, retain its sources and limits and review the output.
CC BY-NC-ND 4.0 · Applies to original text unless otherwise stated; excludes third-party materials. Downloading or machine reading does not extend the existing license or separately authorize derivatives, commercial use or model training.
For the same piece of work, a role description calls for one result, the manual tells people to do something else, and the performance review applies a third standard. When that happens, I put the three documents side by side. Who gets this deliverable? What will they do with it? How good does it have to be before the next step can use it?
Once those questions are clear, the role description says who is responsible, the manual says how to do the work, and the assessment rules say what evidence to judge it by. Each document has a purpose. All three draw on the same result requirements and the same version of the standard. That is what I mean by a shared basis.
1. Start with how the work moves through the business
The upper half of the overview shows the business workflow. A process receives valid inputs, does the work and delivers a result. Check that result against the process's purpose, then see whether the next process can take it forward. At the end of the workflow, check whether the final delivery produced the customer and business outcomes you set out to achieve.
When I review a piece of work, I ask four questions. Was the work completed? Did the deliverable pass? Did the next process use it? Did the overall workflow produce the intended outcome? Record those answers separately so you can see where the work got stuck. The diagram uses three processes to show the relationships. The actual work determines how many you need, which can run in parallel and where you may need to go back.
The lower half shows the roles. Start with the role that carries the work, then identify its responsibilities, the scope of each responsibility, the actions and their outputs. A responsibility should say what to deliver. Its scope defines how far it extends. Each action identifies an object and an operation and produces a result you can trace to evidence.
The two sides meet at delivery. In design, work backwards from the workflow objective to the processes and responsibilities. In execution, follow the action's result forward. Who received it, how did they check it, and what did they do with it?
2. A process has a purpose, and the whole workflow has an objective
Here I use “process” for a piece of work with a specific purpose. Ask what comes in, who does the work, how they coordinate and what they deliver. Inputs include the basis for the work, permissions and resources as well as materials and data. The purpose tells you why the work is needed. The result gives you evidence of whether it served that purpose.
A workflow connects several processes. Check what each process delivers, how the results pass from one to the next and whether those local results together support the overall objective. Purposes 1, 2 and 3 each have their own evidence. Once the workflow ends, check customer value and business outcomes separately.
The Four-Way SOP distinguishes four scopes of work and results.
| SOP | Scope of work | What to specify |
|---|---|---|
| Performance SOP | The whole chain of critical processes | Which processes together support customer value and business outcomes |
| Business Process SOP | One business process | Why it exists, who works together, what it takes in and what it delivers |
| Role SOP | Role responsibilities and task deliverables | What outcome a role is responsible for and which deliverable tasks fulfill it |
| Action SOP | A specific object and operation | What inputs, steps and standards produce the action's output |
The work manual puts the requirements into practice. The performance assessment evaluates the result. Use the Four-Way SOP to locate the work and result at the right scope, so the manual and assessment can refer to requirements already defined there.
3. Once delivery passes, what does the next step still need?
Before starting, agree on the provider, receiver, deliverable, deadline, acceptance criteria and who checks the result. Agree on who handles exceptions or disputes. These decisions give the role description, manual and assessment rules a common basis for handover.
Check this deliverable first. Process A submits the result, evidence and version. The receiver checks it against the agreement and records acceptance if it passes. Say exactly what is missing or needs rework, then submit it again to the same standard.
Then check whether Process B can start. With a usable result confirmed, check permissions, resources, other inputs and dependencies. Start once they are ready. If something is missing, name the condition. Decide whether to wait, coordinate with the people involved or escalate to someone who can resolve it. If the previous step has delivered successfully, resolve the condition missing from the next one.
I keep three records at handover. The result package holds the deliverable, evidence, version and status. The acceptance record holds the receiver, criteria, decision and time. The readiness record lists the valid inputs, permissions, resources and dependencies that are in place. Verify the final delivery too, then assess the workflow objective against actual outcomes.
4. Write three documents from one set of result requirements
Start by agreeing on the process purpose, the deliverable that would meet it and the handover between upstream and downstream work. Write down who uses the result, who is responsible, who checks it, what permissions and resources are available, and who handles exceptions. Use those requirements to write the three documents.
- The role description says what the role takes responsibility for. Describe an outcome the role can deliver. Specify who is responsible, the scope, where work comes from, who gets the result, which permissions and resources are needed, and when to report an exception.
- The work manual says how to do it. Explain how the task starts, what to check before work begins, the steps and decisions, when a result is ready to submit, how to record and hand it over, and who takes over when something goes wrong. A person stepping into the job should be able to use it to decide what comes next.
- The performance assessment rules say how to judge it. Identify the action, responsibility, process or business outcome being assessed. Set the quality, timing, cost and risk criteria, identify evidence, and agree on who assesses, reviews and resolves disputes. Consider what the role can control, the other teams it depends on and how long effects take to appear.
Process IDs, responsibility or task IDs, result IDs and standard versions let the documents refer to the same work. People using the manual and AI using a Skill should find the same version of the acceptance requirements. When a standard changes, review each role description, manual, assessment rule and Skill that refers to it.
I usually check it from the other end. Can the manual guide someone to the result the assessment expects? Does the role responsible for that result have the resources and authority to deliver it? When those answers don't line up, go back to the work and agree on the requirements and conditions.
5. Check the conditions before assigning work to people and AI
The manager specifies this task's purpose, deliverable, required actions, SOP version, acceptance rules, time and resources. Then decide which role capabilities, AI capabilities and collaborators are needed. Verify the available data, tools and permissions, and decide how approvals, exception reports and human takeover will work.
People use the work manual to carry out professional tasks, make judgments and communicate. They confirm, accept and take over within their authority. AI uses suitable Skills, tools and data to retrieve, generate, analyze and check, and submits its result with supporting evidence. The task should say which instructions require confirmation and which exceptions go back to a person. If a capability is missing, provide it or switch to a human. Pause to verify unclear permissions. If execution fails, report, take over or stop as agreed.
Submit the result with its record. Make it possible to find the task ID, executor, input and standard versions, tool or Skill version, supporting evidence, exceptions, elapsed time and human confirmations. The receiver applies the same acceptance requirements to work done by people and by AI, then checks readiness to start the next process.
6. Find evidence for each assessment
An early diagram of roles, work manuals, SOPs and performance assessment included POW. I borrowed the idea from Bitcoin's proof of work that there should be evidence of work you can check. This version separates the questions a business actually needs to verify.
| What to assess | What evidence to look for |
|---|---|
| Execution | Who did what, and whether inputs, versions, status and execution records agree |
| Acceptance | Whether the deliverable met the agreed standard, and where to find the decision and evidence for review |
| Downstream use | How the next process actually used the result and what it contributed to handover and collaboration |
| Workflow objective | Customer and business outcomes, the observation period and other factors that affected them |
Each record can inform the next assessment, which still needs evidence of its own. For responsibilities and tasks, look at delivery quality, timing, judgment and exception reporting. For process coordination, ask whether the next step used the result, how long it waited and how much rework or coordination was needed. For business performance, go back to the overall objective, value, cost, risk and durability.
When assessing individual contributions or compensation, establish what a person could control, the dependencies and the time lag. Keep a way to review evidence and handle disputes. Base pay, role-based pay and results assessment from the early diagram can inform further discussion. Compensation, incentives and distribution follow separately agreed and approved rules.
7. Try it on one piece of work you are doing now
Start with a handover that gets stuck repeatedly. Identify the objective it serves and what each side delivers. List the acceptance and starting conditions, then assign them to the roles and actions involved. Write the role description, manual and assessment rules from one set of requirements. Run a real task and see which conditions are missing, how the result is used and which evidence you still cannot find.
Then trace the work in both directions. From an objective, which processes, responsibilities and actions support it? From a responsibility, which process receives its result, and what does the result help the business achieve? Record gaps in evidence and go back to the actual handover, execution arrangement or assessment criteria. Look for changes in costs, performance or accumulated capabilities after the work has run.
This model builds on the early relationships between roles, work manuals, SOPs and performance assessment. Version 1.0 uses one overview and five more detailed diagrams to spell out the two handover checks, the common basis for the three documents, authorization and takeover, and assessment and review. For how I identify responsibilities and organize capabilities, see Role Responsibilities, Processes, and Human–AI Collaboration.