Context Infrastructure
Yanzi Context Library
Five composable operational primitives — Packs, Seeds, Workflows, Rules, and Roles — that together form the governed context infrastructure for AI-assisted engineering sessions.
What the Context Library Is
The Yanzi Context Library is the governed context layer of Yanzi. It consists of five composable operational primitives — Packs, Seeds, Workflows, Rules, and Roles — that together compose the complete context for a governed AI-assisted engineering session.
Each primitive serves a distinct governance function. Each is an append-only artifact in the Yanzi corpus. Together, they ensure that every session starts from a known, governed, reproducible operational baseline.
The Five Primitives
Seeds — Governance Ground Truth
Seeds establish the authoritative baseline before any work begins. They are human-authored documents that capture what is known and governed at the project or organizational level: canonical architecture documents, technology decisions, engineering standards, compliance baselines.
Seeds are immutable once committed. They are the governance ground truth that all other context builds on.
Packs — Domain Context Bundles
Packs provide versioned, bundled context for a specific engineering domain. A Pack contains everything a model needs to operate within that domain: approved patterns, version constraints, naming conventions, known anti-patterns, and operational standards.
Packs are versioned and composable. A session applies the Pack version that was current when the work was governed. Governance changes are versioned, not silent.
Workflows — Governed Procedures
Workflows define the approved sequence of steps, decision points, and authority boundaries for a repeatable engineering operation. They are not automation scripts — they are governance documents that define how a known class of work should proceed under human oversight.
Common Workflows include PR review procedures, service onboarding sequences, incident response patterns, and release certification steps.
Rules — Unconditional Constraints
Rules define what the AI model may not do in a governed session, regardless of its Role. They represent the minimum governance constraints that apply universally: prohibited dependencies, required review gates, scope limits, escalation conditions.
Rules are append-only and versioned. A Rule in effect cannot be edited — only superseded by a new Rule revision with explicit documentation of the change.
Roles — Bounded Authority
Roles define what the AI model may act on within a specific session type. Each Role specifies a proposal scope (what the model may reason about and suggest) and an execution scope (what the model may act on without further human review).
The execution scope is always narrower than the proposal scope. This is the structural mechanism that ensures consequential decisions remain human-governed.
How the Primitives Compose
A complete governed session context is assembled from the five primitives in a defined order:
- Seeds are loaded first — establishing the governance baseline
- Packs are applied next — adding domain-specific operational context
- Rules are applied — establishing unconditional constraints
- Role is assigned — defining the session’s authority boundary
- Workflow is applied (if applicable) — establishing the procedural context for the session type
This composition is performed by yanzi rehydrate, which produces a deterministic context document from the current corpus state and the specified composition parameters.
Not an AI Feature
The five primitives are engineering infrastructure concepts, not AI product features. Their analogues in traditional engineering:
| Primitive | Traditional analogue |
|---|---|
| Seeds | Initial schema migrations, base configuration |
| Packs | Dependency packages, shared library configs |
| Workflows | Runbooks, standard operating procedures |
| Rules | Linting configs, CODEOWNERS, policy files |
| Roles | IAM policies, RBAC definitions |
These are operationally familiar structures. The Yanzi Context Library applies them to the AI context layer.
Why Composability Matters
The five primitives are designed to be independent and composable. A single organization might have:
- A set of org-level Seeds (the baseline governance ground truth)
- Multiple domain-specific Packs (backend, frontend, data, infrastructure)
- A library of Workflows for common operations
- Project-specific Rules that add to the org-level constraints
- Multiple Roles for different session types (read-only analysis, implementation, release)
Any combination of these can be composed for a specific session type. A frontend implementation session would apply the org Seeds, the frontend Pack, the org-level Rules, a frontend Role, and optionally a PR review Workflow. A backend release session would apply different primitives for its governance requirements.
The primitives are reusable across projects and composable into project-specific governance configurations. This is the library model: build once, govern many.