Verifiable Calculation Certificate — specification
VCC is an experimental open specification for verifiable calculation receipts, with CalcFleet as its first reference implementation. This page is the normative layer, kept separate from the product: what each chapter covers, what version 0.2 actually implements, and what is still planned.
Status is stated honestly per chapter. v0.2 has a single reference implementation, no independent verifiers yet, and governance still in progress — so this is a specification under development, not a mature standard.
The words the specification binds: statement, envelope, issuer, keyset, certificate id, the four verification axes (authentic, intact, reproducible, trusted) and the two verification levels (L1 authenticity + integrity, L2 reproducibility). A recurring rule: interfaces MUST NOT collapse authenticity, trust and reproducibility into a single “verified” boolean.
The statement is the semantic layer: subject, issuer, formula (with manifest digest), calculation (typed inputs and outputs), datasets, evidence, engine and issuedAt. It is canonicalized with RFC 8785 (JCS); the certificate id is the SHA-256 of its own canonical bytes, so changing a byte changes the id. The schema is strict — unknown fields are rejected at issuance.
Verification reports separate axes rather than one verdict. Signature, issuer identity, key status, formula resolvability, dataset resolvability and reproduction are implemented today. Runtime attestation, independent auditor review and business-policy evaluation are described as axes but not built — a verification result never claims a business decision was checked.
Every numeric leaf is a typed value ({type, value, scale, unit?}). The vcc-decimal-v1 profile is implemented and tested: integer, decimal, percent, ratio, money (ISO-4217) and duration, with a canonical decimal grammar, no scientific notation, half-even rounding at the declared scale, and NaN/±Infinity forbidden (they abort issuance). Rational, scientific and day-count conventions are not yet profiled.
A formula is identified by a deterministic Formula Package Manifest: entrypoint, input/output schema digests, implementation digest, tests digest, declared dependencies, datasets, sources and numeric dictionary. Continuous integration recomputes every digest on each push, so a manifest cannot silently change. Transitive-dependency lockfile digesting and a reproducible build recipe are still open.
Datasets consumed by a calculation are pinned by name, version and SHA-256 digest inside the statement, and re-checked by digest during reproduction. The dataset-manifest format (including a license field) is defined; formulas that read datasets stay gated off until their manifests ship in statements.
Today there is a single implicit “full” profile with privacy by construction: only numeric, boolean and closed-enum inputs are accepted, PII-shaped values are refused before signing, and a certificate is only ever issued on explicit request. Redacted, hash-only, encrypted-to-recipient and selective-disclosure profiles are described as intent, not built — adding a declared privacyProfile field is a format change reserved for a later version.
Trust separates four axes — cryptographic validity, issuer key status, certificate status and trusted-at-verification-time — and keys are discovered from a published well-known keyset with statuses and validity windows. The current trust policy is single-issuer and fixed; a selectable trust policy and a multi-issuer trust registry are not yet part of the model.
The envelope is DSSE v1 with Ed25519 over the PAE of the canonical statement, verifiable offline. Key rotation and key-compromise procedures are documented; KMS/HSM-backed signing and external timestamping (RFC 3161 / transparency log) are documented extension points, not yet implemented. The full threat model, with residual risks stated openly, lives in the repository docs.
Golden vectors and a tampering matrix pin the behaviour of the reference implementation. What does not yet exist is a packaged conformance suite an independent implementation could run to declare itself conformant: no standalone JSON Schema published for non-TypeScript implementers, no serialized negative-vector corpus, no cross-language tests. This is the main thing between v0.2 and a second implementation.
This is the least mature chapter, and the reason VCC is described as experimental rather than as a standard. There is no published license, security policy, change process, versioning policy, maintainers list or trademark policy yet; the technical decision log (the ADRs) exists but is internal to the repository. Governance is a prerequisite for anyone else to legally implement or reuse the specification.
Current version: v0.2, the format actually implemented in this repository. The payloadType carries the version, so a verifier can reject an unknown version rather than silently degrading. A written versioning and deprecation policy is planned; signatures are immutable and historical, so a deprecated version stays verifiable.
The public, machine-checkable artifacts are served directly: the issuer keyset, and every formula's immutable package manifest. The full normative text, decision records (ADRs) and threat model are versioned in the repository docs and move into a separate, licensed specification space as governance lands — the step that will let anyone else implement and reuse VCC.
This specification defines a receipt for the integrity, provenance and — when reproducible — the technical repeatability of a deterministic calculation. It does not define, and a conforming certificate does not assert, that inputs are true, that a formula fits a specific purpose, or that a result constitutes professional advice or a regulatory certification.
