The VIBES Standard

Verifiable Inventory of Bot-Engineered Signals — an open standard for tracking, verifying, and attesting AI involvement in software and agent workflows.

Why This Matters

AI is generating production code at an accelerating pace. But the industry has no standard way to record what was generated, by which model, with what instructions, or how the model reasoned. Every AI-produced artifact is a black box the moment it lands in your codebase.

VIBES changes that by defining a structured, tool-agnostic data format for recording AI involvement. The data it captures has immediate value — and opens the door to use cases the industry is only beginning to explore.

What You Can Do Today

What VIBES Data Enables Next

VIBES intentionally captures data without prescribing what to do with it. The base standard is a telemetry layer — a structured signal that downstream systems can consume for purposes we're only beginning to define:

The value of VIBES is not just what you can do with the data today — it's that the data exists at all. Every decision tree captured, every agent action logged, every delegation trace recorded now is an asset for every future use case. The technologies built on top of this data will evolve — the foundation stays.

What is VIBES?

VIBES is an RFC-style specification that defines a three-tier framework for recording AI involvement in software and AI-driven workflows. It specifies what metadata to capture, how to store it using content-addressable hashing, and where audit data lives relative to the project. The standard supports context graphs for tracking causal relationships between events, multi-agent delegation for orchestrating sub-sessions across AI tools, and structured decision records for capturing architectural choices. It is tool-agnostic and designed for adoption by any AI coding tool — Claude Code, Cursor, Windsurf, Copilot, Codex, CLINE, or others.

Design Principles

No Duplication Every unique combination of tool, model, prompt, or reasoning is stored once and referenced by SHA-256 hash.
Progressive Disclosure Low assurance is cheap to implement. Higher tiers add data, not complexity.
Tool-Agnostic The standard prescribes data formats, not tool behavior. Any AI coding tool can implement it.
Git-Aware Audit data correlates with git commits but does not depend on git. Works with any VCS or none.
Queryable The storage format (JSONL) supports structured queries via DuckDB, jq, or any JSON tooling.
Context Graphs Edge records capture causal relationships between events, enabling provenance DAG queries and multi-agent delegation tracking.
Domain Extensible While source code is the first application, the annotation model and attestation pipeline apply to any domain where AI decisions require auditability.

File Structure

All VIBES audit data lives in a .ai-audit/ directory at the project root, tracked alongside your code in version control.

project/ ├── .ai-audit/ │ ├── config.json # Project audit configuration │ ├── manifest.json # Hash → context mappings │ ├── annotations.jsonl # Append-only annotation log │ ├── audit.db # Query database (gitignored) │ ├── .gitignore # Contains: audit.db │ └── blobs/ # Large entries (High assurance) │ └── <hash>.json.gz └── src/ └── ...

Version History

The VIBES standard follows a formal versioning and ratification process. Draft versions are working documents subject to change. A version becomes stable when formally ratified after public review.

Version Date Status Ratified By Notes
0.1-draft 2026-02-03 Superseded Initial internal draft. Core data model, three assurance levels, file layout.
0.2-draft 2026-02-10 Superseded Added context graphs, edge records, multi-agent delegation, decision records.
1.0-draft 2026-02-20 Superseded Feature-complete draft. Tool provider cosigning, attestation pipeline, domain extensibility. Pending community review.
1.1-draft 2026-02-26 Draft Line number rebase resilience with content anchoring, concurrency bottleneck acknowledgment, PRISM (Provenance & Risk Intelligence Scoring Model) optional extension.
0.1-draft 2026-02-26 Draft Initial VERIFY extension draft. Attestation pipeline, DSSE envelopes, trust tiers, tool provider cosigning. See VERIFY.
0.1-draft 2026-02-26 Draft Initial EVOLVE extension draft. Agent learning, governance frameworks, and reinforcement pipelines. See EVOLVE.
0.1-draft 2026-02-26 Draft Initial PRISM extension draft. Provenance & Risk Intelligence Scoring Model for AI-generated code risk assessment. See PRISM.
1.0 TBD Pending TBD Target: first stable release after public review period.

