Framework · Version 1.0
Shuhari for AI Adoption
What this framework is
Shuhari is a centuries-old Japanese progression: shu, follow the form; ha, break it; ri, leave it. Martin applies it to organizational AI capability as three stages he calls the Foundation, the Expansion and the Transcendence. It explains why two organizations buying identical tools end up in different places, and why copying a more advanced organization usually fails.
57-word direct answer
Key takeaways
- Shuhari is not a proprietary model. It is centuries old, and this page says so plainly.
- Martin names the stages the Foundation, the Expansion and the Transcendence, mapping to shu, ha and ri.
- The stages describe capability, which accumulates through practice, not a purchasing sequence.
- The characteristic failure is attempting ri first: improvising before anyone has done the reps.
- A team in shu should follow a documented process exactly. Autonomy is earned, not assigned.
On authorship, stated plainly
Shuhari (守破離) is a traditional Japanese concept with several centuries of history in the tea ceremony, Noh theatre, and later the martial arts. It is not Martin's invention, and it is not proprietary to this site.
What is offered here is an application: a reading of the three stages as a description of how organizations build AI capability, plus the observation that most AI adoption failures are stage errors. If you have encountered shuhari through martial arts, software practice, or the tea ceremony, you already know the model. This page is about where it lands in this particular domain.
Where the concept comes from
The three-stage phrasing is generally attributed to Sen no Rikyū, the sixteenth-century tea master and poet, from a poem instructing the student to observe the rules exhaustively, then break them, then leave them, without ever forgetting the root.
It was presented to a wider public by the nineteenth-century tea master Fuhaku Kawakami, who drew on the writings of Zeami Motokiyo, the great theorist of Noh, on the stages through which a performer passes. From there it entered martial-arts pedagogy, and it is closely associated with aikido, where it is used to describe a student's progression from exact imitation to independent practice.
The kanji carry the sense directly. 守 shu is to protect or obey. 破 ha is to break or detach. 離 ri is to leave or separate.
The aikido teacher Endō Seishirō gave the articulation most often quoted: in shu, forms are repeated faithfully with no deviation; in ha, once the forms are absorbed, innovations are made and forms may be broken; in ri, one departs from the forms entirely and acts freely, without overstepping what the art permits.
The concept has also been widely borrowed in software and organizational practice over the past few decades. This page is one more borrowing, and does not pretend to be the first.
The three stages as Martin names them
The traditional kanji describe a state of mind. These names describe what an organization is actually doing, which is the more useful handle when the question is what to do on Monday. Both labels appear throughout this page, because the second is only meaningful with the first behind it.
- 守 Shu · The Foundation
- Traditionally to protect or obey. In practice: one documented process, followed exactly, on one workflow at a time. Approved tools, defined review points, and explicit permission to use AI only where policy says so. The work of this stage is reps, and the output that matters is a baseline, because without one no later improvement can be characterized honestly.
- 破 Ha · The Expansion
- Traditionally to break or detach. In practice: the process is modified now that its reasoning is understood rather than merely copied. Stages get compressed where risk is genuinely low, review requirements get matched to actual consequence instead of a blanket rule, and patterns borrowed from elsewhere get adjusted deliberately. The word is expansion because scope widens: more workflows, more people, more judgement distributed outward.
- 離 Ri · The Transcendence
- Traditionally to leave or separate. In practice: staff reason correctly about where AI belongs without consulting a policy document, because they understand what the policy was protecting. New approaches get designed for situations nobody anticipated. This is a description of a capability, not a badge, and almost no organization is here across the whole of itself.
The problem it addresses
Two organizations buy the same tools, run comparable pilots, and end up in entirely different places. One has AI woven into a dozen workflows and staff who reason well about where it should and should not be used. The other has licences, enthusiasm, and no operational change. The difference is not the tooling.
The related failure is transfer. A leader reads how a larger, more experienced organization runs AI (lightweight process, engineers improvising, few formal gates) and copies the surface. It does not work, and the conclusion drawn is usually that the approach was wrong. What actually happened is that a practice appropriate to ri was adopted by an organization in shu.
Shuhari gives that a name. Capability is a function of accumulated practice, and the appropriate amount of freedom at each stage is different. Handing autonomy to a team that has not yet done the reps is not empowerment; it is skipping the part where competence is built.
The three stages
Shuhari applied to organizational AI capability, v1.0. Capability rises with time and deliberate practice across three stages: shu, the Foundation; ha, the Expansion; ri, the Transcendence. The dashed line shows the characteristic failure: attempting ri first, without the reps that make judgment possible. Original diagram; the underlying concept is traditional. Reuse with attribution to martinzialcita.com.
The stages applied to AI capability
What each stage looks like in an organization, and the error characteristic of it.
| Stage | What the organization does | What it looks like in practice | Characteristic error |
|---|---|---|---|
| 守 Shu · The Foundation | Adopts a documented process exactly, without variation | One workflow at a time, following all five stages of the adoption framework as written. Approved tools, defined review points, explicit permission to use AI only where policy states. | Deviating early because a step feels like bureaucracy, usually the baseline or the review point |
| 破 Ha · The Expansion | Modifies the process now that its reasoning is understood | Compressing stages where the risk is genuinely low. Adapting the review requirement to the actual consequence rather than a blanket rule. Adopting patterns from elsewhere and adjusting them deliberately. | Adapting for convenience rather than reason, and losing the protection the original step provided |
| 離 Ri · The Transcendence | Works from principle rather than pattern | Staff who reason correctly about where AI belongs without consulting a policy document, because they understand what the policy protects. New approaches designed for situations nobody anticipated. | Assuming the whole organization has arrived, when in fact a few individuals have and the rest are still in shu |
These are stages of an organization's practice, not a maturity score to be claimed. An organization is usually in different stages for different functions at the same time.
Principle
Autonomy is earned through repetition, not granted by announcement. A team that has not yet followed the form exactly has no basis on which to depart from it.
Distinction
Buying a tool is a transaction and takes an afternoon. Building capability is a practice and takes stages. Most AI disappointment is the first being mistaken for the second.
Locating your organization honestly
Rough indicators. Answering shu is not a failing; it is the correct starting point for anyone who has not yet done this work.
Can a second person run your existing AI workflows?
If only the builder can operate them, the organization is in shu regardless of how sophisticated the output looks.
Is there a written record of what staff may and may not do?
In shu this should exist and be followed literally. In ri, people reason to the same conclusions without consulting it.
When you deviate from a process, is a reason recorded?
Deviation with a recorded reason is ha. Deviation without one is drift, whatever stage you believe you are in.
Do you have a baseline for any deployed workflow?
No baseline anywhere usually indicates shu, with stage two of the adoption framework skipped.
Can staff explain what a review point is protecting against?
Following a rule is shu. Explaining its purpose is ha. Correctly deciding a novel case without a rule is ri.
Would your practice survive the departure of your most enthusiastic person?
If not, capability sits with an individual rather than the organization.
When to use it, and when not to
Use it when
- Diagnosing why AI adoption has stalled despite adequate tools
- Explaining why an approach borrowed from another organization did not transfer
- Deciding how much process a team needs right now
- Designing a training sequence, in teaching or workshops
- Setting expectations with leadership about capability timelines
Do NOT use it when
- You need a procedure: use the adoption framework; this is descriptive, not procedural
- You need a maturity score for a board paper; it does not quantify, and forcing it to will mislead
- It would be used to withhold autonomy from capable people as a matter of policy
- The blocker is technical or contractual rather than developmental
- Adoption failed for trust or job-security reasons; that is a different problem, and this framing can sound dismissive of it
How this framing can be misused
Any stage model can become a way of telling people they are not ready. “You are only in shu” is an easy thing to say to someone raising a legitimate objection, and it is not what the concept is for.
In its original setting shuhari describes a relationship in which the teacher's duty is to bring the student to independence. A version used to keep an organization permanently dependent on an outside adviser has the meaning exactly backwards.
Evidence and its limits
This is an interpretive framework, not a measured one. It makes no quantitative claim, has not been validated in a study, and no effect size should be inferred from it.
It is used in teaching and workshops because it reliably helps people locate their situation, and because it reframes “our AI project failed” into the more tractable “we attempted a stage we had not reached”. That is practitioner experience, not evidence.
The strongest honest claim: it is a useful diagnostic lens with a long history in other domains. If it does not help you, it costs nothing to discard.
Relationship to other frameworks
The Practical AI Adoption Framework is the procedural companion. It governs a single workflow; shuhari describes capability across many, over time. In practice an organization runs the adoption framework repeatedly while moving through these stages, and how strictly it should follow that framework is precisely what its shuhari stage tells you.
It sits alongside capability-maturity thinking generally, and shares the obvious weakness of all stage models: real organizations are in several stages at once, and the boundaries are interpretive rather than measured.
For the people-side questions this raises (training, resistance, psychological safety, job design) see AI workforce readiness.
How to cite
For this application: Zialcita, M. (2026). Shuhari for AI Adoption, version 1.0. martinzialcita.com. https://martinzialcita.com/shuhari/
For the underlying concept, cite the tradition rather than this page. Shuhari long predates any modern application and attributing it here would be inaccurate.
The diagram may be reproduced with attribution to martinzialcita.com. This page prints cleanly to PDF.
Sources on the concept
For the history rather than the AI application. The Zeami treatises are the deepest primary route into the underlying theory of stages.
- On the Art of the Nō Drama: The Major Treatises of Zeami Motokiyo (1984, ISBN 978-0691101545)Princeton University Press
- Shuhari: concept, attribution and stage definitionsWikipedia (overview and onward references)
Version history
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-07-31 | Rewritten on the retained URL. Historical attribution corrected and sourced; proprietary framing removed; boundaries and misuse section added. |
The previous version of this page presented shuhari in terms that implied a proprietary system. That framing was inaccurate and has been withdrawn.
Frequently asked questions
Did Martin create shuhari?
No. Shuhari is a traditional Japanese concept with several centuries of history, associated with Sen no Rikyū, popularized by the tea master Fuhaku Kawakami drawing on Zeami Motokiyo's writings on Noh, and later central to aikido pedagogy.
The contribution on this page is the application to organizational AI capability. An earlier version of this site framed it as a proprietary system, which was inaccurate, and that framing has been withdrawn.
How long does a stage take?
There is no schedule, and any number offered would be invented. Progression depends on the volume of real practice, not elapsed time. An organization can spend two years in shu without accumulating reps, or move through it in months with concentrated work.
A more useful question than “how long” is “how many workflows have we actually taken from observation to a measured result?” Capability follows that count.
Is it possible to skip shu?
Not usefully, and attempting it is the failure the framework is best at explaining. Improvisation without reps produces workflows nobody can operate, permissions nobody can account for, and results nobody can substantiate.
An organization can move through shu quickly by doing the work deliberately. It cannot arrive at ri by declaring that its culture prefers autonomy.
Can different parts of an organization be in different stages?
Almost always, and treating the organization as a single point on the scale is the most common misuse.
A marketing team on its fifth AI workflow may be in ha while finance has not started. The practical implication is that process should be set per function rather than as a single organization-wide policy.