Section 8

Toward a standard

Human-AI Workflow Design is released as v0.9, a first version rather than a final one. The decision to version it is deliberate and reflects a specific theory of how good standards develop.

Standards released as finished products tend to become artifacts. They get cited and filed rather than used and extended. Standards released as versioned, living documents tend to become infrastructure. They get applied, tested against edge cases, pushed at the seams, and improved by the people who use them. The HAWD notation is built to be the second kind: rigorous enough to use immediately, open enough to grow through application.

This section describes what v0.9 is, what the open development year ahead of v1.0 is for, what conditions would trigger a revision, how the standard is intended to travel, and what Overlap's role as the originating studio entails.

The open year

Version 0.9 is not a draft awaiting approval, and the period that follows it is not a comment window. It is an open development year.

The distinction matters. A comment period says: we are finishing this, tell us what is wrong. An open year says: we are building this in the open, come build it. The second is what this standard has claimed about itself from the first page, and it is what the licence was chosen to permit.

Through the year following this release, Human-AI Workflow Design is open for use, adaptation, and contribution. Read it. Apply it to your own workflows. Tell us what the notation could not represent, where the building method fell short, what the governance argument missed in your context. Version 1.0 will be what the year produces.

Two kinds of contribution are anticipated, and they are deliberately different in weight.

The first is a proposal to the standard itself: a new shape, a taxonomy entry, an extension for a sector context the originating work did not anticipate. These will be rare and each one is consequential. They are reviewed by Overlap as steward, and accepted changes are credited and carried into the next version.

The second, and by far the more common, is a worked example. An organization applies the notation to a real workflow, documents what it revealed, and contributes the result. This is how most people will participate, and it is the contribution the standard most needs. A notation proves itself by being applied to work its author never imagined. A growing library of worked examples across sectors is what turns a document into a shared language.

Contributors are named. Authorship of the standard remains singular, and Overlap remains its steward, because a standard without an editor becomes incoherent and a document with a hundred authors protects no one. But the people who apply this notation, test it, and improve it will be visible in the work. That is not a courtesy. It is an accurate description of how a standard actually gets built.

What v0.9 establishes

Version 0.9 of the Human-AI Workflow Design standard establishes three things.

First, the notation itself: eight shapes, two rail taxonomies, a core principle, and a visual language for representing the structure of any human-AI workflow. These shapes were developed through application to real workflows across multiple organizational contexts. Each addition to standard IDEF0 notation earns its place by structural necessity. The notation is ready to use.

Second, the building method: the three starting questions, the hierarchical decomposition approach, the authoring discipline, the glossary requirement, and the node narrative as a structural component of every HAWD model. This method is grounded in the SADT tradition and extended for the human-AI context. It's enough for a practitioner to build a complete, well-formed HAWD model from a single session.

Third, the governance argument: the specific mapping of HAWD elements to the requirements of major AI governance frameworks, showing that well-designed HAWD models produce compliance documentation as a natural output of the design process. This argument is the primary case for organizational adoption.

What v0.9 doesn't establish: specific tool recommendations (these change too fast to be part of a notation standard), sector-specific extensions, agent-to-agent workflow patterns, or a formal certification or training system. These are candidates for future versions or companion documents.

What would trigger a revision

Beyond the ordinary work of the open year, a structural revision to the notation, a v1.1 or a v2, would be triggered by any of the following conditions.

A new structural element appears in human-AI workflows that can't be adequately represented with the current eight shapes and two taxonomies. The instrumental versus relational AI distinction in this standard emerged from applying the notation to real workflows, and later versions may surface more of the same kind. If a third structural mode of AI use shows up, one that requires a different shape or a different control relationship, that's a revision trigger.

Agent-authored controls. Workflows in which AI agents coordinate with other AI agents are usually described as a gap in existing notation. For the most part they aren't. An agent calling another agent is a function whose mechanism is an AI agent, producing an output that becomes the input to a function whose mechanism is a different one. That is ordinary decomposition, and the notation handles it. If no human judgment checkpoint appears anywhere in the chain, the diagram does not fail to represent the workflow. It tells you something true about it. The absence of the hexagon is the finding.

