CVP 1.0 Specification

Version: 1.0.0-proposed · Status: Proposed (not Stable) · Last updated: 2026-09-13

This page is the sole normative source for CVP 1.0. The errata ledger is history only — Spec + Errata is not dual-source. Overview: CVP.

Abstract

The Calculator Verification Protocol (CVP) is a versioned, reproducible, evidence-based framework for verifying the correctness, consistency, provenance, numerical behavior, semantic contracts, interface consistency, and production integrity of computational tools published by CalculatorX.

CVP Verified means that a calculator has satisfied the required verification controls defined by the applicable CVP version and assurance profile, with inspectable evidence. It does not imply third-party certification unless explicitly stated. It does not mean every possible input has been enumerated.

Trust through reproducible evidence.

1. Purpose & Principles

CVP answers three questions consistently for humans, auditors, and AI agents:

1. What does “Verified” mean?
2. What objective conditions must a calculator meet?
3. Can an external party re-check the evidence against public rules?

Principles

2. Scope

2.1 What CVP does claim

For a declared model and assumptions, CVP supports claims that:

• The formula/model is documented with provenance (direct or derived)
• At least one independent reference mechanism validates the model / expected outputs
• The implementation computes that model within pre-declared numerical policy
• Units / dimensions (when applicable) are consistent
• Declared input/mode coverage is exercised
• Boundary and invalid inputs are handled as contracted
• Semantic contracts hold
• Exposed execution interfaces agree (when multiple exist)
• Production artifacts match the verified evidence set when attestation is current

2.2 What CVP does not claim

CVP does not automatically prove that a chosen engineering model is appropriate for every real-world use case.

Example: CVP can verify that (P_{sw}=\tfrac{1}{2}V I (t_r+t_f)f) is implemented correctly. CVP alone does not certify fitness for every MOSFET, waveform, driver, or topology.

Domain suitability MAY be strengthened by optional Domain Expert Review (CVP-EXP-01) or authoritative worked examples (O1 under CVP-REF-01).

2.3 Trust architecture

CVP Specification
        ↓
Verification Runner
        ↓
Evidence Manifest ──→ Attestation ──→ Production binding
        ↓
   ┌────┴────┐
Trust Summary   Evidence JSON / API / MCP
 (human UI)          (machines)

Trust Summary is the human-readable result of CVP verification. It is not a separate trust system.

3. Normative language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals, as shown here.

4. Verification object

A CVP run verifies a computational contract, not a single numeric output in isolation:

5. Assurance profiles

A calculator MUST declare exactly one primary profile per CVP run.

Status display SHOULD include profile and protocol version, e.g. CVP VERIFIED · engineering · CVP 1.0.0-proposed.

5.1 Profile matrix

Legend: R = Required · A = Applicable (Required when condition holds) · O = Optional · H = Higher assurance (Required for numerical; Recommended for engineering; Optional for core)

¹ R+ for engineering: scope MUST include engineering applicability notes (AC/DC, RMS/peak, ideal vs real, etc. as relevant).
² For purely unitless core calculators, CVP-UNIT-01 is satisfied by an explicit “unitless” declaration.

6. Controls

6.1 Required controls

6.1.1 Provenance modes (CVP-PROV-01)

Direct provenance: published source → model (standard, textbook, datasheet, application note, peer-reviewed reference), with locateable citation.

Derived provenance: Source A + Source B + documented derivation → CalculatorX model. Derived models MUST record:

• upstream dependency IDs/versions
• derivation description (human-readable)
• machine-readable derivation metadata when available

Absence of an external single-source citation is allowed only when derived provenance is complete.

6.1.2 Independent reference (CVP-REF-01) — normative

CVP-REF-01 is Required for all profiles.

At least one of the following oracle classes MUST be used such that expected values / reference checks are not generated solely by the implementation under test (IUT):

Each reference item MUST declare a reference_scope (incorporated from Erratum E1; ledger only):

Coverage rule: CVP-REF-01 PASS requires that every claim relied upon by the verification run is backed by reference evidence whose reference_scope covers that claim. In particular:

• If golden (or equivalent) numeric expected values are used, at least one reference entry MUST have reference_scope of expected_values or all. An O1/O4 entry with scope model alone does not justify an arbitrary suite of IUT-authored expected values.
• If the run asserts numerical behavior of a finite-precision IUT, at least one entry MUST have reference_scope of numerical_behavior or all (typically O2/O3). Symbolic O4 with scope model alone does not satisfy this.

Typical engineering pattern (RECOMMENDED): O1 with scope model plus O2 or O3 with scope expected_values (and numerical_behavior when claiming FP properties).

Common-mode failure rule: Using the IUT (or a transcription of its outputs) as the sole generator of golden expected values MUST cause CVP-REF-01 to FAIL, even if all numeric comparisons match.

CVP-ORACLE-01 (profile matrix H/R) strengthens depth (e.g. requiring O3 for numerical, or multiple classes) but does not replace CVP-REF-01.

6.2 Applicable controls