A version is ratified when the authoring committee formally approves it for stable use. The "Ratified By" column records the individuals or organizations that signed off.

The Three Assurance Levels

VIBES defines three levels that progressively capture more about AI involvement. Start where it makes sense for your project and increase detail as your needs grow.

Low Assurance

What tool and model touched this code?

"Which AI model and tool generated this function?"

  • tool_name, tool_version — the AI coding tool used
  • model_name, model_version — the underlying AI model
  • model_parameters (optional) — temperature, max_tokens, etc.
  • tool_extensions (optional) — active plugins/MCP servers
  • Line/function annotations with action type (create, modify, delete, review)
  • Command context — shell commands, file operations, API calls
  • Session tracking and git commit correlation

Who should use this: Open source projects, individual developers, teams wanting basic AI transparency without overhead.

Storage: ~200 bytes per annotation

Example: Environment context record
"e7a3f1b2c4d5...": { "type": "environment", "tool_name": "Claude Code", "tool_version": "1.5.2", "model_name": "claude-opus-4-5", "model_version": "20251101", "model_parameters": { "temperature": 0.7, "max_tokens": 4096 }, "tool_extensions": ["filesystem", "git"], "created_at": "2026-02-03T14:30:00Z" }
Full Low Assurance details →
Medium Assurance

What was the AI asked to do?

"What prompt produced this code?"

  • Everything in Low, plus:
  • prompt_text — the full prompt or instruction given to the AI
  • prompt_type — user_instruction, edit_command, chat_message, inline_completion, review_request, refactor_request, or other
  • prompt_context_files — files provided as context to the AI
  • Annotations include prompt_hash linking code to specific instructions

Who should use this: Enterprise teams, regulated industries (finance, healthcare, government), projects requiring prompt-level traceability.

Storage: ~2–10 KB per annotation

Example: Prompt context record
"a1b2c3d4e5f6...": { "type": "prompt", "prompt_text": "Add input validation to the signup form. Email must be valid, password must be at least 8 characters with one uppercase and one number.", "prompt_type": "user_instruction", "prompt_context_files": [ "src/routes/auth.py", "src/models/user.py" ], "created_at": "2026-02-03T14:30:05Z" }
Full Medium Assurance details →
High Assurance

How did the AI reason about the task?

"What was the model thinking when it wrote this?"

  • Everything in Medium, plus:
  • reasoning_text — full chain-of-thought and reasoning trace
  • reasoning_token_count — number of tokens in reasoning output
  • reasoning_model — model producing reasoning (set to generation model if only one model is used)
  • Size management: inline gzip+base64 for entries >10 KB, external blobs for >100 KB
  • Annotations include reasoning_hash

Who should use this: Safety-critical software (aerospace, medical, automotive), security-sensitive code, AI research, organizations preparing for AI regulation.

Storage: ~10–500 KB per annotation (with size management)

Example: Reasoning context record
"c3d4e5f6a7b8...": { "type": "reasoning", "reasoning_text": "Let me analyze the existing signup form validation patterns...\n\nThe current implementation uses...", "reasoning_token_count": 2847, "reasoning_model": "claude-opus-4-5", "created_at": "2026-02-03T14:30:05Z" }
Full High Assurance details →

Comparison Matrix

Capability Low Medium High
Identify tool and model
Track AI-generated lines/functions
Track commands/tool invocations
Correlate with git commits
Know what the AI was asked
Know context files provided
Know how the AI reasoned
Reproduce the generation Unlikely Possible Likely
Track causal relationships (context graphs)
Multi-agent delegation hierarchy
Structured decision records
Line annotation rebase resilience Best-effort Best-effort Best-effort + anchoring
Storage per annotation ~200 B ~2–10 KB ~10–500 KB
Risk scoring & provenance intelligence PRISM extension
Agent learning & governance EVOLVE extension

Data Format

