Section 7

Application to governance

The major AI governance frameworks of the current era share a structural characteristic: they describe the outcomes of good governance with precision and the methods for achieving them with almost none. They tell organizations what they must do. They don't tell organizations how to design the work that produces the doing.

This isn't a criticism. Governance frameworks aren't methodology papers. Their job is to define standards, not to teach design. But the gap between what the frameworks require and what organizations know how to build is significant, and it has consequences. Organizations that can't design auditable human-AI workflows can't demonstrate compliance with frameworks that require auditability. Organizations that can't document where human judgment is non-delegable can't meet requirements that mandate human oversight. The gap is a design gap.

Human-AI Workflow Design fills that gap. This section maps the specific requirements of four major governance frameworks to the structural elements of the HAWD notation: showing exactly where each framework's requirements translate into diagram elements, control types, mechanism choices, and human judgment checkpoints.

The NIST AI Risk Management Framework

The NIST AI Risk Management Framework (AI RMF 1.0, 2023) organizes AI risk management into four functions: Govern, Map, Measure, and Manage. The framework is voluntary, so its core describes outcomes rather than requirements, stated as categories and subcategories under each function. The Govern and Map functions are where HAWD is most directly applicable.

The Govern function asks organizations to establish policies, processes, and accountability structures for AI risk management across the organization (GOVERN 1, GOVERN 2). It asks them to define roles and responsibilities for AI development and deployment, establish documentation practices for AI systems, and create processes for human oversight. One subcategory states the human-AI case directly: policies and procedures are to "define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems" (GOVERN 3.2). In HAWD terms, these outcomes translate directly: roles and responsibilities appear in the mechanisms rail of every workflow diagram. Documentation practices are the node narratives that accompany each diagram. Human oversight structures are the human judgment checkpoint shapes that mark where accountability is explicit and non-delegable.

The Map function asks organizations to establish and understand the context in which AI systems operate, identify the AI actors involved, and categorize the AI system (MAP 1, MAP 2). The HAWD A0 context diagram is a direct response to the Map function's requirements. A well-constructed A0 diagram shows the system's inputs, the controls governing it, the outputs it produces, and the mechanisms enabling it, which is exactly the contextual understanding the Map function requires. The boundary object shape makes explicit which outputs leave the system and enter other systems, which is directly relevant to understanding how AI-generated outputs affect downstream stakeholders.

The RMF asks that processes for human oversight be "defined, assessed, and documented" (MAP 3.5). That outcome is met by the human judgment checkpoint shape and its node narrative. When a workflow diagram shows a hexagon at a specific step, and the node narrative for that step defines what the human is deciding, what criteria they're applying, and what happens in each case, the organization has produced the documentation the RMF requires, as a structural output of the design process itself rather than a separate compliance artifact.

ISO/IEC 42001: AI management systems

ISO/IEC 42001:2023 is the first international standard for AI management systems. It requires organizations to establish, implement, maintain, and continually improve an AI management system, a structured framework for responsible AI development and use. It is also the only framework in this section an organization can be certified against, which means its requirements aren't aspirational. They're audited. That makes the mapping between its requirements and the HAWD notation the most operationally consequential in this section.

Clause 8 requires organizations to plan, implement, and control the processes needed to meet AI management system requirements, and to hold documented information sufficient to have confidence those processes were carried out as planned. Clauses 8.2 through 8.4 each separately require that documentation be retained. A HAWD diagram, together with its node narratives and glossary, constitutes a documented AI process in exactly the sense the standard requires. The diagram shows the structure. The node narratives show the procedure. The glossary keeps terminology consistent across the organization.

