One format, several reference implementations.

Section 01

Status at a glance

One row per implementation. Status labels below the table are deliberately blunt: shipped is shipped, in flight is in flight, PoC is PoC.

Status legend

• Reference lane: primary JavaScript implementation for builder, reader, verifier, CLI, and browser examples.
• SDK lane: public implementation intended to track v0.6 behavior and conformance vectors.
• Independent verifier lane: verifier-focused implementation used to keep the spec from becoming a single-library contract.

Section 03

JavaScript (Shipped)

The reference SDK. Builder, reader, verifier, the canonical-JSON and Ed25519 primitives, and the deterministic-ZIP container live in a single npm package. The exported surface includes CapsuleBuilder, CapsuleReader, verifyCapsule, plus the lower-level buildChainEvents, hashEvent, verifyChain, buildEnvelope, signEnvelope, verifyEnvelopeSignatures, buildManifest, computeCapsuleId, packZip, unpackZip, and the JCS / SHA-256 helpers (jcs, sha256, sha256Hex). Two dependencies: canonicalize (RFC 8785 JCS) and jszip (deterministic ZIP). Node 20 or newer; runs unmodified in browsers via a bundler.

npm install @capsule/sdk-v0.6-prototype

import { CapsuleReader, verifyCapsule } from "@capsule/sdk-v0.6-prototype";

const bytes = await fetch("/examples/medical-journal/sample.capsule")
  .then((r) => r.arrayBuffer());
const reader = await CapsuleReader.fromBytes(new Uint8Array(bytes));
const result = await verifyCapsule(reader, { allowlist: [] });
console.log(result.ok, result.level, result.envelope.signers);

Source: github.com/virionai/capsules-protocol/tree/main/sdk-js.

Browser-only reference builds without a bundler are demonstrated in examples/medical-journal/: the clinician reader loads the SDK in a single offline HTML file.

Section 05

Rust (verifier-only)

The Rust implementation is verifier-focused: capsule verify file.capsule, exit 0 on pass, exit 1 on fail, with typed errors for server-side and command-line workflows.

Verifier-first is the right first scope because the verifier is the contract any consumer needs; the builder is what producers need.

Section 07

How conformance works

Conformance is test-vector parity. A new implementation is Capsule-compliant when it produces capsules whose content_index_hash matches the JS reference, and whose canonical envelope payload signs and verifies bit-identically against the published test vectors. Every hash that ships in provenance/envelope.json (capsule_id, first_event_hash, entry_hash, manifest_hash, content_index_hash, envelope_signature) is checkable byte-for-byte.

Conformance is not enforced by anything except those test vectors. There is no certification program, no registry of approved implementations, no "Capsule Foundation" issuing logos. The test vectors are the conformance program: if the hashes match, the implementation is compliant; if they don't, it isn't.

The spec lives at /protocol/v0.6/: five files (format, manifest, chain, envelope, trust), roughly 5 KB of text in total. The latest conformance results, including the per-target breakdown, are published at /conformance/latest.md.

Section 09

Roadmap

• v0.6 locks when a second independent implementation round-trips signed test vectors. This is milestone 1 of the project roadmap; until it lands, every version commitment is debt.
• Once locked, the Capsule spec gets a versioned release tag and the JS SDK rebases from 0.6.0-prototype.x to 0.6.0. The "prototype" suffix is the visible signal that the format has not yet been independently validated.
• v0.7 plans: AES-256-GCM cipher support, encrypted-capsule extension (multi-recipient envelope), and RFC 3161 / Rekor temporal anchoring. All three are parking-lot today, blocked on adoption signal, not on engineering.

See the full roadmap for current v1.0 gates.