A transformation property (for example 2P → ½t, capacity homogeneity, or unit-equivalent invariance) is a known input→output relation. Recording it only under CVP-PROP-01 and marking CVP-META-01 N/A is a process error.

Metamorphic-class property ids. Scale homogeneity, order permutation invariance, and canonical-form equivalence are metamorphic. A dedicated tests.metamorphic suite is RECOMMENDED. Until a protocol-wide taxonomy migration, case ids matching property-scale-*, property-permute-*, property-canonical-*, property-*-equiv-*, and meta-* MAY remain under CVP-PROP-01 and MUST be treated as metamorphic-class evidence. CVP-META-01 N/A remains a process error when transformation relations exist that are not so classified (for example a property-load vector whose detail is 2P → ½t).

CVP-XCAL-01

When the applicability predicate is true, the control MUST appear in the obligation set as PASS, FAIL, or — for a listed related tool that does not share the identity or assumptions — N/A with a recorded reason. Omitting the control is a process error.

formula_family string equality is sufficient but not required when the calculator page publishes related tools that encode the same identities (for example Γ↔z, |Γ|↔VSWR/RL). A related-tool listing does not make every identity applicable: record N/A when the peer’s model is a strict subset (for example real-RL L-section vs complex-z auto-match). Family-parity properties against a related calculator (property-parity-* or equivalent) are XCAL evidence; they do not justify not_applicable.

CVP-IFACE-01

Equivalent semantic inputs across interfaces MUST produce equivalent computational outputs within the declared representation policy. Evidence SHOULD record interface IDs compared.

ui-ssr means crawlable query-result HTML, not a live browser session. It MUST NOT be described as proving hydration, slider writes, refresh, Back/Forward, cache switching, or end-to-end UI interaction. MCP evidence that reuses the calc API handler MUST be disclosed as such — it is not a second independent runtime.

When a calculator publishes a shareable URL and an engine-linked result graph, evidence SHOULD record a separate integration check: URL → result → graph current point. URL-canonical hydration / slider / history contracts MAY be recorded in the same integration block. A pointer-driven browser session remains out of scope for ui-ssr.

6.3 Higher-assurance & optional

UI MAY show: CVP VERIFIED + Supplemental Domain Reviewed when CVP-EXP-01 = PASS. If independence=internal / external_third_party=false, UI MUST NOT label the review Independent in a way that implies a third party.

CalculatorX internal engineering review (Review-policy L2) MUST be recorded as internal_review, not as domain_review. domain_review is reserved for CVP-EXP-01. When domain_review.status=ABSENT, the object MUST NOT carry reviewer_role from an internal review. UI MUST label the two records separately (for example Internal engineering review vs CVP supplemental expert review).

7. Numerical policy (CVP-NUM-01)

7.1 Anti-tuning rule (normative)

Numerical tolerances MUST be justified independently of the observed production error and MUST be defined before evaluating the implementation under test.

Defining or widening tolerance after inspecting IUT error for the purpose of obtaining PASS MUST cause CVP-NUM-01 to FAIL (process violation), even if comparisons would numerically succeed under the widened tolerance.

7.2 Required declarations

Evidence MUST record:

• numeric representation of the IUT (e.g. IEEE-754 binary64 or exact_integer)
• tolerance type (absolute | relative | ulp | exact | profile-defined composite)
• tolerance value(s)
• rationale referencing policy (not observed error)
• claim scope when the tolerance is vs a tabulated oracle (which vectors / which input region). A tabulated O3 PASS MUST NOT be described as a guarantee over the entire input domain.

For floating profiles (binary64 / ULP):

• max error observed (for audit; MUST NOT be used to set the threshold after the fact)

For the exact_integer profile (normative when the IUT is exact integer arithmetic):

• representation: exact_integer
• arithmetic: e.g. BigInt
• comparison: exact_equality
• tolerance: 0 with type: exact
• ulp_applicable: false
• record exact_mismatches, not error_ulp / threshold_ulp / max_error_observed / precision_bits
• Node/V8 (or another host) MAY appear as a runtime dependency; it MUST NOT be recorded as the numeric model when the arithmetic is exact integer

7.3 Profile guidance (normative minimums unless model policy supersedes with documented rationale)

CVP SHOULD NOT treat large test counts as a substitute for a sound numerical policy.

8. Test classes & coverage

8.1 Coverage matrix (CVP-COV-01)

Each suite MUST declare partitions (modes, ranges, regimes) and map cases to partitions. Evidence MUST summarize coverage (which partitions exercised / unexercised).

Large passed/total counts without partition coverage MUST NOT be presented as sufficient quality evidence. CVP intentionally discourages “test count contests.” Stochastic calculators MUST additionally satisfy §8.3 (semantic partitions; a generic monte-carlo / happy partition is not enough).

8.2 Reproducibility metadata (normative for generated tests)

For any generated class (property / metamorphic / fuzz-like), Evidence MUST include enough metadata to re-run:

• runner name + version
• environment (runtime, runtime version, OS if relevant, numeric model)
• random seed(s)
• generator id/version
• domain distribution / exclusions
• property or generator definition IDs
• suite URI or immutable suite identifier
• stable test case IDs for fixed vectors

