Calculator Verification Protocol

Proposed CVP 1.0 — not Stable.

A public, versioned protocol for verifying CalculatorX computational tools with reproducible evidence.

Layer	Answers
Evidence	What evidence exists for a calculator?
CVP (this page)	Which rules make that evidence sufficient?
Trust Summary	How do humans read the evaluation result?

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

Trust architecture

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

What does CVP Verified mean?

CVP Verified is CalculatorX machine verification against the public CVP protocol for a declared version and assurance profile. Evidence (Manifest, tests, digest, production attestation) is inspectable.

It does not mean third-party certification, laboratory accreditation, or an independent audit — unless that is explicitly stated. It does not mean every possible input has been enumerated. It means the declared model passed the required controls as specified, with published evidence.

Core (pure math / unitless transforms) is that machine-verification profile: algebraic model, independent O2 expected values, golden / boundary / invalid-input cases, declared partition coverage, contracts, cross-interface consistency, and production attestation. Domain expert review is optional; when it has not been performed, that absence is disclosed.

While Proposed, UI MUST show the CVP protocol version (including -proposed) plus the assurance profile in the badge (e.g. CVP VERIFIED · CVP protocol 1.0.0-proposed · Engineering assurance), not bare CVP VERIFIED. Do not emit a bare Proposed 1.0.0 token next to Calculation 1.1.1 — that collides with calculation versions. The assurance token is the CVP profile, not a calculator input mode. When a Manifest declares verified_scope, the badge and Trust card SHOULD show that scope as a claim field (example: Verified scope: Basic RSS/WCA).

What cross-interface PASS means

CVP-IFACE-01 compares equivalent semantic inputs across published surfaces: crawlable UI (SSR) query-result HTML, REST, and MCP. MCP invokes the same calc API handler as REST — it is not a second independent runtime.

PASS means those surfaces agreed on the recorded samples. It does not prove a live browser session, client hydration, cache switching, or end-to-end UI interaction. Those remain outside Core interface evidence unless a separate check is explicitly recorded.

Core controls (summary)

CVP evaluates objective evidence across:

• Formula / model provenance
• Independent reference (reference_scope: model · expected values · numerical behavior)
• Golden, boundary, and invalid-input tests
• Numerical policy (no post-hoc tolerance fit)
• Input / mode coverage
• Semantic contracts
• Cross-interface consistency (when multiple surfaces exist)
• Artifact integrity
• Production attestation
• Stochastic / Monte Carlo contract (when the IUT is RNG-driven): RNG + seed + sampler, seeded O2, analytic vs sampling layers, semantic partitions, sampling CI

Normative MUST / SHOULD language lives only in the specification.

Assurance profiles

Profile	Typical use
core	Pure math / unitless transforms
engineering	Physical models with units and assumptions
numerical	Iterative / approximate / high-precision algorithms

Random / Monte Carlo calculators keep their assurance profile (engineering or numerical) and additionally satisfy the stochastic contract: RNG + seed + sampler, a seeded stochastic O2, analytic vs sampling layers, semantic partitions, and sampling CI when yield is published. Gold standard: Monte Carlo Tolerance Analysis.

CVP vs Review policy

Signal	Role
CVP	Computational verification status from Evidence Manifest
Review policy / Domain Expert Review	Supplemental human / domain assurance — does not by itself determine CVP conformance

Short-term both coexist. Long-term, CalculatorX trust claims migrate to the CVP evidence model.

Reproducing O3 reference tables

Calculators that declare O3 (mpmath high-precision, or MPFR only when that backend is recorded) expected values publish the generator, table, hashes, and the tabulated vectors — not only the pass/fail summary. The same reproduce contract covers math and engineering pilots.

Math example — math.cos

Item	Location
Public reproduce page	/evidence/math.cos/reproduce
Reproduce JSON	/evidence/math.cos/reproduce.json
Public table	/developers/cvp/reproduce/math-o3-tables.json
Public generator	/developers/cvp/reproduce/generate-math-o3.py
Workspace generator	scripts/lib/cvp/oracles/generate-math-o3.py
Re-run command	python3 scripts/lib/cvp/oracles/generate-math-o3.py
Pack re-run	npm run cvp:run -- --capability math.cos

Engineering example — electrical.rf.antenna_length

Antenna Length (1.0.3, verification revision 2026-09-11.o3-cov) is the public engineering O3 template: element-fraction model (O1) plus V8-independent mpmath table (O3).

