# The Zen of Hanzo — 64 patterns for intelligent systems > The I Ching read as a systems philosophy for artificial intelligence. Sixty-four patterns for building intelligence that stays open, understandable, adaptable and controlled by the people who use it. # The Zen of Hanzo 64 patterns for intelligent systems The I Ching is a map of change. Its 64 hexagrams describe recurring conditions: creation, resistance, conflict, growth, decay, transformation, completion and renewal. Hanzo interprets these patterns for the age of artificial intelligence. Not as fortune-telling. Not as decoration. As a systems philosophy — a framework for building intelligence that remains open, understandable, adaptable and controlled by the people who use it. [Explore the 64 patterns](#patterns)[Build with Hanzo](https://cloud.hanzo.ai) The premise ## Intelligence is always changing No intelligent system remains fixed. Models learn. Data changes. Infrastructure fails. Organizations grow. Interfaces become dependencies. Successful architectures eventually meet conditions they were never designed to handle. The goal is not to prevent change. The goal is to build systems capable of changing without losing their integrity. That is the Zen of Hanzo. Five traditions ## Ancient patterns, modern engineering Hanzo brings together five complementary traditions. ### I Ching Understand the condition. The 64 hexagrams form a language for recognizing recurring states of change. Before acting, understand what kind of situation the system is in. Creation requires a different response than obstruction. Abundance requires a different response than scarcity. Completion requires a different response than beginning. ### Zen See without attachment. Approach every system with beginner's mind. Do not defend an abstraction simply because it already exists. Do not confuse complexity with sophistication. Observe reality directly, remove what is unnecessary and remain willing to begin again. ### Curry Compose from primitives. Haskell Curry's combinatory logic demonstrates how expressive systems can emerge from a small foundation of composable operations. Build small components. Give each a precise meaning. Compose them without hidden coupling. Let finite primitives produce unbounded capability. ### Hickey Untangle complexity. Rich Hickey distinguishes what is genuinely simple from what is merely easy to access. Convenience can conceal entanglement. Hanzo separates identity from state, policy from execution, data from process and capability from interface. Systems become understandable when independent concerns remain independent. ### Pike Cover the space with fewer ideas. Rob Pike's engineering philosophy favors small sets of orthogonal features that interact predictably. The objective is not the smallest feature count. The objective is the smallest coherent basis capable of expressing the whole system. The synthesis ## Five operating laws - 01 ### See the system clearly Understand the current condition before prescribing action. - 02 ### Separate what changes independently Do not bind together concepts that evolve for different reasons. - 03 ### Compose capability from complete primitives Small components should combine without central coordination or hidden behavior. - 04 ### Preserve the user's authority The user should control their models, data, keys, infrastructure and economic participation. - 05 ### Design for the next transformation Every completed system is already approaching its next condition. The 64 patterns ## Every hexagram is active Each represents a condition that can appear in a model, an application, a company, a network or an entire technological ecosystem. The classical title names the condition. The Hanzo principle defines how we respond. Sequence Matrix Lenses All sixty-four, in the traditional King Wen order. I ### Origination 01–08 ䷀01The Creative — Initiative HeavenoverHeaven Principle Create from first principles. In practice Do not begin with inherited limitations. Establish the essential force of the system before adding conventions, integrations or optimization. Ask What should exist that does not exist yet? ䷁02The Receptive — Grounding EarthoverEarth Principle Build upon reality. In practice Listen to users, environments, constraints and evidence. Strong foundations receive information before imposing structure. Ask What is reality already telling us? ䷂03Difficulty at the Beginning — Emergence WateroverThunder Principle Expect disorder at inception. In practice New systems begin with incomplete information, unstable interfaces and competing possibilities. Establish roots before pursuing speed. Ask What must become stable first? ䷃04Youthful Folly — Beginner's Mind MountainoverWater Principle Learn before claiming certainty. In practice Seek guidance, test assumptions and remain open to correction. Expertise without curiosity becomes blindness. Ask What are we assuming we already understand? Lenses Zen ䷄05Waiting — Readiness WateroverHeaven Principle Preparation is action. In practice Build capacity, gather evidence and allow conditions to mature. Do not force execution before the system can support it. Ask What can be prepared while timing develops? ䷅06Conflict — Resolution HeavenoverWater Principle Make disagreement explicit. In practice Most technical conflict begins with unclear ownership, contradictory contracts or hidden assumptions. Resolve the structure, not merely the argument. Ask Which boundary or contract is ambiguous? ䷆07The Army — Coordination EarthoverWater Principle Concentrate force through structure. In practice Clear roles, shared protocols and disciplined execution turn many independent actors into a coherent system. Ask Who decides, who executes and who verifies? ䷇08Holding Together — Cohesion WateroverEarth Principle Organize around trust. In practice Networks endure when participants share protocols, incentives and a reliable center of coordination without surrendering their autonomy. Ask What causes the system to remain coherent? II ### Formation 09–16 ䷈09Small Taming — Incremental Control WindoverHeaven Principle Small constraints shape large systems. In practice Rate limits, types, tests, schemas and permissions quietly determine whether power becomes useful or chaotic. Ask Which small constraint prevents a large failure? ䷉10Treading — Careful Operation HeavenoverLake Principle Move with awareness. In practice Powerful infrastructure must be approached with explicit permissions, safe defaults and respect for consequences. Ask Where does one careless action create disproportionate risk? ䷊11Peace — Alignment EarthoverHeaven Principle Allow value to flow. In practice Systems thrive when layers communicate cleanly, incentives align and information can move without unnecessary obstruction. Ask Where is useful flow being interrupted? ䷋12Standstill — Decoupling HeavenoverEarth Principle Recognize blocked circulation. In practice When systems stop communicating, adding more force often increases failure. Isolate the obstruction and restore the channel. Ask What has stopped moving, and why? ䷌13Fellowship — Open Collaboration HeavenoverFire Principle Build across boundaries. In practice Shared standards, open protocols and public knowledge allow independent teams to create more than any closed organization can alone. Ask What becomes possible when others can participate? ䷍14Great Possession — Stewardship FireoverHeaven Principle Abundance creates responsibility. In practice Compute, data, capital and reach should increase what a system contributes—not merely what its owners can extract. Ask What responsibility comes with this capability? ䷎15Modesty — Humility EarthoverMountain Principle Let evidence outrank ego. In practice Make the smallest claim supported by reality. Quietly functioning systems are more valuable than loudly advertised possibilities. Ask What do the results actually justify? Lenses ZenHickey ䷏16Enthusiasm — Mobilization ThunderoverEarth Principle Direct energy through structure. In practice Momentum becomes productive when people understand the purpose, the path and their role in moving it forward. Ask Is excitement attached to executable direction? III ### Correction 17–24 ䷐17Following — Adaptation LakeoverThunder Principle Follow reality rather than forcing it. In practice Good systems respond to user behavior, operational evidence and changing environments without abandoning their principles. Ask What signal should the system follow? ䷑18Work on the Decayed — Refactoring MountainoverWind Principle Repair the cause, not the symptom. In practice Inherited complexity, stale assumptions and hidden debt must be exposed and corrected at their source. Ask Which old decision is creating today's failure? Lenses Hickey ䷒19Approach — Accessibility EarthoverLake Principle Bring capability closer. In practice Intelligence becomes valuable when it is understandable, affordable and available where people already work. Ask What distance stands between capability and use? ䷓20Contemplation — Observability WindoverEarth Principle See the whole before intervening. In practice Logs, metrics, traces, evaluations and direct observation transform invisible behavior into understandable systems. Ask What can happen that we cannot currently see? Lenses Zen ䷔21Biting Through — Enforcement FireoverThunder Principle Remove hard obstructions decisively. In practice Policies that cannot execute are merely suggestions. Security, validation and governance must operate at the point of action. Ask Which rule must become executable? ䷕22Grace — Interface MountainoverFire Principle Beauty should reveal structure. In practice Design should make the system easier to understand and operate, not decorate confusion or hide unfinished behavior. Ask Does the interface clarify the underlying model? ䷖23Splitting Apart — Decomposition MountainoverEarth Principle Let failing structures fall away. In practice Separate the durable core from layers that have become fragile, coupled or obsolete. Ask What can be removed without weakening the essence? Lenses Hickey ䷗24Return — Reversibility EarthoverThunder Principle Make return possible. In practice Rollback, recovery, versioning, checkpoints and reproducibility allow experimentation without permanent damage. Ask How does the system return to a known state? IV ### Power 25–32 ䷘25Innocence — Integrity HeavenoverThunder Principle Avoid contrivance. In practice Behavior should follow explicit rules rather than hidden manipulation, accidental side effects or clever exceptions. Ask Is the system behaving according to its stated model? ䷙26Great Taming — Capacity MountainoverHeaven Principle Accumulate strength before expansion. In practice Knowledge, compute, liquidity, testing and operational maturity should precede the demand placed upon them. Ask Which capacity must be built before scale? ䷚27Nourishment — Inputs MountainoverThunder Principle Systems become what they consume. In practice Data, prompts, context, dependencies, feedback and incentives determine the intelligence that emerges. Ask What are we feeding the system? ䷛28Great Exceeding — Load Bearing LakeoverWind Principle Extraordinary load requires extraordinary support. In practice Know when normal architecture is carrying conditions beyond its intended limits. Ask Which component is carrying too much weight? ䷜29The Abyss — Resilience WateroverWater Principle Design for repeated danger. In practice Reliable systems assume failures will recur. Recovery must be automatic, tested and stronger than a single fallback. Ask What happens when the same failure occurs again? ䷝30Clinging Fire — Legibility FireoverFire Principle Illuminate cause and consequence. In practice State, ownership, policy and execution should remain visible enough for people to understand what the system is doing. Ask What remains hidden during execution? ䷞31Influence — Resonance LakeoverMountain Principle Invite adoption rather than forcing it. In practice Systems spread when they fit naturally into existing behavior and create immediate reciprocal value. Ask Why would someone willingly carry this forward? ䷟32Duration — Stability ThunderoverWind Principle Preserve meaning across time. In practice APIs, formats, identities and promises should remain stable enough for others to build upon them confidently. Ask Which contract must remain dependable? V ### Adaptation 33–40 ䷠33Retreat — Strategic Withdrawal HeavenoverMountain Principle Know when to stop. In practice Disable, isolate, deprecate or leave a path before sunk cost turns a recoverable mistake into systemic damage. Ask What should we stop defending? Lenses Zen ䷡34Great Power — Controlled Power ThunderoverHeaven Principle Strength requires restraint. In practice The more capable a model or platform becomes, the more explicit its boundaries, permissions and accountability must become. Ask What controls this power? ䷢35Progress — Iteration FireoverEarth Principle Advance visibly and cumulatively. In practice Small improvements become transformational when they can be measured, retained and built upon. Ask What did this iteration prove? ䷣36Darkening of the Light — Confidentiality EarthoverFire Principle Protect intelligence when exposure is dangerous. In practice Privacy, encryption and local execution preserve valuable knowledge under hostile or untrusted conditions. Ask What must remain concealed to remain safe? ䷤37The Family — Locality WindoverFire Principle Define local responsibility. In practice Strong global systems emerge from understandable local units with clear roles, authority and internal coherence. Ask Is responsibility clear within every local boundary? ䷥38Opposition — Diversity FireoverLake Principle Preserve useful difference. In practice Models, architectures and contributors do not need to agree in order to improve one another. Diversity can expose blind spots and increase resilience. Ask Which disagreement contains useful information? ䷦39Obstruction — Constraint Discovery WateroverMountain Principle Let obstacles teach. In practice Repeated friction reveals where an abstraction, workflow or assumption no longer matches reality. Ask What is this obstruction telling us about the design? ䷧40Deliverance — Simplification ThunderoverWater Principle Release trapped capacity. In practice Remove accidental complexity, obsolete coordination and unnecessary dependencies. Ask What becomes possible after this constraint disappears? Lenses Hickey VI ### Transformation 41–48 ䷨41Decrease — Minimalism MountainoverLake Principle Subtract deliberately. In practice Remove features, states and concepts until the remaining system expresses its purpose without waste. Ask What can disappear? Lenses ZenHickeyPike ䷩42Increase — Leverage WindoverThunder Principle Add where value compounds. In practice The best improvements strengthen many products, users or layers simultaneously. Ask Which addition multiplies the capability of everything around it? ䷪43Breakthrough — Decision LakeoverHeaven Principle Make truth explicit. In practice Decisive change requires clear evidence, declared intent and responsibility for the consequences. Ask Which decision can no longer remain implicit? ䷫44Coming to Meet — Boundary Control HeavenoverWind Principle Treat arrivals as consequential. In practice A new model, dependency, contributor or external service may alter the system more deeply than expected. Ask What authority are we granting to what just entered? ䷬45Gathering Together — Ecosystem LakeoverEarth Principle Create a center for participation. In practice Models, tools, compute, knowledge and contributors become more valuable when they can discover and compose with one another. Ask What shared center allows independent contribution? Lenses Curry ䷭46Pushing Upward — Layering EarthoverWind Principle Grow from stable foundations. In practice Higher abstractions should preserve the strength and meaning of the layers beneath them. Ask Is every new layer supported by a complete lower layer? Lenses Curry ䷮47Oppression — Graceful Degradation LakeoverWater Principle Remain useful under constraint. In practice When memory, compute, bandwidth or external services disappear, the system should preserve its most essential function. Ask What remains available in the worst operating condition? ䷯48The Well — Shared Infrastructure WateroverWind Principle Build resources many can draw from. In practice Protocols, open models, public research and common infrastructure create persistent value beyond a single product. Ask What shared resource are we maintaining? VII ### Renewal 49–56 ䷰49Revolution — Migration LakeoverFire Principle Replace foundations honestly. In practice When incremental repair can no longer preserve integrity, design a controlled transition to a new system. Ask Has repair become more dangerous than replacement? ䷱50The Cauldron — Transformation FireoverWind Principle Turn raw material into capability. In practice Stable processes convert data, research, compute and human knowledge into useful intelligence. Ask What transformation does this system perform? ䷲51Thunder — Responsiveness ThunderoverThunder Principle Respond without panic. In practice Detect important change quickly and execute a prepared response before disruption becomes collapse. Ask Which event requires immediate coordinated action? ䷳52Keeping Still — Boundaries MountainoverMountain Principle Know where action must stop. In practice Every component, agent and person should have explicit limits on authority, execution and access. Ask Where is the stopping condition? Lenses Pike ䷴53Development — Gradualism WindoverMountain Principle Mature through ordered stages. In practice Durable systems progress through tested transitions rather than skipping directly from prototype to critical infrastructure. Ask Which stage cannot safely be skipped? ䷵54The Marrying Maiden — Integration Risk ThunderoverLake Principle Understand asymmetric dependence. In practice External integrations can place the system in a secondary position with limited authority over its own future. Ask Who controls the relationship after integration? ䷶55Abundance — Operational Clarity ThunderoverFire Principle Simplify at the moment of maximum complexity. In practice As systems become more powerful, commands, ownership and communication must become clearer. Ask Can the system still be understood at peak scale? ䷷56The Wanderer — Portability FireoverMountain Principle Build systems that can travel. In practice Models, workloads and data should move across clouds, devices, regions and organizations without losing their identity. Ask Can this operate somewhere we do not control? VIII ### Continuity 57–64 ䷸57The Gentle Wind — Composability WindoverWind Principle Spread through small, consistent interfaces. In practice Simple primitives that penetrate every layer can produce systems of indefinite capability. Ask Can this combine cleanly with something we have not yet imagined? Lenses CurryPike ䷹58The Joyous Lake — Exchange LakeoverLake Principle Create reciprocal communication. In practice Open dialogue, feedback and shared knowledge make systems more useful and communities more resilient. Ask How does value return through the interaction? ䷺59Dispersion — Distribution WindoverWater Principle Dissolve rigid centers. In practice Distribute computation, state and authority where doing so increases resilience, privacy and participation. Ask Which central dependency should be dispersed? ䷻60Limitation — Constraints WateroverLake Principle Use limits to create freedom. In practice Clear types, interfaces, quotas and policies make behavior predictable enough for people to build confidently. Ask Which constraint makes the system easier to reason about? Lenses Pike ䷼61Inner Truth — Verifiability WindoverLake Principle Make trust emerge from structure. In practice Proofs, signatures, evaluations, traces and reproducible behavior are stronger than institutional promises. Ask How can this claim be independently verified? Lenses Curry ䷽62Small Exceeding — Precision ThunderoverMountain Principle Treat small details as structural. In practice In delicate systems, minor inconsistencies can produce consequences larger than ambitious architectural decisions. Ask Which small detail could invalidate the whole? ䷾63After Completion — Operational Discipline WateroverFire Principle Completion is a dangerous state. In practice When every component appears correctly positioned, complacency becomes the primary risk. Observe, maintain and prepare for drift. Ask What could quietly deteriorate after launch? ䷿64Before Completion — Continuous Becoming FireoverWater Principle No system is final. In practice Every release, model and architecture is a transition toward another condition. Build so that the next change remains possible. Ask What must remain open for what comes next? Lenses Zen The method ## How we build 01 ### Observe Identify the actual condition of the system. 02 ### Separate Untangle concerns that change for different reasons. 03 ### Reduce Find the smallest complete set of concepts. 04 ### Compose Combine orthogonal primitives into greater capability. 05 ### Verify Measure behavior instead of trusting intention. 06 ### Adapt Respond to evidence without abandoning the foundation. 07 ### Distribute Place data, computation and authority where they belong. 08 ### Continue Treat every completion as the beginning of another cycle. Across the stack ## One philosophy [### Hanzo Models Open and adaptable intelligence across language, vision, audio, code, tools and physical systems.](https://hanzo.ai/models)[### Hanzo Cloud One control plane, assembled from services you can take apart.](https://hanzo.ai/cloud)[### Hanzo Engine Efficient execution built around measurable performance, hardware awareness and composable runtimes.](https://hanzo.ai/engine)[### Hanzo Router Model choice treated as a changing systems problem—balancing capability, latency, cost, privacy and availability.](https://hanzo.ai/gateway)[### Hanzo Network Distributed intelligence designed to reduce centralized dependence and share value with those who contribute compute, models, code and knowledge.](https://hanzo.ai/network)[### Hanzo Open Source Infrastructure that can be inspected, operated, modified and carried forward by the people who depend upon it.](https://hanzo.ai/open-source) ## Build systems that can change The purpose of a philosophy is not to decorate a company. It is to make difficult decisions clearer. When we design a model, an API, an agent, a database or a network, we return to the same questions: - Is it understandable? - Is it composable? - Is it verifiable? - Can it operate privately? - Can the user leave? - Can it survive failure? - Can it evolve without being destroyed? - Does it increase human agency? The Zen of Hanzo is not a promise that systems will remain still. It is a method for building systems that remain whole while everything changes. From one line, two forces.From two forces, eight patterns.From eight patterns, sixty-four conditions.From small primitives, unbounded intelligence. [Explore Hanzo](https://hanzo.ai/)[Read the research](https://papers.hanzo.ai)[View the source](https://github.com/hanzoai)