Use this resourceModels
- Purpose
- The V2.0 research summary connects stakeholder value, four SOP scales, role responsibilities, human–AI work and result evidence. Fourteen chapters and thirty diagrams explain how to test current results and capability for the next job.
- 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
- Interim research summary, theoretical framework V2.0. Implementation details and business effects need testing in pilots. 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
- V2.0 · Revised 2026-11-11
- Original diagrams and files
- Figure 01 · Model overview: value, collaboration and capability
- Figure 02 · Eight propositions for the first edition
- Figure 03 · Digital stakeholder governance: three dimensions
- Figure 04 · Co-creation, long-term accumulation and governance
- Figure 05 · Business judgment, organization and execution
- Figure 10 · Six jobs managers do to organize execution
- Figure 11 · Execution capabilities and supporting resources
- Figure 06 · Four SOP scales: breaking down results for reuse
- Figure 07 · Master diagram: roles, workflow and performance
- Figure 08 · Process and workflow: purposes, objectives and results
- Figure 19 · Prerequisites: two decisions at handover
- Figure 09 · Derive roles and tasks from the need for value
- Figure 14 · One design basis for three management documents
- Figure 15 · Shared IDs, versions and dependencies
- Figure 12 · Smallest action, task instance and reusable standard
- Figure 13 · Four ways tasks arise: attributes can overlap
- Figure 16 · Shared standard for SOP, manual and Skill
- Figure 17 · Combine Skills around a functional result
- Figure 18 · Human–AI execution, authority and takeover
- Figure 20 · Four states and their evidence
- Figure 21 · Performance by scale, review and accountability
- Figure 22 · Results, contribution, rights and distribution
- Figure 23 · Shared interfaces for independent organizations
- Figure 24 · Trusted collaboration and when to use blockchain
- Figure 25 · Operating feedback and diagnosing exceptions
- Figure 26 · Validate changes, control release and build capability
- Download the editable 31-page Draw.io atlas (Chinese)
- Figure 27 · First pilot: start with one key business workflow
- Figure 28 · Two tests: better business results and stronger capabilities
- Figure 29 · First-edition toolkit and pilot deliverables
- Figure 30 · Terminology, research limits and version control
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.
I've been trying to answer one question. As AI takes on more of a company's work, how can the company tell whether it has actually become better at running its business?
A document can be written quickly. I still want to know who will use it, how they'll judge it, who will handle problems and whether someone else or a different AI could do the job next time. In V2.0 I connect processes, workflows, role responsibilities and results, then work out where people and AI fit.
1. What the company needs to rebuild
I start with the value that stakeholders need. Four-direction SOPs break down the results, while process and role design bring together the capabilities of staff, AI and external partners. After execution, teams use shared requirements to hand over, accept and review the work. Methods that hold up become available for the next job.
I look for two things together: an improvement in this round of business and a more dependable capability for the next. AI calls and file counts describe activity. Actual delivery and reuse tell me more about operating capability.
Organize capabilities for business value. Test current results and long-term gains separately.
These propositions guide design and still need to be tested in practice.
2. Start with where value comes from
In my work on stakeholder capital, I look at what can accumulate after people invest effort and create value together: resources, capabilities and working relationships. Contributions, rights and governance need to connect over time. A delivery can be valuable today and leave something for the next collaboration.
| Dimension | What to look at |
|---|---|
| Four ecosystems | Resources, customers, operations and capital. Identify who takes part, what they bring and which relationships need governance. |
| Six value systems | Core value, value production, sales, operations, returns and amplification. Trace how a value proposition becomes realized value. |
| Four competitive layers | Product → platform → finance → culture. Identify the layer at which competition takes place. |
The ecosystem framework describes participation and value relationships. The four-direction SOPs describe how results are organized and delivered. The competitive layers are a way to examine competition. Technology and financial arrangements depend on the business. The full mapping among ecosystems, value systems and SOPs remains a research question.
Four ecosystems, six value systems and four competitive layers.
In stakeholder capital research, contributions, capital and rights need separate consideration.
3. What direction, organization and execution each involve
Business judgment decides whose needs to serve, which business to pursue and how much to commit. Organizational capability turns the desired result into processes, roles, authority and resources, then coordinates dependencies. Execution capability does the work, delivers the result and flags exceptions.
One person can carry several responsibilities, and AI can assist with analysis and execution. For each job I want to know who sets the objective, who authorizes the work and who owns the result. Compute, budgets, data and tools support the work. They become usable capabilities through configuration and testing. External partners need clear responsibilities and interfaces too.
Different people can hold these responsibilities. One person can also hold more than one.
Connect objectives, resources, handovers and responsibilities.
Identify who or what can deliver, then check data, tools, timing and authority.
4. How I break down the four SOPs
| Scale | What needs to be clear |
|---|---|
| Business-results SOP | Which business processes work together to deliver customer value and operating results. Performance rules evaluate the resulting outcomes. |
| Business-process SOP | Why a process exists, who participates, how the work is organized and how results are handed over. Processes can cross teams or companies. |
| Functional SOP | Which result a role owns and how that responsibility becomes deliverable tasks. |
| Action SOP | What object to act on, what to do and what to produce. A noun and verb identify the action. Inputs, standards, authority and exception handling make it executable. |
I break down the desired value and results from the top, then verify how actions, role deliverables and processes support them from the bottom. The four scales describe relationships between results. Work can cross levels and departments. A higher action count still needs to be tested against the overall objective.
Four scopes of results. Roles and teams may work across them.
The four SOPs organize work. Manuals and evaluation support them.
5. Separate processes, workflows and results
I use process for work with a local purpose and workflow for the sequence of connected processes whose results support an overall objective. A result is the output or state that actually emerges. It gives us evidence for whether a purpose or objective was met.
Earlier diagrams made this distinction and checked incoming results before work moved on. This version makes the conditions more explicit. For each process I ask why it exists, what it hands over, who will use it and what it contributes to the overall objective. The answers help me decide what work to assign and where AI can contribute.
The terms follow their use in the original model.
6. Make two decisions at each handover
First, check the previous result against the agreed standard. If required materials are missing or quality falls short, identify the gap, correct or redo the work and submit it again.
Then check whether the next process is ready. An accepted result can still be waiting for authorization, resources, a time window or another dependency. Coordinate, wait or escalate as appropriate. Separate decisions show who can resolve the issue and let us record completion, acceptance, readiness and attainment of the objective separately.
Correct a deficient delivery. Wait, coordinate or escalate if the next process is blocked.
7. Write three documents from one process
Start with the process purpose, expected result, interfaces, permissions and operating conditions. Use that shared basis to answer three questions.
- Role descriptions specify the result I own, who receives it and the scope of my authority.
- Work manuals explain how I check inputs, act, exercise judgment, hand over and handle exceptions.
- Performance rules describe the evidence and review period, what the owner controls and how to seek a review.
Then check the three documents together. Does the manual explain how to produce the result the role owns? Does the evaluation recognize the work in the manual? Do people have the resources and authority for the results expected of them? Process IDs, role or task IDs, result IDs and standard versions can tie the documents together. The manual for people and the AI Skill use the same acceptance requirements. This design still needs to be tested in use, including its data fields and systems.
Define ownership of the result, then choose the roles and capabilities that can deliver it.
Share result requirements, interfaces and responsibility conditions across all three.
Proposed first set of fields for traceability. Test them in use.
8. Organize people and AI around the task result
A task instance specifies the deliverable, owner, inputs and deadline. An SOP supplies the standard for that class of work. A manual guides a person's actions, judgment and takeover. A Skill assembles methods, knowledge, tools and rules for AI. People and AI can work differently and face the same acceptance test.
At action level, specify the operation and output, then choose manual work, AI assistance or automation. At functional level, define the deliverable first. AI can propose a combination of Skills for the owner to confirm. Business processes connect outputs across functions, and business-results SOPs bring the focus back to customer value and operating results. A Skill can serve several tasks, and a task can need several Skills and human work. When inputs or capabilities are missing or authority is unclear, resolve the dependency, pause or hand the task to a person.
An action is the smallest unit of analysis. Assign an owner, inputs, outputs and acceptance requirements to one instance, and it can be managed as an atomic task. Complex tasks can contain several actions. Routine, periodic, triggered and request-driven describe how tasks arise and can overlap.
An action is the smallest unit of analysis. A complex task can contain several actions.
Routine, periodic, triggered and requested describe how tasks arise.
People and AI work in different ways toward the same required result.
Define the functional deliverable first, then match capabilities to that task.
Specify direct actions, approval points, pauses and handover to a person.
9. Evaluate results and performance with evidence
I used POW in an early diagram, drawing on Bitcoin's idea of proof of work. I now describe this part as result evidence and performance evaluation. Check four things independently: whether the work happened, whether the result passed, whether the next process used it and whether the overall objective was reached during the observation period.
Evaluate responsibilities and tasks, processes and coordination, and business outcomes at the appropriate scales. Consider resources, controllable factors, dependencies and time lags. Support, risk control and long-term capability work need evidence suited to their effects. Base pay, role pay and result evaluation can connect to a compensation system. Pay, incentives and distribution need separate rules, approvals and review. After accepting a deliverable, attribution and rights still require their own decisions.
The arrows connect evidence. Each state needs a separate check.
Use shared documents and actual evidence to evaluate performance.
10. Connect work across organizations
Customers, suppliers, partners and investors operate independently. When connecting their work, agree on roles, deliverables and acceptance, data access and authority, dispute handling, and applicable rights and settlement rules. Each party can keep its internal SOPs and work through a shared interface.
The verifiable value creation network is a research concept. It calls for traceable work, delivery, confirmation and rules. Where several parties need shared records and checks, blockchain is an option to evaluate. Recorded evidence still needs fact-checking, and automatic execution still needs authority and dispute handling. Joint creation, contribution, rights and distribution each have their own conditions.
Four connected decisions with separate conditions.
Companies, customers, suppliers, partners and investors keep their own roles and responsibilities.
Identify what parties must confirm before choosing how to record, verify and enforce rules.
11. Turn work already done into capability for next time
The earlier action–result–learning diagrams considered how the reasons for success or failure feed back into SOPs, manuals and training. I want to strengthen the validation in between. Keep execution and operating evidence, evaluate at the relevant scale, investigate causes, propose a change and try it on a small scale. Then decide whether to release it, keep observing or retire it.
Check explanations against evidence. Compare the new method's results, costs and side effects. Once validated, update roles, manuals, SOPs, Skills and training together, with clear conditions, owners and a way back. When others can reliably use the method, the organization has gained a capability. Whether it becomes shared capital or gives rise to rights depends on governance rules and evidence over time.
Check the cause before changing people, capabilities, tools, workflows or assumptions about the goal.
Keep methods the next team can use.
12. What the research has produced so far
When V2.0 took shape, there were 13 diagrams: one role–workflow–performance master diagram and two six-page sets. The master locates the four-direction SOPs. The human–AI collaboration set follows capability assignment, execution and feedback. The shared role-document design set covers prerequisite checks, the three documents and result evidence.
The accompanying V1.0 atlas consolidates the material into 30 diagrams and a one-page index. Two-part handover checks, Skill configuration, authority and takeover, and ID and version links are designs developed during this stage. The age of an early diagram, the date of public release, theoretical originality and business effects each need their own evidence.
Role Responsibilities, Processes, and Human–AI Collaboration · A Shared Design Model for Processes, Workflows, and Role Documents · Download the editable 31-page Draw.io atlas (Chinese)
13. Try one business workflow next
I would start with one important workflow and define its scope, owner, baseline and stop conditions. Write down the overall objective and the purposes of its processes. Break out responsibilities, tasks and actions, write the three documents from the same basis, then assign human and AI capabilities and set permissions and handovers.
Observe quality, waiting, rework, human takeover, costs and actual business results. Ask a second colleague to repeat the work using the manual or Skill left by the first run. Expand when the evidence supports it, keep observing while effects are uncertain, and adjust or stop when the conditions fail.
The framework, terminology and diagrams are in place. Pilots still need to refine Skill combinations, evidence fields, standard versions and review procedures. Ecosystem mapping, cross-organization interfaces, long-term accumulation and repeatable business results remain to be tested.
Set review points, observation periods and stop conditions for the business at hand.
Both tests need evidence beyond time saved and output counts.
Use this structure to start. Shared data standards still need cross-organization testing.
14. The judgment I want to carry forward
V2.0 connects six things. Business direction starts with whose needs to serve. The four SOPs specify process purposes, workflow objectives and who can use each result. Roles, manuals and evaluation share a basis. Execution, acceptance, use and objective attainment have separate evidence. Performance review accounts for responsibility and can be challenged. At the end of the job we check which capabilities can be used again.
What I want to test next is whether people and AI can take one real business workflow, use the same result standards to do and hand over the work, then use the outcome to improve the method.
Atlas V1.0 aligns definitions and documents. Originality and operating effects need separate evidence.
This is a research update dated 11 November 2026, with theoretical framework V2.0 and companion atlas V1.0. It builds on pages 12–15 and 22 of the BS Diagram Collection and the two model atlases. For the theory of stakeholder value and long-term accumulation, see Stakeholder Capital Theory · Chinese text. For my thoughts on starting with one workflow, see After Bringing In AI, What Capability Does the Company Keep?.