Model identity
Does the named method use the stated likelihood, parameterization, termination rule and data-generating assumptions?
Verification & model assurance
Know what supports a result
Perdura is intended to support engineering decisions, not merely produce plausible numbers. Its assurance process asks whether the correct model was implemented, whether it is complete for the stated scope, whether its uncertainty behaves as claimed, and whether that meaning survives every step from calculation to report.
Claims are scoped to their evidence.
A passing build verifies the tested software revision. A standards parity
test supports the mapped clauses and examples. Neither is automatically a
certification of every model or proof of suitability for a particular use.
What quality means here
More than implementation consistency
Tests that repeat the production formula can preserve the same mistake. Perdura separates six questions that require different evidence.
Equation correctness
Do estimators, statistics, intervals and predictions agree with an authoritative derivation or independent oracle?
Capability completeness
Are required inputs, regimes, outputs and diagnostics implemented—or recorded explicitly as gaps?
Statistical calibration
Do confidence levels, tests and prediction intervals achieve their intended behavior in the regimes where they are offered?
Numerical robustness
Are sparse data, censoring, ties, boundaries, extreme scales, weak identification and optimizer failures handled explicitly?
Semantic integrity
Do units, assumptions, parameters, uncertainty and eligibility retain the same meaning in the API, UI, saved project, plot and export?
Governing record: Perdura model-assurance framework ↗
How a claim is challenged
Independent references, adverse regimes and complete data paths
The applicable checks depend on the result. Point estimates, confidence intervals, optimization decisions and standards tables do not share one interchangeable definition of “tested.”
- Trace the source. Record the governing edition, equation, clause or table and the precise scope represented in the software.
- Use an independent expected result. Compare with printed worked examples, analytic identities, published datasets or separately implemented numerical oracles—not a restatement of production code.
- Cross the difficult regimes. Exercise small and large samples, complete and censored observations, ties, sparse cells, boundaries, unit rescaling, and model misspecification where applicable.
- Calibrate inferential claims. Use seeded simulation studies to separate fit eligibility, interval completion and repeated-sampling coverage rather than reporting only successful refits.
- Fail closed. Reject invalid domains and disclose non-convergence, boundary contact, weak identification and unsupported inference instead of returning a normal-looking result.
- Follow the result end to end. Verify request schemas, calculation contracts, persistence, invalidation, plots, reports and exported representations.
Deeper view: why test count is not the quality claim
A large regression suite is valuable for detecting change, but count alone says nothing about the independence or relevance of its expected values. Perdura’s assurance records map evidence to a specific model, claim and operating regime. Consistency tests remain useful, but they are not promoted to independent scientific validation.
The matrix also records unsupported regimes and unresolved blockers. Its structural gate can pass while a model remains unverified; the stricter scientific gate cannot.
Inspect the machine-readable assurance matrix ↗ Standards and named methods
A source name is not treated as automatic conformance
Standards-based calculators identify their edition, implemented scope, exclusions, clause coverage and validation basis. Fully mapped methods, partial implementations, screening models and user-defined rules are presented as different evidence classes.
For example, MIL-HDBK-217F Notice 2, ANSI/VITA 51.1 and the implemented RADC nonoperating method have source-specific coverage and parity records. Other prediction methods remain explicitly labeled as screening models where complete licensed tables or workflows have not been reproduced.
Review standards coverage ↗| Evidence class | What it supports |
|---|---|
| Verified implementation | Mapped scope with authoritative examples or independent table/equation oracles. |
| Partial implementation | Selected verified content with incomplete source coverage disclosed. |
| Screening model | Preliminary comparison or trade study, not full source conformance. |
| User-defined method | A project rule supplied and governed by the user. |
Why this improves decisions
Results carry context, not just values
Eligibility before ranking
Failed, unsupported or statistically ineligible candidates are kept out of ordinary model comparisons.
Uncertainty with meaning
Intervals identify their method and target; approximations and unverified boundary cases are not silently presented as regular inference.
Drivers remain visible
Factor contributions, importance measures, sensitivity results and diagnostics show which inputs control the conclusion.
Decisions remain reviewable
Projects retain inputs and analysis state, while reports and exports can retain the software and analysis identity behind the result.
Inferential detail: uncertainty validation methodology ↗
Build and artifact evidence
Trace a file back to the software that produced it
Every CI run compiles a printable HTML report and a canonical JSON record with structured test results, branch coverage, API contracts, reference checks, platform manifests, logs and SHA-256 checksums. Releases retain their verification evidence alongside the packaged application.
Perdura exports can optionally be bundled with a provenance manifest containing the artifact digest, project identity, software version, source commit, build-evidence link and relevant analysis fingerprints. This establishes integrity and traceability—not a digital signature or producer authentication.
Current assurance boundary
Strong evidence, stated conservatively
Perdura’s automated evidence supports technical review, reproducibility and controlled change. It is not regulatory certification, independent validation, or proof that every model is complete for every application.
The strict whole-product scientific gate remains intentionally closed while the complete model inventory and claim-by-regime evidence are still being developed. A user or organization remains responsible for intended-use validation, requirements approval, configuration control, risk management, and record retention. This limitation is part of the assurance case, not a footnote to it.