Without this metadata, claims of full reproducibility are NOT satisfied; the run may still be auditable but MUST NOT advertise bit-for-bit reproducibility.

When a calculator publishes an O3 table, Evidence SHOULD also provide a public reproduce entry (page or JSON) listing:

• fixed input vectors and expected values
• oracle identity (library, precision, generator, seed, table hash)
• execution commands
• the last result summary

Workspace-only paths such as scripts/lib/cvp/oracles/… are not sufficient as the sole reproduce pointer. Public templates: math math.cos; engineering electrical.rf.antenna_length. See Reproducing O3 reference tables.

8.3 Stochastic calculators (normative)

This section applies when the implementation under test is a random / sampling calculator: Monte Carlo, seeded PRNG replay, or any capability whose published result depends on a random number generator. Deterministic closed-form calculators that merely include a few seeded oracle-table vectors (for example tabulated math.sin angles) are not stochastic calculators.

Gold-standard implementation: engineering.tolerance.monte_carlo (Monte Carlo Tolerance Analysis).

A stochastic calculator MUST:

1. Declare the calculation lock: PRNG algorithm, seed, and sampler (for example mulberry32 + Box–Muller). These MUST appear on the independent reference and on published outputs — not only in FAQ copy.
2. Provide a seeded stochastic O2 that deterministically replays published sampling statistics (mean, standard deviation, percentiles, and yield when published). An O2 that independently checks only an analytic σ / moment identity is not sufficient.
3. Layer analytic identity and sampling agreement. A closed-form identity (for example correlated (\sigma=\sqrt{\sigma_1^2+\sigma_2^2+2\rho\sigma_1\sigma_2})) MUST NOT share a PASS with Monte Carlo statistical proximity. Record them as separate cases (for example property-corr-analytic vs property-corr-mc-near-analytic).
4. Use semantic coverage partitions. A single generic success partition such as monte-carlo, happy, nominal, default, core, or main MUST NOT satisfy CVP-COV-01 for a stochastic calculator. Partitions MUST name regimes (independent / correlated / non-normal / NORTA / yield / reproducibility / invalid-domain, as applicable).
5. Publish sampling uncertainty for proportions. If yield, reject rate, or PPM is a published result, Evidence MUST record an explicit sampling interval (ci_method such as Wilson, with ci_low / ci_high). A point estimate alone is not sufficient.
6. Name unverified sampling paths in verified_scope. Paths that remain engine regression (for example NORTA sampling, Sobol, Shapley) MUST be listed as out of the O2 compare. Silence is not an exemption.

Engineering O2 on the same runtime as the IUT (same V8 binary64, reimplemented PRNG/sampler in a separate module) is a valid O2. A different language / high-precision path is Higher Assurance (CVP-ORACLE-01 / O3) and is not required to freeze an engineering stochastic calculator.

Verification-core hashing for stochastic calculators follows §11.1: cvp_core_sha256 MUST NOT include volatile production status, attestation clocks, or Evidence contract-count side channels.

9. Status model

Trust Summary and Evidence JSON MUST use these spellings.

9.1 VERIFIED

All Required controls for the profile pass, and all Applicable controls whose condition is true pass. Attestation is CURRENT.

Display: CVP VERIFIED · optional profile · CVP version
Does not mean: third-party certification; exhaustive enumeration of all inputs; unbounded real-world fitness.

9.2 PARTIAL

Verification started; ≥1 Required/applicable control is PENDING or incomplete; none of those have FAIL.

MUST NOT be marketed as fully verified.

9.3 STALE

A prior successful verification/attestation existed, but one or more of the following changed without successful re-run:

• calculation logic / model / provenance derivation
• semantic contract
• verification suite or evidence set
• result-affecting dependencies
• production artifact bytes / hash
• interface surface that affects CVP-IFACE-01 applicability

Recovery: re-execute CVP; on full pass, attestation → CURRENT.

9.4 FAILED

≥1 Required or applicable Applicable control has FAIL.

9.5 NOT_VERIFIED

No complete CVP execution recorded for the current calculator version / profile.

9.6 Attestation sub-states

A calculator MUST NOT be labeled CVP VERIFIED unless attestation is CURRENT.

Authoritative production binding: calculator-level attestation on an Evidence Manifest is a projection of the site-wide production attestation report at /.well-known/calculatorx-production-attestation.json (catalog / evidence / public HTML freshness for that capability). That report is the authoritative source for CVP-PROD-01. A Manifest MUST NOT show CURRENT when the site-wide report is fail, or when this capability's live current_cvp_status / Evidence freshness is STALE. Site-wide status=stale caused by other capabilities does not by itself require this Manifest to be STALE. Auditors MUST gate on Manifest attestation and current_cvp_status.{capability_id}, and SHOULD read stale_reason / stale_capability_count / verified_current_capability_count / cvp rather than treating the first top-level stale token as a calculator veto. When a calculator is CURRENT and the live site-wide report is stale, Trust copy and CVP-PROD-01 notes MUST name both clocks (bound snapshot vs live site-wide report) and MUST NOT claim site report pass.

