Why We Named it "Joseki"
Go is an ancient strategy game with simple rules and almost incomprehensible complexity. Over centuries of play, Go players documented recurring sequences of moves called joseki. A joseki is a studied pattern, usually played in a corner, that leaves both players with a reasonable result. One player may receive secure territory while the other gains influence toward the center.
But a joseki is not automatically the correct move.
A sequence that works well in one game may be a serious mistake in another. The surrounding stones, direction of play and broader strategy all matter. Memorizing the pattern without understanding its purpose can leave a player locally satisfied but globally defeated.
This combination of reuse and judgment is what makes joseki a useful way to think about artificial intelligence.
Beyond the “Perfect Prompt”
Organizations often treat prompts as isolated pieces of text. A useful prompt is copied into a document, pasted into Slack, modified by another employee and eventually placed into production. The evaluation criteria may live somewhere else. The safety policy may exist only in a vendor dashboard. No one may know which version was actually used.
This becomes more serious as AI systems move beyond experimentation. It is not enough to know what instructions were given to a model. Teams must also know which version was used, which models it works with, how it was tested, what data accompanied it and who is permitted to use it.
This is the purpose of Joseki:WrapperHub.
Joseki allows organizations to package the full behavior of an AI system into a reusable, versioned unit. A Behavior Package can include the prompt, examples, adapters, evaluation suites, safety policies, installation requirements, licensing information and evidence of provenance. Instead of copying prompts between projects, teams can install, inspect, test and roll back a defined package.
The distinction is that: a prompt library stores text, Joseki stores a behavior contract: what the system is intended to do, how it was produced, how it was evaluated and under what conditions it should be trusted.
Established Patterns, Not Blind Automation
Like a Go joseki, a Behavior Package is not guaranteed to work in every context. A package may perform well on one model and fail after a provider update. It may require different safety rules in another organization or behave unpredictably in another language.
The answer is not to abandon reusable patterns but to make them visible, testable and responsive to changing conditions.
Joseki therefore helps users see whether a package still works across different models and versions. Instead of relying on a stale “last updated” date, teams can evaluate whether a behavior remains reliable in the environment where they intend to use it.
The broader challenge of rapid technical growth is often solved through new abstractions. Industrial standards made mass production manageable. Internet protocols organized digital communication. AI needs similar frameworks for packaging, evaluating and governing behavior.
A Go player studies joseki so that every familiar position does not have to be solved again from first principles. An AI team should not have to rebuild its prompts, evaluations, safety rules and documentation every time it changes models.
That is the idea behind Joseki: share the behavior, not just the prompt.