Item	Location
Public reproduce page	/evidence/electrical.rf.antenna_length/reproduce
Reproduce JSON	/evidence/electrical.rf.antenna_length/reproduce.json
Public table	/developers/cvp/reproduce/antenna-length-o3-tables.json
Public generator	/developers/cvp/reproduce/generate-antenna-length-o3.py
Workspace generator	scripts/lib/cvp/oracles/generate-antenna-length-o3.py
Re-run command	python3 scripts/lib/cvp/oracles/generate-antenna-length-o3.py
Pack re-run	npm run cvp:run -- --capability electrical.rf.antenna_length
Immutable Manifest	/evidence/electrical.rf.antenna_length/1.0.3/2026-09-11.o3-cov.cvp.json

Shared reproduce fields and CLI

Manifest fields: generator_id, seed, table_sha256, reproduce, claim_scope, links.reproduce.

Each reproduce vector lists inputs, expected_f64 / expected_decimal, the last IUT actual, and ULP error. Re-running the generator without changing seed or inputs should reproduce the table digest.

A third party can re-check a published package without the CalculatorX engine:

npm run cvp:verify -- public/evidence/math.cos
npm run cvp:verify -- public/evidence/electrical.rf.antenna_length
# or: node scripts/run-cvp.mjs verify --package <dir|reproduce.json|pack.zip>

That CLI hashes the O3 table and/or re-runs the public O2 checker. It is not a hosted runner (runner.calculatorx.com) and does not prove a live browser session.

Claim scope: O3 PASS means the published tabulated vectors met the a-priori ULP policy. It does not mean every real input (huge angles, unlisted zeros, or unlisted antenna geometries) meets the same bound.

Versions: calculator.version is the calculation algorithm; protocol.version is CVP; verification_revision is the evidence batch. Adding CVP controls does not by itself bump the calculation version. Antenna Length stays 1.0.3 while evidence revision 2026-09-11.o3-cov evolves independently.

Digest names (do not interchange)

Agents often see several SHA-256 values labeled loosely as “evidence digest.” They hash different subjects:

Interop name	Field	Scope
cvp_core_sha256 / cvp_evidence_digest	Manifest artifacts.cvp_core_sha256 (= evidence_digest)	CVP verification fingerprint v2 (immutable core)
artifact_evidence_sha256	Evidence release_integrity.digests.evidence_core_sha256	Canonical Evidence core (Trust freshness)
evidence_catalog_digest	Manifest artifacts.attested_catalog_sha256 / report attested_catalog_digest	Capability catalog integrity

Core vs Overlay: attestation status, CURRENT/STALE, timestamps, and Evidence tests.contract counts are Trust Overlay — they MUST NOT change cvp_core_sha256. Immutable pins are write-once for a given core digest.

Also distinguish display fields:

Field	Meaning
verification_status	Suite obligations only (VERIFIED / FAILED / …)
production_freshness	Attestation bind of cvp_core_sha256 (CURRENT / STALE / ABSENT)
overall_trust	Machine overall (VERIFIED / VERIFIED_STALE / VERIFIED_UNATTESTED / …)
status	Composite Trust projection (suite + freshness). VERIFIED requires CURRENT.

Production Attestation binds cvp_core_sha256, not the overlay revision label and not live CURRENT/STALE fields. Immutable pins are write-once for a given core digest; latest.cvp.json may carry overlay updates.

Manifests SHOULD expose artifacts.digest_registry with digest_scope, digest_algorithm, and canonicalization. Spec: CVP §11.1.

Production attestation

CVP-PROD-01 binds to the site-wide report at /.well-known/calculatorx-production-attestation.json. The calculator Manifest attestation field is a projection of that report onto the capability — not a second independent signature.

Distinguish two layers:

Layer	Meaning
Site-wide artifact checks (status=pass, is_current=true)	Published HTML / schema / evidence digests matched when the report was written
Per-calculator CVP Production CURRENT	Requires CVP Manifest VERIFIED and Manifest attestation CURRENT

A site-wide pass does not by itself authorize Calculator / Capability / Evidence Trust rows to show Production CURRENT, and MUST NOT paint CVP VERIFIED when the Manifest is STALE. Trust surfaces share one final CVP status; local artifact PASS must not independently invent VERIFIED/CURRENT.