CVP-PROD-01 MUST distinguish local calculator checks from the site-wide report:

• Site-wide report status=fail, or this calculator's production checks fail → CVP-PROD-01 FAIL. Derived document status is FAILED (§10). Notes MUST name both the site report status and the local check status. Do not record an unconditional PASS whose notes quote a production FAIL.
• Digest / artifact drift after a prior PASS snapshot, while local checks still pass and the site report is not fail → attestation STALE with CVP-PROD-01 PASS (freshness gate; re-attestation required before CURRENT).
• Recovery: repair the failing production surfaces (for example Evidence HTML Coverage / evidence digest projection), re-run production attestation, and only restore VERIFIED after this capability's current_cvp_status is VERIFIED + CURRENT and the site-wide report is not fail.

9.7 Precedence

FAILED > STALE > PARTIAL > NOT_VERIFIED
(VERIFIED only when none of the above apply and all pass conditions hold.)

10. Control evaluation algorithm (normative)

Inputs: profile (P), control results map, applicability predicates, attestation status.

1. Build obligation set (O)

   • Include every control marked R for (P) in §5.1.
   • Include every A control whose applicability predicate is true.
   • Include H controls that are Required for (P) (e.g. CVP-ORACLE-01 for numerical).
   • Do not include O controls in (O) (they do not block VERIFIED).

2. Normalize results for each control in (O): PASS | FAIL | SKIP | PENDING

   • SKIP on a control in (O) is treated as process error → map to FAIL unless the control’s applicability was re-evaluated as false (then remove from (O) and record applicability: not_applicable).
   • Optional controls outside (O) may be SKIP without affecting status.

3. Classify

   • If any control in (O) is FAIL → status = FAILED
   • Else if attestation is STALE (and a prior verified attestation existed) → STALE
   • Else if any control in (O) is PENDING → PARTIAL
   • Else if (O) is empty of completed run → NOT_VERIFIED
   • Else if all in (O) are PASS and attestation is CURRENT → VERIFIED
   • Else if all in (O) are PASS and attestation is ABSENT → PARTIAL (verification complete; production not bound)

4. Emit Evidence Manifest including obligation set, per-control results, and derived status.

11. Artifacts, hashing & attestation

11.1 Hash coverage (normative)

To avoid self-referential hashing:

Published Manifests SHOULD include artifacts.digest_registry enumerating these names, scopes, and field paths so Agents do not treat every “evidence digest” as interchangeable.

Verification Core vs Trust Overlay (normative): artifacts.evidence_digest / artifacts.cvp_core_sha256 MUST hash only the Verification Core. The following MUST NOT enter the core digest:

• status, verification_status, production_freshness, overall_trust
• attestation.* (ids, CURRENT/STALE, attested clocks, production_checks)
• timestamps.rendered_at and other serialization clocks that are not part of suite identity
• calculator.verification_revision / pin filenames (overlay labels)
• Evidence-published tests.contract counts (release-integrity side channel)

Production Attestation MUST bind cvp_core_sha256 (digest prefix). CURRENT MUST NOT require verification_revision string equality. Re-attestation that only updates the Trust Overlay MUST NOT change cvp_core_sha256. Immutable revision pins (…/{version}/{verification_revision}.cvp.json) are write-once for a given core digest; implementations SHOULD also publish a content-addressed pin (…/{version}/{verification_revision}.{cvp_core_sha256[0:12]}.cvp.json). Core changes require a new verification_revision. latest.cvp.json MAY move and MAY carry overlay fields that the pin does not.

Causal clocks MUST satisfy verified_at ≤ evidence_attested_at ≤ last_confirmed_current_at. A Manifest that violates this order MUST NOT be published.

CVP-PROD-01 SHOULD expose check_result (alias of result), production_state, and binding_current so Agents do not treat a PASS control as “production is CURRENT”.

Canonicalization algorithm (JSON): UTF-8, sorted object keys, no insignificant whitespace, as specified by the companion schema release notes (digest_algorithm = sha256, canonicalization = json-sorted-keys-utf8).

Integrity (hash match) answers “has this changed?”
It does not alone answer “who produced this evidence?”

11.2 Signed attestation (CVP 1.0)

Cryptographically signed attestations are RECOMMENDED in CVP 1.0 and MAY become REQUIRED in a future assurance profile or CVP major version.

When present (signed mode), attestation SHOULD include all of:

• statement_sha256 (hash of attestation statement payload)
• signature
• key_id

When absent (unsigned integrity mode), attestation MUST NOT include key_id, signature, or statement_sha256 alone or in partial combination that implies a signature. Unsigned examples MUST only include integrity fields such as status and attested_at. (Incorporated from Erratum E2; ledger only.)

Conceptual chain:

Evidence bundle → evidence_bundle_sha256
        ↓
Attestation statement (binds calculator version, suite, hashes, status)
        ↓ signature
Verification key (key_id)

Until signing is deployed, implementations MUST describe production binding as integrity attestation, not as proof of authenticity against a public key.

11.3 Production Evidence immutability (normative)

