A working framework for managing prompts, images, manuals, and constraints as versioned operational assets.
This repository is for teams and practitioners who need AI workflows to be reusable, reviewable, and stable across time — especially when prompts, images, manuals, and constraints are reused across sessions, operators, or projects.
This is not a generic prompt library, a model benchmark repository, or a collection of one-off generation tricks. It is a framework for treating operational inputs as managed assets.
This repository proposes a practical operational framework for AI asset management:
Prompts, images, manuals, constraints, and reference materials used in AI workflows should be treated as versionable operational assets — not as informal, disposable inputs.
This is not presented as a new theory. It is a practical application of established software and documentation practices to AI operational inputs.
- Read
docs/concept.md - Then read
docs/versioning_policy.md - Then inspect the templates in
docs/templates/
AI workflows are often managed informally.
Prompts are edited in place. Images are stored without version labels. Reference documents accumulate without structure. Nobody records what changed, when, or why.
This works for small, one-off tasks. It breaks down when:
- Workflows run across multiple sessions or operators
- Outputs must be reproducible or auditable
- Assets need to be shared, updated, or rolled back
- Quality regressions need to be diagnosed
In many cases, the operational bottleneck is not the model itself, but the lack of structured asset management around it.
Treat AI operational inputs as versionable assets.
That means:
- each asset has an explicit role
- each asset has a version
- changes are tracked with reasons
- rollback is always possible
- active assets are separated from archived or deprecated ones
- research materials are separated from execution materials
This is standard practice in software and documentation workflows. It is still unevenly applied in AI operations.
A Versionable AI Asset is any unit of input material used in an AI workflow that is:
- meaningful — it has a defined operational role
- bounded — it has clear scope and edges
- reusable — it can function across multiple sessions
- replaceable — it can be updated modularly without rebuilding everything
- auditable — its history is traceable
Assets may include:
| Asset Type | Examples |
|---|---|
| Identity definitions | YAML character sheets, persona specifications |
| Anchor references | Validated images, structural reference sets |
| Behavioral profiles | Tone guides, register definitions, role constraints |
| Operational manuals | Workflow instructions, session management rules |
| Constraint sets | Acceptance criteria, quality gates, hard limits |
| Lexicons | Controlled vocabulary for modifications |
| Research materials | Drift documentation, failure logs, comparative analysis |
Not every AI input needs to be managed this way. Simple, one-off prompts do not require version control.
The framework is intended for inputs that are reused, updated, shared, or relied upon over time.
This framework rests on several distinctions that are easy to blur in practice.
Execution assets are live operational materials — narrow, validated, and actively used.
Research assets are exploratory materials — broader, messier, and not yet validated for production use.
These should not be stored in the same location or mixed into the same workflows.
| Status | Meaning |
|---|---|
active |
Currently in operational use |
archive |
Preserved for rollback or comparison — not for active use |
deprecated |
No longer recommended — retained for traceability only |
experimental |
Under evaluation — not yet validated for production |
For structured definitions such as identity, behavior, and constraints, YAML can serve as the Single Source of Truth.
English-language prompts are a delivery format — a projection of the YAML definition. When generation quality degrades, one robust response is to return to the YAML source rather than continuing to patch the delivery prompt in place.
All assets should follow a three-part version scheme: MAJOR.MINOR.PATCH
| Change type | When to use | Example |
|---|---|---|
| Major | Structural redesign, core logic change | v1.0.0 → v2.0.0 |
| Minor | Meaningful improvement, new content added | v0.1.0 → v0.2.0 |
| Patch | Small corrections, formatting, typos | v0.1.0 → v0.1.1 |
Every version change should include a brief revision note explaining what changed and why.
versionable-ai-assets/
├── README.md
├── docs/
│ ├── concept.md ← Core concept document
│ ├── versioning_policy.md ← Versioning rules and rationale
│ ├── asset_taxonomy.md ← Asset types and their roles
│ └── templates/
│ ├── asset_manifest.yaml ← Template: asset metadata
│ ├── identity_core.yaml ← Template: identity definition
│ └── acceptance_criteria.md ← Template: quality criteria
└── examples/
└── (to be added)
- character-identity-protocol — A governance framework for character identity continuity in generative AI. CIP and related PAL work are downstream examples of the versionable asset approach applied to a specific domain.
This repository is in early development. The core documents are working drafts. Feedback and discussion are welcome via Issues.
This repository is currently under a draft custom license. Some materials may later be separated under different terms. Please do not reuse or redistribute without prior permission. Detailed licensing terms will be finalized in a later revision of this repository.
© 2026 Hitoshi Watadani