Evidence identity
Original bytes or native observations keep stable identity, content digests, source metadata, custody, and exact addressable fragments.
ARCHITECTURE
Build the decision so its foundation can still be inspected later.
METRAXIOM combines a metrology-specific execution system with the DUEPROOF assurance kernel. The product keeps measurement meaning close to the technician while preserving the dependency, challenge, correction, recall, and proof controls needed for later reconstruction.
THE CONTROLLED MEASUREMENT-DECISION CHAIN
The public story and the technical record follow the same sequence.
The interface can simplify what appears first, but it cannot remove or merge facts whose distinctions matter to a measurement, decision, review, correction, or future recall.
- 01Identity
The physical instrument, measurement system, function, channel, range, configuration, and lifecycle state.
- 02Context
The measurand, intended use, criticality, environment, location, job, and retained context revision.
- 03Authority
The exact procedure, specification, policy, decision rule, competency, and effective revisions.
- 04Reference
Standards, check standards, monitors, fixtures, materials, software, and capability at time of use.
- 05Observe
Raw DUT, reference, environment, and acquisition facts with timestamps and provenance.
- 06Model
Corrections, conversions, constants, formulas, uncertainty components, and exact calculation version.
- 07Decide
Specification, acceptance boundaries, guard band, decision rule, result, and reason codes.
- 08Review
Exceptions, contradictions, contest, human responsibility, approval, and release authority.
- 09Prove
Manifest, fingerprints, certificate projection, audit lineage, dependency graph, and verifier profile.
BRAND AND CONTROL STACK
METRAXIOM is the product. DUEPROOF is the assurance kernel beneath it.
Customers use METRAXIOM to configure, execute, evaluate, review, package, and manage measurement work. DUEPROOF supplies the generic control vocabulary for evidence identity, material reliance, gates, challenge, correction, recall, proof, and independent verification.
DUEPROOF does not replace technician language, appear as a second product in primary navigation, or become an accreditation-like mark on certificates. It is revealed where technical depth is useful: Architecture, Trust, Documentation, proof-package verification, and enterprise review.
Customer-facing productMETRAXIOM Measurement Intelligence
CategoryMeasurement-decision infrastructure
Interactive proofCalibration Studio
Private executionMeasurement Workspace
Assurance kernelMETRAXIOM DUEPROOF
Current deploymentPublic-production evaluation; private workspace and authoritative measurement release independently held
DUEPROOF ASSURANCE KERNEL
Provenance is necessary. Dependency and correction make it operational.
A conventional audit log records that something changed. DUEPROOF is designed to record what materially relied on the changed object, why that reliance existed, what must now be re-examined, and how the original state remains reconstructable.
Typed support
Evidence can support, contradict, contextualize, authenticate, or originate a material claim; retrieval rank alone is not evidence.
Material reliance
Explicit edges record which result materially depended on which method, standard, model, approval, specification, or source.
Deterministic gates
Required integrity, policy, authority, reference, calculation, approval, contest, and recall conditions produce machine-readable PASS, HOLD, FAIL, ERROR, or NOT_APPLICABLE states.
Contest and correction
Challenges are structured objects. Sustained corrections supersede prior state without erasing historical justification.
Dependency recall
A material change traverses declared reliance paths under a versioned algorithm and creates review, recalculate, notify, suspend, or invalidate actions.
Proof packages
A versioned manifest enumerates included objects, hashes, limitations, unresolved disputes, recall state, and verification instructions.
Independent verification
A separate verifier can validate package structure, hashes, signatures or attestations, schema, and internal references without trusting the authoring UI.
CONTEST + CORRECTION · SYNTHETIC PROTOTYPE
A correction supersedes the disputed assertion. It does not erase it.
The prototype models a challenge as a retained object, requires an explicit resolution, and permits a replacement assertion only when the challenge is sustained. The prior assertion remains in the historical chain so later reliance and proof can reconstruct what was believed before the correction.
Projection only — no release or recall authority.
This synthetic ledger does not mutate customer records, release a calibration, initiate recall, or make a product disposition. Hosted contest/correction persistence and authority remain separately gated.
Projection stateCORRECTED CURRENT
Original assertion retainedNo correction applied to the retained 10 V DC reference range.
Structured contestREFERENCE_OOT_EVIDENCE · SUSTAINED
Supersessionassertion:rs-00481:rev-1 → assertion:rs-00481:rev-2
Current assertionSupported correction envelope is +300 µV to +420 µV for the bounded incident interval.
History length2 assertions · 1 correction
Authorityprojection only no release or recall authority
CURRENT CAPABILITY STATUS
Architecture, implementation, validation, and release are different states.
This status table prevents an adopted design from being described as an already validated production control. Each enabled feature must still produce implementation and acceptance evidence for the exact build.
Public deterministic proof
ImplementedServer-side sample engine candidate 0.3.4-candidate; bounded sample data and reproducibility fingerprint.
Calibration context and procedure authority
ImplementedRetained context revisions, scoped procedure revisions, preflight authority display, and transaction expectation lock.
Pressure work-package lineage
ImplementedAs-found, post-adjustment, and as-left sessions; append-only observations; candidate manifest and completion gates.
Hosted tenant/security foundation
ImplementedOrganization-scoped workspace model, server-side checks, RLS assumptions, MFA paths, CSP/origin controls, and private-route noindex.
DUEPROOF canonical kernel
Adopted / gatedArchitecture and control hierarchy adopted; public proof, material-reliance, synthetic contest/correction, deterministic recall-action projection, manifest-driven portable impact-package reconstruction, and a zero-application-import standalone integrity verifier reference are implemented, while hosted persistence, production reliance capture, recall/notification/disposition execution, anchored trust, and externally independent verifier acceptance remain gated.
Authoritative release
GatedSeparate production flag and validation evidence required; calculation, review, subscription, or UI state cannot confer release.
Local Professional / Air-Gapped editions
PlannedArchitecture permits deployment profiles, but installer, identity, keys, backup, verifier, update, support, and validation paths are not yet released.
TRUTH AND AUTHORITY BOUNDARY
Cryptography can prove bytes and signatures. It cannot prove factual truth.
METRAXIOM uses exact language: hashed, integrity checked, signature verified, trusted timestamp present, or tamper-evident under a named profile. Source authenticity, reliability, relevance, freshness, authority, fitness, corroboration, and measurement uncertainty remain separately evaluated properties.
The standalone impact-package integrity verifier and its scope/readme are public reference artifacts with zero METRAXIOM application imports. They verify internal digest integrity only; external verifier acceptance and issuer identity remain unearned.
AI remains advisory.
A model may extract, retrieve, explain, summarize, or challenge. It cannot silently create measurement facts, approve a source, alter canonical evidence, waive a gate, authorize a decision, sign a package, or release a calibration result.
Review AI & Data Use →BUILD AND RELEASE IDENTITY
A deploy is not authority.
Every authoritative path must resolve to the source commit, dependency lock, migrations, configuration, procedure and specification revisions, calculation model, decision rule, gate results, approvals, and proof profile used at the time. Release follows validation, restore, security, accessibility, metrology, and production-verification gates—not visual completion alone.