The sharpest correspondence sits in Annex A, the standard's normative reference controls, the set an auditor certifies against. Control A.9.2 requires the organization to define and document the processes for the responsible use of AI systems. That is the HAWD deliverable stated as an auditable control. An auditor examining A.9.2 is looking for precisely the artifact a HAWD model is: the documented process, with its governing controls named and its human oversight visible. Two further controls in the same annex reinforce the fit. A.6.2.7 requires AI system technical documentation determined by the needs of each category of interested party, which is what a node narrative is and what it's for. A.6.2.8 requires event logging across the life cycle, which the notation makes meaningful by defining which events are worth logging in the first place.

The standard's implementation guidance for responsible use reads, in effect, as a specification for the human judgment checkpoint. It asks organizations to determine at which stages of the AI system life cycle meaningful human oversight should be incorporated, to involve human reviewers with the authority to override AI decisions, and to consider whether automated decision-making is appropriate for a given use at all. Those determinations are exactly what placing a human judgment checkpoint in a diagram records. The notation is the method for making the determination the standard asks for. The diagram is the evidence it was made.

Clause 9 requires performance evaluation: the organization must monitor, measure, analyze, and evaluate its AI management system, with documented evidence of the results. The HAWD workflow design makes this tractable. A workflow with documented controls can be evaluated against those controls: is the prompt that was supposed to govern this step actually being used? Is the human judgment checkpoint being honored in practice? Is the output of the AI-assisted step meeting the quality criteria defined in the node narrative? These questions are only answerable if the workflow was designed with explicit controls and checkpoints. Without the design, evaluation is subjective. With it, evaluation is structural.

The EU AI Act

The EU AI Act, which entered into force in 2024 and applies progressively through 2027, is the most prescriptive AI governance regulation yet enacted. For high-risk AI systems, which include AI used in employment, education, access to essential services, law enforcement, and several other categories, it mandates human oversight, technical documentation, and logging of AI system operations.

Article 14 of the Act requires that high-risk AI systems be designed and developed in such a way as to allow natural persons to effectively oversee them during the period of use. It specifies that human oversight must allow the persons assigned to it to understand the capabilities and limitations of the AI system, monitor its operation, intervene and stop it when necessary, and not over-rely on its outputs.

These requirements map directly onto HAWD design principles. Understanding the capabilities and limitations of the AI system is what the AI agent shape and its node narrative provide: the mechanism is named, its governing control is documented, its output format is specified, and its limitations are noted. Monitoring operation is what the human judgment checkpoint provides: the explicit stop where a human reviews what the AI has produced before the workflow advances. The Act is specific about what that person must be able to do: disregard, override, or reverse the system's output, which is the checkpoint's definition of non-delegable authority stated in legal language. And the Act names the failure mode the checkpoint exists to prevent: automation bias, the tendency to rely or over-rely on AI output. The node narrative's human judgment criteria are the countermeasure: the practitioner gets specific questions to ask and specific standards to apply, rather than being expected to exercise undirected judgment against undocumented criteria.

Two further provisions place the workflow itself, not just the AI system, inside the regulation's scope. Article 14 distinguishes oversight measures built into the system by its provider from measures the provider identifies for the deployer to implement. That second category is workflow design: the deploying organization deciding where oversight happens, who performs it, and how it's documented. Article 26 then obligates deployers directly: human oversight must be assigned to people with the necessary competence, training, and authority, and the deployer is free to organize its own resources to implement it. For the majority of organizations, which deploy AI systems rather than build them, this is exactly the design work HAWD structures: the checkpoint places the oversight, the mechanisms rail names the role performing it, and the node narrative records what they're deciding and by what criteria.

The Act also requires technical documentation, drawn up before a high-risk system reaches the market and kept current, sufficient to demonstrate compliance. The required contents are listed in Annex IV, and most of them are system-level engineering documentation. But one required element is squarely a workflow artifact: an assessment of the human oversight measures needed in accordance with Article 14, including the measures that help deployers interpret the system's outputs. A complete HAWD model, the A0 context diagram, decomposition diagrams, node narratives, glossary, and control documentation, is that assessment in reviewable form. It records where oversight happens, who performs it, what they're deciding, and what governs the AI steps around them, in a form regulators, auditors, and the organization's own governance function can read.