Published Evidence JSON is the subject of production attestation (evidence_core_sha256). Once a digest is bound, that subject MUST be immutable in the production pipeline.

evidence_core_sha256 MUST be SHA-256 of a canonicalized Evidence core, not of the entire JSON document. Volatile metadata MUST NOT enter the core. Implementations MUST exclude at least:

• generated_at, rendered_at, evidence_core_generated_at
• engine_build
• release_integrity (self-digest wrapper)
• verification (advertised counts derived from the core)

A no-op regenerate that only changes those fields MUST yield the same evidence_core_sha256.

Host-numeric diagnostics (Monte Carlo histogram / convergence, Box-Muller sample statistics at ULP scale, calculation_fingerprint of those outputs) MAY differ across Node/V8 versions. Production generate MUST NOT replace committed Evidence solely because those diagnostics moved. The attested digest remains the exact evidence_core_sha256 of the committed bytes; repair of a real digest mismatch is re-attestation, not a Pages rewrite.

Production / CI / Pages MAY:

• calculate a candidate Evidence document
• validate it
• compare candidate core to the committed core
• fail the build when they differ

Production / CI / Pages MUST NOT:

• rewrite committed Evidence cores
• silently update an attested Evidence digest
• treat “copy live hash into the overlay” as attestation
• rebind VERIFIED / CURRENT without a successful attest:production (and, when Manifest identity changed, cvp:run)

Freshness gate: if a calculator’s overlay claims VERIFIED + CURRENT but live Evidence evidence_core_sha256 ≠ the attested digest, Trust MUST project STALE (attested_evidence_digest_mismatch) and MUST NOT advertise Production CURRENT. This gate MUST NOT be weakened to hide generator churn.

Derived Production CURRENT. Overlay status is not an independent boolean. Production CURRENT for a calculator holds only when all of the following are true:

• Manifest status is VERIFIED
• overlay status is VERIFIED and overlay attestation is CURRENT
• attested verification_revision equals the published Manifest revision
• attested evidence_core_sha256 equals live Evidence core
• calculation_version matches across Manifest, catalog, and Evidence
• the site-wide production report is not fail for this capability’s probes

A VERIFIED overlay that still names digest A while live Evidence is B is an atomicity violation. Repair is re-attest (bind B after verification), not rewriting the overlay to B.

Lifecycle:

local generate Evidence → commit core → deploy
        ↓
   candidate core == committed core → ship (frozen)
   candidate core != committed core → FAIL BUILD
        ↓
   digest mismatch → STALE until attest:production [--write]
        ↓
   subsequent Pages builds MUST reuse committed Evidence
        ↓
   remains CURRENT while the core is unchanged

12. Evidence Manifest requirements

Every Evidence Manifest MUST include:

• protocol.name = "CVP"; protocol.version
• While protocol.version is Proposed (*-proposed), Manifests MUST also pin protocol.revision (ISO date of the spec text used for that run) and SHOULD pin protocol.spec_sha256 of the published spec document (/developers/cvp/spec/1.0). protocol.version alone is not a content-addressed pin: Proposed text MAY change without bumping the version string.
• document_status (proposed | stable | …)
• calculator.id / calculator.version
• profile
• status (§9)
• runner (name, version)
• environment (runtime, runtime_version, numeric_model, …)
• suite (id, version, uri)
• per-control results for all evaluated controls
• obligation_set (control IDs that determined status)
• test class counts + reproducibility metadata (§8.2)
• coverage summary for CVP-COV-01
• oracle / reference descriptors for CVP-REF-01
• numerical policy block (§7)
• artifact hashes (§11)
• dependency versions
• attestation object
• timestamps (UTC)

13. Trust Summary mapping

UI SHOULD link:

• View CVP → landing /developers/cvp or spec /developers/cvp/spec/1.0
• View evidence → this calculator’s evidence
• Reproduce → public vector list, expected values, and re-run commands when O3 is claimed

Production attestation MUST NOT treat a VERIFIED badge as sufficient Trust projection. Checks named *-html-cvp-projection MUST compare advertised Trust fields to the Manifest: status, protocol version, assurance profile, verification_revision, verified_scope, deferred_scope, coverage N/N, golden / boundary / invalid / property / cross-interface / contract suite counts, and cvp_core_sha256 (evidence_digest). A match elsewhere on the page MUST NOT satisfy those fields. Calculator HTML, Capability, Evidence, and the Manifest MUST agree on the advertised fields. Shareable calculator query URLs SHOULD be probed when they are a primary UX, so a stale query-variant shell cannot hide behind a fresh canonical page.

14. Versioning & compatibility

These three MUST remain distinguishable in Trust Summary and Evidence. Adding a verification layer MUST NOT by itself bump the calculation version.

• Patch updates that do not add Required controls MAY keep existing VERIFIED labels.
• Adding/tightening a Required control MUST state whether existing attestations become STALE.
• Result-affecting calculator/suite changes MUST invalidate production attestation until re-verification.

15. Governance

Goal: evolve from internal QA rules toward a public verification methodology that others can cite and critique.

16. Conformance & badge copy