One thing in that picture is genuinely unresolved, and it is narrower and sharper than "we lack a representation for agentic systems." This standard defines a prompt as a designed instruction written by a human. In a mature agentic system, an orchestrating agent may generate the instruction that governs a subordinate agent at runtime. That is a control authored by a mechanism, inside a single execution, with no human in the loop. The shape exists. The taxonomy entry does not. A control with no human author is a structural question the controls taxonomy currently cannot answer, and it becomes pressing as these systems mature.

There is a second question underneath it, about what a diagram is for when the runtime path is not fully predictable. When an orchestrator decides at execution time how many sub-agents to invoke and in what order, the diagram describes what was designed to happen rather than what happened. The usual conclusion is that the diagram is therefore of limited use. The opposite is closer to the truth. A log without a design is a record of activity. A log read against a design is a record of conformance. Which controls were actually applied, which checkpoints were actually honoured, where the system departed from what it was built to do, and whether that departure was reasonable. This is the audit capability the governance frameworks ask for and none of them supply a method to produce, and it exists only because a designed model exists to compare against. The notation does not need a new shape for this. It needs organizations willing to run the comparison, and that is work for the open year rather than a defect in the standard.

Dynamically retrieved controls. A retrieval-augmented step draws its governing context from a store at query time rather than applying a control written in advance. The existing notation represents this adequately. The store is a mechanism, the AI agent draws from it, and the dual-rail property already accounts for content that governs an output while arriving through the mechanism rail. What a static diagram cannot show is that the retrieved content differs from run to run: two executions of the same step, under the same prompt, can produce different outputs if the store has changed.

The design implication is not a new shape. It is a labelling convention, and possibly a taxonomy entry, distinguishing a control that is applied statically from one that is retrieved dynamically, so that a reader knows the content varies by execution. The governance implication is handled where it belongs, and the standard already says so: the diagram defines what must be logged, and the log records what was actually retrieved. Together they reconstruct the step. Neither does it alone.

Cross-organizational workflows. The boundary object was defined to mark the edge of a workflow, and Section 6 extends it to mark the coupling between workflows inside one organization. The same logic reaches further than that. A network of organizations drawing on shared knowledge resources, pulling them into their own workflows, and contributing back to them is a system of coupled loops crossing organizational boundaries rather than functional ones. The notation appears to hold at that scale, but it has not been tested there, and the governance questions it raises are not the same ones a single organization faces. Who governs a shared control that many organizations rely on? What happens when a knowledge asset produced by one organization becomes the control governing another's AI step? This is one of the more interesting open questions in the standard, and answering it requires a network willing to model itself.

Governance-producing outputs as a named element. Section 6 shows a workflow whose outputs turn back to strengthen its own controls: judgment captured at a human checkpoint, written into the stores and guides that govern the next cycle. The current notation represents this using existing shapes, an output becomes a control, a boundary object crosses an edge. A future version may formalize the governance-producing output as a named element, if practitioners find that naming it explicitly helps them design for organizational learning rather than mere repetition.

Field evidence that a shape is being systematically misused. If practitioners consistently misapply a shape, using the human judgment checkpoint for routine reviews rather than non-delegable accountability moments, say, that's a signal the shape definition needs sharpening, not that practitioners are wrong.

A governance framework updates its requirements in a way the current notation can't support. The EU AI Act's implementation will generate specific technical guidance that may require new representational elements. ISO/IEC 42001 will be reviewed and potentially updated. New sector-specific frameworks will emerge. The standard should track these developments.

A pattern runs through several of these. The notation is more general than the problems people expect it to fail at, because the ICOM model was built to describe function and governance rather than any particular technology. Most of what is currently described as a new problem in agentic systems turns out to be an old problem in function modelling wearing new clothes. Where a genuine gap exists, it is usually narrower and more specific than the general anxiety suggests. Naming those gaps precisely is more useful than conceding them broadly.

