| Item_Prototype | Fleeting |
|---|---|
| Item_ID | ove-readme |
| Title | Operating-Volume-Engineering — README |
| Date_Added | 2026-06-01 |
| Date_Modified | 2026-06-06 |
| Needs_Processing | false |
A discipline-and-toolkit for designing operating volumes — self-contained markdown corpora that an AI assistant loads to orchestrate a specific kind of work. Point any capable AI at this folder, tell it to read AI-BOOTSTRAP.md, and it will walk you through designing your own.
An operating volume (OV) is the slot in the AI lexicon between a Custom GPT / Project and an AI harness. Larger than a skill, deeper than a Custom GPT, smaller than a harness. Substrate-agnostic — it runs on Claude, GPT, Gemini, or anything else that can read markdown and parse YAML frontmatter.
An OV consists of:
- A bootstrap protocol — instructions the AI reads first to load the volume
- An engine — the operating manual the AI consults during sessions
- Templates — scaffolding for the artifacts the work produces
- Schema — the structural contract every artifact conforms to
- Cartridges — per-engagement workspaces where the actual work accumulates
- State files — durable records the AI reads and writes across sessions
Two existing operating volumes by the same author:
- SOLVE-eX — an OV for structured problem-solving and decision-making
- LifeLong-Learning — an OV for AI-orchestrated self-directed deep study
This OV is the propagator: it teaches an AI how to help you design more.
You point an AI at this folder when you want to build a new operating volume for a domain that matters to you. The AI:
- Interviews you about the domain (what kind of work, what cadence, what artifacts, what state)
- Designs the schema, cartridge shape, and session protocol with you
- Drafts the bootstrap protocol, engine files, and templates
- Walks you through scrubbing, versioning, and shipping
- Optionally drives the GitHub setup
You end the engagement with a complete, shippable OV folder — schema-validated, scrubbed of personal data, licensed, and ready to push.
- Not a no-code OV builder. The AI writes the markdown; you make the design decisions.
- Not a framework you import. There's no library; the folder is the artifact.
- Not opinionated about your domain. It works for problem-solving, learning, negotiation, relationship maintenance, writing, anything with the right shape.
- Not a substitute for thinking. Designing a good OV is real intellectual work; the AI is a competent partner, not the designer.
You just got this folder. Here's how to use it.
Plain markdown. Any environment where your AI assistant can read local files works (Claude Code, Claude Desktop, Claude.ai with Projects, ChatGPT Projects, Gemini, Cursor, Windsurf, VS Code with an AI side-panel, Obsidian, plain text editors with AI integration).
In your first message, say:
"Read
AI-BOOTSTRAP.mdand help me design a new operating volume."
Or, if you want to audit an existing OV:
"Read
AI-BOOTSTRAP.mdand help me audit [my OV name]."
The AI asks one question at a time about the domain. Don't expect a multi-bullet questionnaire — that's a documented failure mode this OV specifically guards against. Expect Socratic clarification, design proposals you can accept or push back on, and incremental construction of the new OV's files inside a cartridge here.
For environment setup, see INSTALL.md. For day-to-day operation and troubleshooting, see OPERATOR-GUIDE.md. To extend or contribute, see CONTRIBUTING.md. For one-shot AI-assisted updates when a new release ships, see UPDATE-PROMPT.md.
- AI assistant — any model capable of reading markdown and parsing YAML frontmatter (Claude Sonnet/Opus class, GPT-4 class and above, Gemini 2.x and above)
- OS — Mac, Windows, or Linux
- Editor — any text editor with AI integration; Obsidian works well; Claude Code / Cursor / Windsurf are excellent
- Python / network / runtime dependencies — none for the core flow. The optional validator at
_design-engine/_meta/validate.pyrequires Python 3.7+ standard library only.
OVs depend on two capabilities from the AI environment: file read and file write. Most modern environments support both. Some support only read — and that distinction matters because the OV's defining property is multi-session statefulness, which lives in files on disk.
| Substrate | Read | Write | Statefulness | Note |
|---|---|---|---|---|
| Claude Code, Cursor, Windsurf, VS Code with AI side-panel | ✓ | ✓ | Full | Native fit |
| Claude Desktop with local file access | ✓ | ✓ | Full | Native fit |
| JetBrains AI Assistant, Zed AI | ✓ | ✓ | Full | Native fit |
| Obsidian + Copilot-class plugins | ✓ | varies | Full when the plugin can write | Verify plugin capability |
| Claude.ai with Projects (file attachments) | ✓ | ✗ | Degraded — sandbox mode | Read-only; state must be pasted back across sessions |
| ChatGPT Projects, Custom GPTs (file attachments) | ✓ | ✗ | Degraded — sandbox mode | Same as above |
| Gemini, generic chat with pasted files | ✓ | ✗ | Degraded — sandbox mode | Same as above |
Sandbox mode. When the AI cannot persist _design-state.md or write to <Cartridge>/Sessions/, the OV's core contract is broken — state must be re-asserted by the user each session. The AI's first response must announce sandbox mode explicitly so the user can decide to (a) keep the engagement to a single session, or (b) paste the latest state back at the next session start. Silent absorption of sandbox mode is the failure to catch — see _design-engine/02-DESIGN-PRINCIPLES.md P2/P6 and the canonical readiness-statement specification in _design-engine/00-START-HERE.md.
Sandbox mode is a real and supported way to use this folder; it just isn't the default and it isn't free.
| Folder / file | Contents |
|---|---|
AI-BOOTSTRAP.md |
AI entry point — first file the AI reads |
README.md |
This file |
INSTALL.md |
Setup instructions |
OPERATOR-GUIDE.md |
Day-to-day operation and troubleshooting |
CONTRIBUTING.md |
How to extend the engine or share improvements back |
VERSION.md / CHANGELOG.md |
Release metadata and history |
LICENSE.md |
CC-BY 4.0 |
_USER.md.template |
Optional user-profile template |
_design-engine/ |
The subject-agnostic OV-design operating manual |
_design-engine/_templates/ |
Templates for every standard file an OV ships with |
_design-engine/_meta/ |
Schema-of-schemas + the failure-modes catalog |
SOLVE-eX-Retrospective/ |
Worked example: retrospective design analysis of SOLVE-eX |
LifeLong-Learning-Retrospective/ |
Worked example: retrospective design analysis of LifeLong-Learning |
Negotiation-Preparation/ |
Worked example: fresh-design walkthrough (anchor demonstration) |
Long-Form-Writing/ |
Worked example: fresh design for book/dissertation/screenplay work |
Relationship-Cultivation/ |
Worked example: fresh design for a relational-CRM-style OV |
Each cartridge contains: _ov-manifest.md, _design-state.md, _design-decisions.md, _schema-draft.md, Sessions/, Artifacts/.
The category sits at a real gap in the public AI lexicon — larger than a skill, deeper than a Custom GPT or Project, smaller than a harness. It needed a name that wasn't already claimed and that signaled what it does. Volume implies a series (you'll likely have several), carries gravitas, isn't claimed by any platform, and has the bound-self-contained-artifact feel. Operating parallels operating system — the OV is to an AI what an OS is to hardware.
The associated discipline is called operating volume engineering, parallel to prompt engineering, agent engineering, harness engineering. See _design-engine/01-WHAT-IS-AN-OV.md for the full taxonomy.
Operating-Volume-Engineering is released under the Creative Commons Attribution 4.0 International License (CC-BY 4.0). You are free to share, adapt, and build upon this material for any purpose — including commercially — provided you give appropriate attribution.
See LICENSE.md for the full license text. Attribution format:
Built on Operating-Volume-Engineering v1.0 by Jawn Lam — https://github.com/JawnLam/Operating-Volume-Engineering Licensed under CC BY 4.0.
See VERSION.md. This is the v1.0.0 initial public release.