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 Build with Hanzo

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.

All sixty-four, in the traditional King Wen order.

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?

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?

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?

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

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

Observe

Identify the actual condition of the system.

Separate

Untangle concerns that change for different reasons.

Reduce

Find the smallest complete set of concepts.

Compose

Combine orthogonal primitives into greater capability.

Verify

Measure behavior instead of trusting intention.

Adapt

Respond to evidence without abandoning the foundation.

Distribute

Place data, computation and authority where they belong.

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.

Hanzo Cloud

A unified control plane assembled from interoperable services rather than a closed, inseparable platform.

Hanzo Engine

Efficient execution built around measurable performance, hardware awareness and composable runtimes.

Hanzo Router

Model choice treated as a changing systems problem—balancing capability, latency, cost, privacy and availability.

Hanzo Network

Distributed intelligence designed to reduce centralized dependence and share value with those who contribute compute, models, code and knowledge.

Hanzo Open Source

Infrastructure that can be inspected, operated, modified and carried forward by the people who depend upon it.

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 Read the research View the source