The logging requirement, that high-risk AI systems maintain logs enabling the reconstruction of AI-assisted decisions, is handled at the system level by tools and sits outside the scope of notation. But HAWD makes logging meaningful by defining what should be logged. A workflow with documented controls and human judgment checkpoints defines the events that matter: was this prompt used, was this checkpoint honored, was this output reviewed before it was acted on. Without the workflow design, logs are records of activity. With it, they're records of compliance.

Board governance frameworks

Major board governance guidance on AI, including guidance from major professional services firms, governance associations, and national health authorities, converges on a consistent set of requirements: boards should understand the AI systems operating in their organizations, define where human judgment is non-negotiable, establish oversight processes, and ensure AI use fits organizational strategy and values.

These requirements are well-stated. What they consistently lack is a method for doing the design work that produces compliance with them. Telling a board that it should define where human judgment is non-negotiable doesn't tell the board how to identify those moments in the organization's workflows, make them visible to the governance function, or ensure they're consistently honoured as AI use scales.

HAWD provides that method. The human judgment checkpoint shape makes non-delegable moments visible at a glance in any diagram. The controls taxonomy makes the governing frame of every AI-assisted step explicit: board priorities, strategic framing, and organizational policies all appear as documented controls in the top rail of the function boxes they govern. The boundary object shape shows where AI-assisted outputs cross workflow boundaries and enter governance processes, exactly the visibility boards need to exercise meaningful oversight.

The worked examples in Section 6 show this mechanism directly, even outside a board setting. The relationship loop demonstrates how judgment exercised at a human checkpoint gets captured as a control that governs future runs of the workflow, exactly the movement a board needs to see: where human accountability enters, and how the organization's own priorities become the documented controls that shape what the AI does next. The same structure applies to board governance. Priorities set in a facilitated board conversation become knowledge assets in the control rail of the workflows that prepare board materials and analyze board discussions. A board reviewing that workflow can see, in the diagram, exactly where its priorities govern the AI steps and where human accountability is required, before any material reaches it.

The common gap across all frameworks

What's striking about these four frameworks, and about the broader field of AI governance guidance, is how consistently they name the same structural requirements: documented processes, explicit human oversight, auditable controls, accountable decision chains. And how consistently they stop short of the design method that would make those requirements achievable.

The NIST AI RMF asks for documented human oversight but doesn't specify how to design oversight into a workflow. ISO 42001 requires documented AI processes but doesn't provide a notation system for producing them. The EU AI Act mandates human oversight measures but doesn't define what a human oversight measure looks like in a workflow diagram. Board governance frameworks require boards to define where human judgment is non-delegable but don't give boards a visual language for doing so.

The frameworks describe the destination. Human-AI Workflow Design describes how to build the road.

Better governance writing won't fill this gap. It requires a design methodology: a shared visual language, a structured notation system, a process for translating governance requirements into workflow design. That's what Human-AI Workflow Design provides.

The notation serves governance frameworks rather than competing with them. Every HAWD diagram is an act of compliance: compliance as a design principle built into the workflow from the start, not a checklist completed after the fact. When controls are documented as part of designing the workflow, they exist. When human judgment checkpoints are placed as part of designing the workflow, they're honoured. When boundary objects are named as part of designing the workflow, the downstream governance implications are visible before the workflow runs rather than after something goes wrong.

Organizations that design their human-AI workflows using HAWD will find that much of what the major governance frameworks require is produced as a natural output of the design process. The documentation exists because the diagram requires it. The human oversight is explicit because the notation requires it. The controls are auditable because naming them is what makes the diagram complete.

Section 8 positions Human-AI Workflow Design as a versioned, living standard: the rationale for versioning, the conditions that would trigger a v2, and the invitation to extend and apply the methodology across sectors and workflow types.