Validation
Hardened audit system around the calculator suite. Every case has a formula, an expected value with provenance, an actual value computed live, a trust label, a tolerance, and a receipt hash.
Trust label legend
Every validation case carries exactly one trust label declaring what the case proves. These labels are emitted into the certificate and the JSON report so downstream reviewers know what kind of evidence a PASS represents.
Summary
Cross-tool consistency checks
These cases compute the same physics term through two independent code paths in shared/shared.js / shared/validation.js and assert that the results agree to floating-point precision. They detect drift between calculators rather than validating any external reference.
| ID | Case | Expected | Actual | Status |
|---|
Authoritative constants
Every constant used by the calculators with its public source. Edit a constant in shared/shared.js only with a matching source change here.
| Symbol | Value | Units | Source | Note |
|---|
Validation cases
Analytic textbook cases — exact closed-form expected values
| ID | Case | Formula | Expected | Actual | Rel. err | Tol | Status |
|---|
JPL Horizons public geometry — publicly tabulated ephemeris snapshots
Tolerances are relaxed to absorb published rounding, NOT to admit drift. Anchor values are recorded explicitly in shared/validation.js.
| ID | Case | Formula | Expected | Actual | Rel. err | Tol | Status |
|---|
NASA/JPL DSOC public scenario anchors — scenario anchors only
| ID | Case | Formula | Expected | Actual | Rel. err | Tol | Status |
|---|
Public-data experimental cross-checks — canonical experiments and published measurements
Compares the calculators' outputs against published values from canonical GR experiments (Eddington, GPS / Ashby, Pound–Rebka, Vessot–Levine GP-A, Cassini superior-conjunction, NASA DSOC public records). Tolerances reflect published precision plus the model's approximation order.
| ID | Case | Formula | Expected | Actual | Rel. err | Tol | Status |
|---|
Adversarial / fail-closed tests — calculators must error or warn on bad inputs
| ID | Case | Failure condition | Expected | Actual | Rel. err | Tol | Status |
|---|
Cross-tool consistency — same physics through two code paths must match
| ID | Case | Formula | Expected | Actual | Rel. err | Tol | Status |
|---|
Source registry
Every formula and constant points to a public source. Source IDs in the validation cases above resolve to entries here.
| ID | Name | Role |
|---|
Deployment-blocking test rules
- Every case marked
required: trueinshared/validation.jsmust PASS. - If any required case fails, the deployment gate above goes to
BLOCK. - Adversarial cases test that the calculator fails closed on bad inputs; their PASS condition is that a NaN, Infinity, or warning is produced.
- The receipt hash is recomputed on every page load. Two reviewers running this page should obtain the same receipt hash if the calculator module is unchanged.
Certificate format
Every calculator on the lab also exports a JSON certificate. Schema:
{
"tool": "<tool-name>",
"version": "0.1.0",
"timestamp_utc": "ISO-8601",
"inputs": { ... },
"constants": { ... },
"formulas": [ "Δt = (1+γ) GM/c³ ln((r1+r2+R)/(r1+r2-R))", ... ],
"assumptions": [ ... ],
"outputs": { ... },
"tolerance_tests": [ { "term": "...", "rank": "KEEP|WATCH|IGNORE", ... } ],
"warnings": [ ... ],
"source_notes": [ ... ],
"generator": "Relativistic Optics Lab (...)",
"hash": { "sha256": "<64-hex>", "short": "<12-hex>" }
}
Download report
The full validation report can be downloaded as JSON. This is the result that should be archived alongside any engineering note that cites a calculator output.