InstructVault (ivault)
Version prompts in Git, test them in CI, load them locally at runtime.
Prompts live as YAML/JSON files. Changes go through PRs and CI, releases are pinned by tag or SHA, and your app renders them from a local checkout or a bundle artifact — no hosted registry in the request path.
Quickstart
pip install instructvault
ivault init # scaffold prompts/, datasets/, CI workflow
ivault validate prompts # check every prompt spec
ivault render prompts/hello_world.prompt.yml --vars '{"name":"Ava"}'
A prompt looks like this
# prompts/support_reply.prompt.yml
spec_version: "1.0"
name: support_reply
modelParameters:
model: gpt-4o
temperature: 0.3
variables:
required: [ticket_text]
optional: [customer_name]
messages:
- role: system
content: "You are a concise, empathetic support engineer."
- role: user
content: |
Customer: {{ customer_name | default("there") }}
Ticket: {{ ticket_text }}
tests: # at least one test is required
- name: includes_ticket
vars: { ticket_text: "My order arrived damaged." }
assert: { contains_all: ["Ticket:"] }
Use it in your app
render() returns a list of {role, content} messages that also carries the spec's model config, so it drops straight into any client:
from openai import OpenAI
from instructvault import InstructVault
client = OpenAI()
vault = InstructVault(repo_root=".") # or bundle_path="out/ivault.bundle.json"
result = vault.render(
"prompts/support_reply.prompt.yml",
vars={"ticket_text": "My order is delayed", "customer_name": "Ava"},
ref="prompts/v1.0.0", # pin to a tag/SHA (omit for working tree)
)
response = client.chat.completions.create(**result.to_openai())
result is a plain list, so for m in result: m.content still works. Adapters: .to_openai(), .to_anthropic(), .to_litellm(), .to_dict().
CLI
| Command | Purpose |
|---|---|
ivault init |
Scaffold prompts/, datasets/, and a CI workflow |
ivault validate <path> |
Validate prompt specs (add --policy for custom rules) |
ivault lint <path> --fail-under warning |
Quality gate: report prompt smells (secrets, missing docs), score, and gate CI |
ivault render <prompt> --vars '{...}' |
Render messages locally |
ivault eval <prompt> --report out/report.json --junit out/junit.xml |
Run tests/datasets, emit reports |
ivault diff <prompt> --ref1 <a> --ref2 <b> |
Diff a prompt across two refs |
ivault bundle --prompts prompts --out out/ivault.bundle.json --ref <tag> |
Build a deployable bundle |
ivault lock --prompts prompts --out ivault.lock.json |
Write a content-addressed lockfile |
ivault verify ivault.lock.json |
Fail if prompts drift from the lockfile |
ivault schema --out schemas/prompt.schema.json |
Emit the prompt JSON Schema |
ivault resolve <ref> / ivault migrate prompts |
Resolve a ref to a SHA / migrate specs |
By default eval asserts against the rendered prompt — fully deterministic, no network. Add --provider openai to instead call a model and assert on its reply (needs OPENAI_API_KEY), or --provider ollama to run against a local model (defaults to http://127.0.0.1:11434, override with OLLAMA_HOST). Network is strictly opt-in, so CI stays deterministic unless you ask for a provider.
Where it fits
| Approach | Versioned in Git | CI-friendly | Local runtime | Hosted dependency |
|---|---|---|---|---|
| Prompt strings in app code | Partial | Partial | Yes | No |
| Prompts in a database / admin UI | Usually not | Usually not | No | Usually yes |
| Hosted prompt registry/platform | Varies | Varies | Usually no | Yes |
| InstructVault | Yes | Yes | Yes | No |
flowchart LR
A[Prompt files] --> B[PR review] --> C[CI validate + eval] --> D[Tag, SHA, or bundle] --> E[App runtime]
Develop locally
git clone https://github.com/05satyam/instruct_vault.git
cd instruct_vault
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
python -m pytest
Docs & examples
docs/dropin_guide.md— add InstructVault to an existing CI/CD repodocs/cookbooks.md— OpenAI, LangChain, LlamaIndex, RAG, policies, bundlesdocs/lockfiles_and_judge.md— reproducible releases + LLM-as-judge evalsdocs/lint.md— the prompt quality gate (ivault lint) and rule catalogdocs/spec.md— prompt spec and validation rulesdocs/ci.md·docs/governance.md·docs/stability.md·docs/roadmap.md·docs/performance.md- Examples:
examples/ivault_demo_template,examples/llamaindex_demo,examples/notebooks,examples/policies
License
Apache-2.0
Metadata
Release files for instructvault 0.7.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| instructvault-0.7.1.tar.gz | 2.1 MB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| instructvault-0.7.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 2.2 MB
Release files / instructvault-0.7.1.tar.gz
| Download URL | instructvault-0.7.1.tar.gz |
|---|---|
| Size | 2.1 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4dfd3feff2145327b2159fb6beb4628491a6e44790a0e726d7a08625003c4113
|
|
BLAKE2b-256 checksum How to use checksums |
bb4af83fc673446f1263b88f171ce15c58e1e6a98a18107ce02dacc00a800933
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.11.15
|
Release files / instructvault-0.7.1-py3-none-any.whl
| Download URL | instructvault-0.7.1-py3-none-any.whl |
|---|---|
| Size | 27.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
88da40fdfe7ac98882c3f58d281df45bf3f8a1038d412a871f0755461d79f6a7
|
|
BLAKE2b-256 checksum How to use checksums |
b7b4f52ad49afeeac0a360ffb992b993536c5b07b121daa016df89a35024b3bf
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.11.15
|
Security for instructvault 0.7.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.