VRL Proof Bundle Specification v1.0
The complete specification for cryptographically verifiable AI outputs.
Abstract
This document defines the VRL Proof Bundle — a portable, self-contained artifact that cryptographically attests to the identity, inputs, outputs, and execution correctness of any AI system or deterministic computation.
A VRL Proof Bundle carries enough information for any third party to independently verify its authenticity without trusting the issuing party or any centralised service.
The VRL Proof Bundle is designed to become the universal envelope for verifiable AI output — the equivalent of a TLS certificate for computational truth.
Status of This Document
This document is a Draft Specification open for public review and contribution.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
Table of Contents
- Terminology
- AI Identity Standard (AI-ID)
- Proof Bundle Structure
- Proof Systems
- Circuit Registry
- Data Commitments
- Proof Graph
- Legal Layer
- Trust Context
- Canonical Serialisation
- Hash Computation
- Verification Procedure
- Mandatory Output Envelope
- Security Considerations
- Versioning
- Complete Examples
- JSON Schema
1. Terminology
- AI-ID — A cryptographic identifier uniquely bound to a specific AI model at a specific version in a specific execution environment.
- Circuit — A deterministic, verifiable computation encoded as arithmetic constraints, identified by circuit hash and registered in the VRL Circuit Registry.
- Integrity Hash — SHA-256 digest of the concatenation of input_hash + output_hash + trace_hash. Binds all three artifacts into a single verifiable fingerprint.
- Proof Bundle — The complete, portable artifact. Contains AI identity claim, computation record, cryptographic proof, optional legal metadata, data commitments, and graph edges.
- Proof System — The cryptographic mechanism used to generate and verify the proof.
- TEE — Trusted Execution Environment. Hardware-isolated compute enclave that generates a signed attestation report.
- Trace — Ordered sequence of intermediate computation steps between input and output.
- Verifier — Any party that independently checks a proof bundle's validity.
2. AI Identity Standard (AI-ID)
2.1 Purpose
An AI-ID is a stable, verifiable identifier for a specific AI model at a specific version under a specific execution configuration. It allows any party to assert: "This exact model, in this exact state, produced this output."
2.2 AI-ID Computation
An AI-ID is computed as:
AI_ID = SHA-256(canonical_json({
"model_weights_hash": SHA-256(model_weights_bytes),
"runtime_hash": SHA-256(runtime_environment),
"config_hash": SHA-256(canonical_json(config)),
"provider_id": "<provider>",
"model_name": "<name>",
"model_version": "<semver>",
"spec_version": "vrl/ai-id/1.0"
}))
2.3 AI Identity Object
| Field | Type | Required | Description |
|---|---|---|---|
ai_id |
hex string (64 chars) | Yes | SHA-256 digest of canonical AI identity record |
model_name |
string | Yes | Human-readable model name (e.g., "llama-3-70b") |
model_version |
string (semver) | Yes | Semantic version of the model |
provider_id |
string | Yes | Canonical provider identifier (e.g., "io.meta") |
execution_environment |
enum | Yes | one of: tee, gpu, cpu, deterministic, web |
3. Proof Bundle Structure
| Field | Type | Required | Description |
|---|---|---|---|
vrl_version |
string | Yes | Specification version (must be "1.0") |
bundle_id |
UUID v4 | Yes | Unique identifier for this bundle |
ai_identity |
object | Yes | AI Identity object (see §2) |
computation |
object | Yes | Computation record with hashes |
proof |
object | Yes | Cryptographic proof (see §4) |
data_commitments |
array | No | Array of signed dataset commitments |
legal |
object | No | Compliance and jurisdiction metadata |
issued_at |
ISO 8601 | No | Timestamp of bundle creation |
Computation Object
The computation object records what was computed:
| Field | Type | Description |
|---|---|---|
circuit_id |
string | Registered circuit identifier (domain/name@version) |
circuit_hash |
hex string | SHA-256 of circuit constraint system |
input_hash |
hex string | SHA-256 of canonical input |
output_hash |
hex string | SHA-256 of canonical output |
trace_hash |
hex string | SHA-256 of execution trace |
integrity_hash |
hex string | SHA-256(input_hash + output_hash + trace_hash) |
4. Proof Systems
VRL is proof-system agnostic. The following are the standardised proof mechanisms:
| Proof System | Strength | Best For |
|---|---|---|
plonk-halo2-pasta |
Cryptographic | Deterministic computations, compliance |
tee-intel-tdx |
Hardware | LLM inference in Intel TDX enclaves |
tee-amd-sev-snp |
Hardware | AI in AMD SEV-SNP enclaves |
zk-ml |
Cryptographic | Small ML models via EZKL |
sha256-deterministic |
Hash-chain | Rule engines, audit trails |
api-hash-binding |
Hash-binding | API-hosted models |
5. Circuit Registry
The VRL Circuit Registry is an open, append-only catalog of certified computation circuits.
Circuits have three certification tiers:
- EXPERIMENTAL — Submitted, not yet reviewed
- REVIEWED — Reviewed by VRL maintainers
- CERTIFIED — Independently audited and formally verified
See the registry browser for the current circuit catalog.
6. Data Commitments
A data commitment cryptographically binds a proof bundle to a specific version of an external dataset, signed by the dataset's authoritative provider.
| Field | Type | Description |
|---|---|---|
dataset_id |
string | Authoritative dataset identifier |
dataset_version |
string | Version of the dataset used |
dataset_hash |
hex string | SHA-256 of canonical dataset |
provider_id |
string | Authoritative provider identifier |
committed_at |
ISO 8601 | Timestamp of commitment |
7. Proof Graph
Proof bundles can reference each other as dependencies, forming a directed acyclic graph (DAG). This allows composition of verifiable computations.
8. Legal Layer
The legal metadata allows proof bundles to declare their compliance context:
| Field | Type | Description |
|---|---|---|
jurisdictions |
array | ISO 3166-1 alpha-2 country codes |
admissibility_standard |
string | e.g., "VRL_v1", "EVIDENTIARY" |
compliance_flags |
array | e.g., ["EU_AI_ACT", "HIPAA", "SOX"] |
10. Canonical Serialisation
All JSON must be serialised canonically (sorted keys, no whitespace) for hashing:
canonical_json(obj) = JSON with:
• Keys sorted lexicographically
• No whitespace (no spaces after : or ,)
• No trailing newlines
• UTF-8 encoded
11. Hash Computation
All hashes use SHA-256 and are represented as lowercase hexadecimal strings.
hash = lowercase(hex(SHA-256(bytes)))
12. Verification Procedure
The 10-step verification procedure:
- Parse the JSON bundle
- Check vrl_version equals "1.0"
- Validate all required fields are present
- Validate ai_identity structure
- Validate computation data
- Validate proof structure
- Verify integrity_hash = SHA256(input_hash + output_hash + trace_hash)
- Validate bundle_id is valid UUID v4
- Validate timestamps (if present) are valid ISO 8601
- Return VALID or INVALID with detailed error codes
See the web verifier for a live implementation.
14. Security Considerations
- All hashes are non-invertible (SHA-256)
- Proof bundles are immutable once issued
- Verification requires no trust in the issuer
- Private inputs are hashed, never exposed
- Bundle tampering is immediately detectable
15. Versioning
This is VRL Proof Bundle Specification v1.0. Breaking changes require a major version bump. Minor features may be added without breaking backward compatibility.
Learn More
For the complete specification including JSON Schema, examples, and formal definitions, see the GitHub repository.
Language SDKs are maintained separately in vrl-protocol/sdk.