VIBES stores audit data in three files inside the .ai-audit/ directory. All three are designed to be human-readable, git-friendly, and queryable.

config.json — Project Audit Configuration

Defines the project's assurance level, tracked file extensions, and exclusion patterns. This is the first file a tool creates when initializing VIBES compliance.

Example config.json
{ "standard": "VIBES", "standard_version": "1.0", "assurance_level": "medium", "project_name": "signup-service", "tracked_extensions": [".py", ".js", ".ts"], "exclude_patterns": [ "**/node_modules/**", "**/vendor/**", "**/dist/**" ] }

manifest.json — Context Hash Registry

Maps SHA-256 content hashes to their full context objects (environment, prompt, command, reasoning, decision). Each unique context is stored once and referenced by hash from annotations.

Example manifest.json entry
{ "standard": "VIBES", "version": "1.0", "entries": { "e7a3f1b2c4d5...": { "type": "environment", "tool_name": "Claude Code", "tool_version": "1.5.2", "model_name": "claude-opus-4-5", "model_version": "20251101" }, "a1b2c3d4e5f6...": { "type": "prompt", "prompt_text": "Add input validation...", "prompt_type": "user_instruction" } } }

annotations.jsonl — Audit Trail

Append-only JSONL file containing line annotations, function annotations, session lifecycle events, edge records (causal relationships), and delegation records (multi-agent orchestration). Each record references context hashes from the manifest. Git diffs show exactly what was added.

Example annotation records
// Line annotation — records which lines were AI-generated {"type":"line", "file_path":"src/auth.py", "line_start":1, "line_end":45, "environment_hash":"e7a3f1b2...", "prompt_hash":"a1b2c3d4...", "action":"create", "commit_hash":"abc123", "assurance_level":"medium"} // Function annotation — records AI-generated functions {"type":"function", "file_path":"src/auth.py", "function_name":"validate_signup", "function_signature":"def validate_signup(email, password)", "environment_hash":"e7a3f1b2...", "action":"create", "assurance_level":"medium"} // Session records — track when AI sessions start and end {"type":"session", "event":"start", "session_id":"550e8400-e29b-41d4...", "environment_hash":"e7a3f1b2...", "description":"Adding signup validation"}

Content-Addressable Hashing

VIBES uses SHA-256 to ensure no duplication. Identical contexts always produce the same hash, regardless of when they were created. The hashing algorithm:

  1. Remove the created_at field from the context object
  2. Serialize to JSON with sorted keys and no whitespace
  3. Encode as UTF-8
  4. Compute SHA-256 digest
  5. Express as lowercase hexadecimal (64 characters)
Pseudocode: computing a context hash
# Python example import hashlib, json def compute_context_hash(context: dict) -> str: # Remove non-canonical fields hashable = {k: v for k, v in context.items() if k != "created_at"} # Canonical JSON: sorted keys, no whitespace canonical = json.dumps(hashable, sort_keys=True, separators=(",", ":")) # SHA-256, lowercase hex return hashlib.sha256(canonical.encode("utf-8")).hexdigest()

Specification Downloads

These are the authoritative source documents for the VIBES standard. The HTML pages on this site are derived from these specifications.

How VIBES Compares

VIBES is complementary to existing software supply chain standards, not competing with them. It fills a specific gap: tracking AI provenance at the line and function level.

The key differentiator: VIBES tracks AI provenance at the line and function level. No other standard provides this granularity. The same data model extends to agent workflow auditing beyond source code.

Companion Standards

VIBES is the foundation of a four-part ecosystem. Three companion standards extend it with security, risk analysis, and agent intelligence.

VERIFY — Cryptographic attestation. Ed25519 signatures, DSSE envelopes, tool provider cosigning, and a public attestation registry. Proves your audit data is authentic, untampered, and temporally anchored.

PRISM — Risk scoring. Computes severity bands from VIBES audit data for CI/CD gating, security triage, and compliance dashboards.

EVOLVE — Agent learning & governance. Decision records, feedback loops, and governance frameworks for self-improving agents.

Back to Home