How the standard is intended to travel

Human-AI Workflow Design is licensed under Creative Commons Attribution 4.0 International. It can be used, adapted, shared, and built upon freely, with attribution to Overlap as the originating studio.

This licensing decision reflects a specific view about how methodology standards create value. A proprietary notation system creates a dependency. An open one creates infrastructure. The goal is for HAWD to become a shared language: one that organizations, consultants, designers, and governance practitioners can all use without licensing friction, and that the communities adopting it can extend and improve.

Attribution matters as a matter of intellectual honesty, not commerce. The notation has a specific lineage: SADT, IDEF0, service design, human-AI workflow application. That lineage should be visible in how the notation travels. Organizations that adapt HAWD for a specific sector context should name their adaptation as a HAWD extension, cite the originating standard, and where possible share their extensions back with the broader community.

The standard is built to be tool-agnostic. You can implement it in Miro, Lucidchart, Figma, on a whiteboard, or in any diagramming tool that supports custom shapes. Overlap maintains a Miro-based reference implementation with a custom shape library, available as a companion resource. That implementation is one way to apply the standard, not the standard itself. Organizations are free to implement it in whatever tool fits their working environment.

Overlap's role as steward

Overlap is the originating studio of the Human-AI Workflow Design standard. As steward, Overlap maintains the notation, publishes revisions, builds the case library of applied examples, and develops companion resources including the AI tool capability map, the node narrative template, and sector-specific guidance documents.

Stewardship doesn't mean ownership in a restrictive sense. Overlap doesn't control how the notation is used or extended. It does maintain the canonical version of the standard, the document you're reading, and takes responsibility for the quality and rigor of what carries the HAWD name.

Overlap applies the HAWD methodology in its consulting practice, with nonprofit organizations, foundations, and corporate governance functions. Every client engagement tests the notation against real organizational workflows. The insights from those engagements feed back into the standard. The worked examples in Section 6 are real workflows that have shaped how the notation developed.

This recursive relationship is a bit meta: the methodology describes how to design human-AI workflows, and developing the methodology was itself a human-AI workflow that the methodology can describe. The standard was developed through sustained human-AI collaboration. The thinking is human. The writing is collaborative. The notation is a product of applying the same discipline it describes: iterative, controlled, with human judgment at every significant decision point.

The agent design argument

There's a downstream benefit to the HAWD methodology beyond documentation and governance, and it's a forward-looking claim.

Practitioners who learn to read and write HAWD diagrams will become better at designing AI agents and AI-native systems.

This is because the notation forces clarity about three things agent design requires: what a mechanism needs to do its work (the input and the control), what governs how the mechanism operates (the prompt and the knowledge assets in the control rail), and where human judgment must stay in the loop (the human judgment checkpoint). Those are agent architecture questions. A practitioner who has learned to diagram a workflow in HAWD notation has internalized the discipline good agent design requires, before they ever write a line of configuration.

As organizations move from AI-assisted workflows to agentic workflows, where AI agents orchestrate multi-step processes with minimal human involvement at each step, the design discipline HAWD establishes becomes more important, not less. The risks of undocumented controls and absent human judgment checkpoints grow as automation grows. HAWD is infrastructure for the next wave of AI deployment, not just a methodology for the current moment.

An invitation

The standard is v0.9. It's complete enough to use, rigorous enough to cite, and open enough to extend. What it needs now is application: to workflows, sectors, and organizational contexts the originating work didn't anticipate.

Apply it. Document what you find. Contribute a worked example. Share what the notation can't represent, what the building method needs, what the governance argument misses in your context. Propose an extension if you have one. The standard will improve through use, and the year ahead exists for exactly that.

The goal is a shared visual language for human-AI workflow design that belongs to everyone who uses it, not a perfect notation system produced by one studio, because the problem it addresses belongs to everyone who works alongside AI.