calculator-html-cvp-projection is a full Trust Projection equality check, not a badge-only check. Advertised Calculator / Capability / Evidence fields (revision, verified_scope, deferred_scope, coverage N/N, suite counts, digest) MUST match the Manifest. A VERIFIED badge with an old scope-honesty revision is a fail. Share URLs that are a primary UX (for example Tolerance Stack-up ?mode=rss&tol1=…) are probed in addition to the canonical calculator page.

Inside the production report, also distinguish probe snapshot from final CVP status:

Field	Meaning
snapshot_status / items[]	Probe-time checks. Immediately after the digest-stamp attest (before cvp:run + Trust HTML redeploy), CVP surface rows may still say STALE. After the closing attest (post-CVP deploy), these should agree with live VERIFIED.
cvp_probe_status	Index of those probe-time CVP statuses.
current_cvp_status	Final publish gate per capability. Updated when cvp:run binds Manifest attestation to CURRENT; does not rewrite items or mint a new attestation_id until the next --write.

Auditors should prefer a closed deploy (npm run deploy:pages) where the final --write re-probes after VERIFIED is live, so items / cvp_probe_status / current_cvp_status tell one story. If reading an in-flight report, gate on Manifest attestation.status=CURRENT and current_cvp_status, not a lone historical STALE string in an older probe detail.

Site-wide status: stale is not a calculator veto. The top-level report is a snapshot of every attested capability. One STALE capability (or a digest drift) sets status=stale and is_current=false even when 9776/9776 probe items PASS and electrical.apparent_power is VERIFIED + CURRENT. Read these fields instead of treating the first stale token as site-wide failure:

Field	Meaning
snapshot_status	Artifact probe result (pass / fail)
stale_capability_count / cvp.stale	How many capabilities are live CVP STALE
verified_current_capability_count / cvp.current	How many are live VERIFIED + CURRENT
stale_reason	Why the top-level status is stale, including which ids
current_cvp_status.{capability_id}	The calculator gate

After Evidence or Manifest regeneration: digest-stamp with attest:production --write, bind with cvp:run, deploy Trust HTML, then attest again so attested_evidence_digest matches current_evidence_digest and probe rows are not left STALE while Manifest is VERIFIED. A Manifest MUST NOT show CURRENT while the site-wide report is fail for the same evidence set. CVP-PROD-01 MUST FAIL when the bound report status=fail; do not record an unconditional PASS whose notes quote a production FAIL. Site-wide status=stale with snapshot_status=pass does not by itself demote a capability whose current_cvp_status is VERIFIED + CURRENT.

Trust Production copy MUST distinguish the bound snapshot from the live site-wide report when they disagree, including timestamps:

Token	Meaning
Bound attestation PASS @ T1	This calculator's last production bind / snapshot
Site-wide CVP health: N CURRENT · K require re-attestation @ T_live	Live origin report: this calculator may be CURRENT while other capabilities need re-attestation

Do not label baked SSR clocks as Live. Immutable Manifest overlay notes MAY retain the bind-time Live site report phrasing as historical context; Trust HTML MUST not present that bind-time clock as the current site report.

Do not write CVP-PROD-01 notes that say site report pass when the live top-level status is stale. Auditors should see both clocks, not a collapsed CURRENT badge that contradicts the open site report.

Protocol status

Item	Value
Version	1.0.0-proposed
Document status	Proposed (not Stable)
Normative text	/developers/cvp/spec/1.0
Evidence Manifest schema	/developers/cvp/schema · JSON
Errata ledger	/developers/cvp/errata (history only)
Engineering pilots	electrical.amps_to_volts, electrical.adc.snr, electrical.rf.antenna_length (engineering O3 template) → /evidence/{capability_id}/{version}.cvp.json
Math graph pilots	math.arcsin, math.arccos, math.arctan, math.sin, math.cos, math.tan, math.log, math.ln, math.square_root, math.root, math.exponent, math.antilog (core + URL→result→graph)
Math engineering graph	math.exponential_growth (engineering + URL→result→graph; constant-rate model, not a unitless core identity)
Math core (profile only)	arithmetic, fractions, scientific notation, quadratic, percentage / percent change — core, no Live-graph integration claim

Stable readiness (internal) requires a production-grade Runner across heterogeneous calculators without special exemptions, Trust Summary fully derived from the same Manifest, and formal JSON canonicalization before signed manifests.