A calculator conforms to Proposed CVP 1.0 for profile (P) when Evidence follows this specification, evaluation (§10) yields VERIFIED, attestation is CURRENT, and evidence is retrievable.

When Stable, allowed badge copy includes:

• Verified under CVP
• Verified under Calculator Verification Protocol (CVP) 1.0

While document_status is proposed, UI MUST display Proposed status and the assurance profile in the verification badge itself (not only in a linked footnote). Allowed forms:

• Verified under Proposed CVP 1.0.0 · {profile}
• CVP VERIFIED · Proposed 1.0.0 · {profile} (example: CVP VERIFIED · Proposed 1.0.0 · engineering)
• CVP VERIFIED · Proposed 1.0.0 · Assurance: {Profile} (example: CVP VERIFIED · Proposed 1.0.0 · Assurance: Engineering)
• CVP VERIFIED · Proposed 1.0.0 · {Profile} assurance (example: CVP VERIFIED · Proposed 1.0.0 · Engineering assurance)
• CVP VERIFIED · CVP protocol 1.0.0-proposed · {Profile} assurance (example: CVP VERIFIED · CVP protocol 1.0.0-proposed · Engineering assurance) — preferred in CalculatorX UI so protocol version is not confused with calculation version, and the CVP assurance profile is not read as a calculator input mode

When a Manifest declares verified_scope, UI SHOULD append that scope to the badge (example: CVP VERIFIED · CVP protocol 1.0.0-proposed · Engineering assurance · Basic RSS/WCA scope). Trust UI SHOULD present verified_scope and deferred_scope as first-class claim fields, not as Known limitations.

Bare CVP VERIFIED / Verified under CVP 1.0 without Proposed marking MUST NOT be used until this specification is marked Stable. Omitting the profile (for example a bare CVP VERIFIED · CVP protocol 1.0.0-proposed) is also forbidden while Proposed. A bare Proposed 1.0.0 token next to Calculation {version} SHOULD NOT be used — prefer CVP protocol 1.0.0-proposed. (Incorporated from Erratum E3; ledger only.)

Disallowed for first-party self-execution without independent auditor:

• Certified · CalculatorX Certified · wording implying external accreditation

Don’t trust the badge. Verify the evidence.

Product gating (non-normative): No CVP evidence → no CVP VERIFIED → may ship, but must not claim trusted status.

17. Publication URLs

Appendix A — Evidence JSON schema skeleton

Schema skeleton and example Evidence Manifest. Normative requirements are in the sections above; expand only when you need the field shape.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://calculatorx.com/developers/cvp/schema/cvp-evidence-1.0.json",
  "title": "CVP Evidence Manifest",
  "type": "object",
  "required": [
    "protocol",
    "document_status",
    "calculator",
    "profile",
    "status",
    "runner",
    "environment",
    "suite",
    "obligation_set",
    "controls",
    "tests",
    "coverage",
    "reference",
    "numerical",
    "artifacts",
    "attestation",
    "timestamps"
  ],
  "properties": {
    "protocol": {
      "type": "object",
      "required": ["name", "version"],
      "properties": {
        "name": { "const": "CVP" },
        "version": { "type": "string" }
      }
    },
    "document_status": {
      "type": "string",
      "enum": ["proposed", "stable", "deprecated"]
    },
    "calculator": {
      "type": "object",
      "required": ["id", "version"],
      "properties": {
        "id": { "type": "string" },
        "version": { "type": "string" },
        "title": { "type": "string" },
        "formula_family": { "type": "string" }
      }
    },
    "profile": {
      "type": "string",
      "enum": ["core", "engineering", "numerical"]
    },
    "status": {
      "type": "string",
      "enum": ["VERIFIED", "PARTIAL", "STALE", "FAILED", "NOT_VERIFIED"]
    },
    "runner": {
      "type": "object",
      "required": ["name", "version"],
      "properties": {
        "name": { "type": "string" },
        "version": { "type": "string" }
      }
    },
    "environment": {
      "type": "object",
      "required": ["runtime", "runtime_version", "numeric_model"],
      "properties": {
        "runtime": { "type": "string" },
        "runtime_version": { "type": "string" },
        "numeric_model": { "type": "string" },
        "os": { "type": "string" }
      }
    },
    "suite": {
      "type": "object",
      "required": ["id", "version"],
      "properties": {
        "id": { "type": "string" },
        "version": { "type": "string" },
        "uri": { "type": "string", "format": "uri" }
      }
    },
    "obligation_set": {
      "type": "array",
      "items": { "type": "string" }
    },
    "provenance": {
      "type": "object",
      "properties": {
        "mode": {
          "type": "string",
          "enum": ["direct", "derived", "mixed"]
        },
        "sources": {
          "type": "array",
          "items": {
            "type": "object",
            "required": ["label"],
            "properties": {
              "label": { "type": "string" },
              "kind": {
                "type": "string",
                "enum": [
                  "standard",
                  "textbook",
                  "datasheet",
                  "application_note",
                  "peer_reviewed",
                  "derived",
                  "other"
                ]
              },
              "reference": { "type": "string" },
              "url": { "type": "string", "format": "uri" }
            }
          }
        },
        "derivation": {
          "type": "object",
          "properties": {
            "description": { "type": "string" },
            "upstream": {
              "type": "array",
              "items": {
                "type": "object",
                "required": ["id", "version"],
                "properties": {
                  "id": { "type": "string" },
                  "version": { "type": "string" }
                }
              }
            }
          }
        }
      }
    },
    "reference": {
      "type": "object",
      "required": ["items"],
      "properties": {
        "items": {
          "type": "array",
          "minItems": 1,
          "items": {
            "type": "object",
            "required": ["class", "scope"],
            "properties": {
              "class": {
                "type": "string",
                "enum": ["O1", "O2", "O3", "O4"]
              },
              "scope": {
                "type": "string",
                "enum": ["model", "expected_values", "numerical_behavior", "all"]
              },
              "label": { "type": "string" },
              "engine": {
                "type": "object",
                "properties": {
                  "name": { "type": "string" },
                  "precision_bits": { "type": "integer", "minimum": 1 },
                  "independent_of_iut": { "type": "boolean" }
                }
              }
            }
          }
        },
        "notes": { "type": "string" }
      }
    },
    "controls": {
      "type": "object",
      "additionalProperties": {
        "type": "object",
        "required": ["result"],
        "properties": {
          "result": {
            "type": "string",
            "enum": ["PASS", "FAIL", "SKIP", "PENDING"]
          },
          "applicability": {
            "type": "string",
            "enum": [
              "required",
              "applicable",
              "not_applicable",
              "optional",
              "higher_assurance"
            ]
          },
          "notes": { "type": "string" }
        }
      }
    },
    "tests": {
      "type": "object",
      "additionalProperties": {
        "type": "object",
        "required": ["passed", "total"],
        "properties": {
          "passed": { "type": "integer", "minimum": 0 },
          "total": { "type": "integer", "minimum": 0 },
          "failed": { "type": "integer", "minimum": 0 },
          "seed": { "type": "string" },
          "generator_id": { "type": "string" },
          "generator_version": { "type": "string" },
          "definition_ids": {
            "type": "array",
            "items": { "type": "string" }
          },
          "case_ids": {
            "type": "array",
            "items": { "type": "string" }
          }
        }
      }
    },
    "coverage": {
      "type": "object",
      "required": ["partitions"],
      "properties": {
        "partitions": {
          "type": "array",
          "items": {
            "type": "object",
            "required": ["id", "exercised"],
            "properties": {
              "id": { "type": "string" },
              "description": { "type": "string" },
              "exercised": { "type": "boolean" },
              "case_count": { "type": "integer", "minimum": 0 }
            }
          }
        }
      }
    },
    "numerical": {
      "type": "object",
      "required": ["representation", "tolerance"],
      "properties": {
        "representation": { "type": "string" },
        "tolerance": {
          "type": "object",
          "required": ["type", "value", "rationale", "declared_before_evaluation"],
          "properties": {
            "type": {
              "type": "string",
              "enum": ["absolute", "relative", "ulp", "composite", "exact"]
            },
            "value": { "type": "number" },
            "rationale": { "type": "string" },
            "declared_before_evaluation": { "type": "boolean", "const": true }
          }
        },
        "max_error_observed": { "type": "number" }
      }
    },
    "interfaces": {
      "type": "object",
      "properties": {
        "compared": {
          "type": "array",
          "items": { "type": "string" }
        },
        "result": {
          "type": "string",
          "enum": ["PASS", "FAIL", "SKIP", "PENDING"]
        }
      }
    },
    "artifacts": {
      "type": "object",
      "required": ["evidence_bundle_sha256"],
      "properties": {
        "evidence_bundle_sha256": {
          "type": "string",
          "pattern": "^[a-f0-9]{64}$"
        },
        "production_sha256": {
          "type": "string",
          "pattern": "^[a-f0-9]{64}$"
        },
        "attested_catalog_sha256": {
          "type": "string",
          "pattern": "^[a-f0-9]{64}$"
        },
        "manifest_sha256": {
          "type": "string",
          "pattern": "^[a-f0-9]{64}$"
        },
        "source_commit": { "type": "string" }
      }
    },
    "dependencies": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["name", "version"],
        "properties": {
          "name": { "type": "string" },
          "version": { "type": "string" }
        }
      }
    },
    "attestation": {
      "type": "object",
      "required": ["status"],
      "properties": {
        "status": {
          "type": "string",
          "enum": ["CURRENT", "STALE", "ABSENT"]
        },
        "attested_at": { "type": "string", "format": "date-time" },
        "stale_reason": { "type": "string" },
        "statement_sha256": {
          "type": "string",
          "pattern": "^[a-f0-9]{64}$"
        },
        "signature": { "type": "string" },
        "key_id": { "type": "string" }
      },
      "if": {
        "anyOf": [
          { "required": ["statement_sha256"] },
          { "required": ["signature"] },
          { "required": ["key_id"] }
        ]
      },
      "then": {
        "required": ["statement_sha256", "signature", "key_id"]
      }
    },
    "domain_review": {
      "type": "object",
      "description": "CVP-EXP-01 supplemental expert review. Distinct from internal_review.",
      "properties": {
        "status": {
          "type": "string",
          "enum": ["PASS", "FAIL", "ABSENT"]
        },
        "scope": { "type": "string" },
        "reviewer_role": { "type": "string" },
        "spec_version": { "type": "string" }
      }
    },
    "internal_review": {
      "type": "object",
      "description": "CalculatorX internal engineering review (Review-policy L2).",
      "properties": {
        "status": {
          "type": "string",
          "enum": ["PASS", "FAIL", "ABSENT"]
        },
        "reviewer_role": { "type": "string" },
        "reviewed_by": { "type": "string" },
        "spec_version": { "type": "string" }
      }
    },
    "timestamps": {
      "type": "object",
      "required": ["verified_at"],
      "properties": {
        "verified_at": { "type": "string", "format": "date-time" },
        "generated_at": { "type": "string", "format": "date-time" }
      }
    }
  }
}

{
  "protocol": { "name": "CVP", "version": "1.0.0-proposed", "revision": "2026-09-13" },
  "document_status": "proposed",
  "calculator": {
    "id": "amps-to-volts",
    "version": "1.0.3",
    "formula_family": "ohms-law"
  },
  "profile": "engineering",
  "status": "VERIFIED",
  "runner": { "name": "cvp-runner", "version": "1.0.2" },
  "environment": {
    "runtime": "node",
    "runtime_version": "20.11.0",
    "numeric_model": "IEEE-754 binary64"
  },
  "suite": {
    "id": "amps-to-volts",
    "version": "1.0.3",
    "uri": "https://calculatorx.com/evidence/suites/amps-to-volts@1.0.3"
  },
  "obligation_set": [
    "CVP-PROV-01",
    "CVP-MODEL-01",
    "CVP-SCOPE-01",
    "CVP-UNIT-01",
    "CVP-REF-01",
    "CVP-GOLD-01",
    "CVP-BND-01",
    "CVP-INV-01",
    "CVP-NUM-01",
    "CVP-COV-01",
    "CVP-CONTRACT-01",
    "CVP-DEP-01",
    "CVP-ART-01",
    "CVP-PROD-01",
    "CVP-DIM-01",
    "CVP-PROP-01",
    "CVP-IFACE-01"
  ],
  "reference": {
    "items": [
      {
        "class": "O1",
        "scope": "model",
        "label": "textbook ohms-law worked example"
      },
      {
        "class": "O3",
        "scope": "expected_values",
        "engine": {
          "name": "mpmath",
          "precision_bits": 256,
          "independent_of_iut": true
        }
      },
      {
        "class": "O4",
        "scope": "model",
        "engine": {
          "name": "sympy",
          "independent_of_iut": true
        }
      }
    ]
  },
  "controls": {
    "CVP-REF-01": { "result": "PASS", "applicability": "required" },
    "CVP-GOLD-01": { "result": "PASS", "applicability": "required" },
    "CVP-NUM-01": { "result": "PASS", "applicability": "required" },
    "CVP-COV-01": { "result": "PASS", "applicability": "required" },
    "CVP-IFACE-01": { "result": "PASS", "applicability": "applicable" },
    "CVP-EXP-01": { "result": "SKIP", "applicability": "optional" }
  },
  "tests": {
    "golden": {
      "passed": 48,
      "total": 48,
      "failed": 0,
      "case_ids": ["g-001", "g-002"]
    },
    "property": {
      "passed": 100000,
      "total": 100000,
      "failed": 0,
      "seed": "9f2c…",
      "generator_id": "ohms-law-props",
      "generator_version": "1.2.0",
      "definition_ids": ["prop-v-over-i-eq-r"]
    },
    "contract": { "passed": 1, "total": 1, "failed": 0 }
  },
  "coverage": {
    "partitions": [
      { "id": "normal-dc", "exercised": true, "case_count": 40 },
      { "id": "near-zero-r", "exercised": true, "case_count": 8 }
    ]
  },
  "numerical": {
    "representation": "IEEE-754 binary64",
    "tolerance": {
      "type": "ulp",
      "value": 2,
      "rationale": "binary64 elementary operation policy for ohms-law family",
      "declared_before_evaluation": true
    },
    "max_error_observed": 0
  },
  "artifacts": {
    "evidence_bundle_sha256": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "production_sha256": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
  },
  "attestation": {
    "status": "CURRENT",
    "attested_at": "2026-09-05T12:00:00Z"
  },
  "timestamps": { "verified_at": "2026-09-05T12:00:00Z" }
}

Appendix B — Changelog

Appendix C — Diff vs prior internal draft (informative)

Assessment: Prior internal draft ~8.3/10; this Proposed final text ~9.2/10 design readiness. Remaining work before Stable: implement CVP Runner + Evidence Manifest; validate on dozens of heterogeneous calculators without special exemptions; apply formal JSON canonicalization before relying on signed manifests; optional methodology review of CVP itself.

End of Proposed CVP 1.0.0