certifiable-verify

When a regulator asks “how do you know the deployed model matches what was trained?”, what’s your answer?

If it involves spreadsheets, manual checksums, or “we have a process”, you have a problem. Not because those approaches don’t work — but because they don’t prove anything in a way that can be independently verified.

certifiable-verify validates the complete provenance chain through cryptographic binding verification.

View on GitHub

The Problem

The certifiable-* ecosystem produces cryptographic commitments at every stage:

• certifiable-data produces a Merkle root of training batches
• certifiable-training produces a gradient chain hash
• certifiable-quant produces an error certificate
• certifiable-deploy produces an attestation tree
• certifiable-inference produces a predictions hash
• certifiable-monitor produces a ledger digest

But commitments alone aren’t enough. You need to verify that each commitment binds correctly to the previous stage. That the training hash actually includes the data Merkle root. That the deployment bundle contains the quantized model that was certified. That the chain is unbroken from input data to deployed inference.

That’s what certifiable-verify does.

Two Verification Modes

Hash-Only Mode — Fast verification using pre-computed commitments:

cv_config_t config;
cv_config_default(&config);
config.mode = CV_MODE_HASH_ONLY;

cv_artifacts_t artifacts;
/* Load commitments from each stage... */

cv_report_t report;
cv_fault_flags_t faults = {0};

cv_result_t rc = cv_verify(&config, &artifacts, &report, &faults);

if (report.pipeline_valid) {
    printf("Pipeline verified ✓\n");
}

Full Replay Mode — Complete re-execution for maximum assurance:

config.mode = CV_MODE_FULL_REPLAY;
config.data_path = "training_data.csv";
config.model_path = "model.cbf";

/* Re-runs entire pipeline, compares against recorded commitments */
cv_result_t rc = cv_verify(&config, &artifacts, &report, &faults);

Six Cross-Artifact Bindings

certifiable-verify validates six cryptographic bindings between pipeline stages:

Each binding is verified independently. If binding 2 fails but others pass, you know exactly where the chain broke.

cv_binding_result_t binding;
cv_verify_binding(CV_BINDING_QUANT_DEPLOY, &artifacts, &binding, &faults);

if (!binding.valid) {
    printf("Bundle doesn't match quantization certificate\n");
    printf("Expected: %s\n", binding.expected_hex);
    printf("Found: %s\n", binding.actual_hex);
}

Report Generation

certifiable-verify produces machine-readable reports with self-integrity hashes:

cv_report_write_json(&report, "verification_report.json", &faults);

{
  "version": "1.0.0",
  "timestamp": "2026-01-19T21:00:00Z",
  "pipeline_valid": true,
  "bindings": [
    {"id": 0, "name": "data→training", "valid": true},
    {"id": 1, "name": "training→quant", "valid": true},
    {"id": 2, "name": "quant→deploy", "valid": true},
    {"id": 3, "name": "deploy→inference", "valid": true},
    {"id": 4, "name": "inference→monitor", "valid": true},
    {"id": 5, "name": "deploy→monitor", "valid": true}
  ],
  "report_hash": "a3f2c8..."
}

The report_hash covers the entire report content, enabling tamper detection.

Test Coverage

All 10 test suites passing.

Part of a Complete Pipeline

certifiable-verify is stage 6 in the certifiable-* ecosystem:

data → training → quant → deploy → inference → monitor → verify

It’s the final stage — the one that answers “is this pipeline intact?”

When You Need This

Aerospace (DO-178C): Requires traceability from requirements through implementation to test. certifiable-verify extends this to the ML pipeline itself — proving that the deployed model traces back to specific training data through an unbroken chain of cryptographic commitments.

Medical Devices (IEC 62304): Class C software requires rigorous verification. certifiable-verify provides automated, repeatable verification that can be run before every deployment — not just during initial certification.

Automotive (ISO 26262): ASIL-D requires evidence that safety-critical software behaves as specified. certifiable-verify produces that evidence in a format that’s machine-verifiable and auditable.

Getting Started

git clone https://github.com/williamofai/certifiable-verify.git
cd certifiable-verify
mkdir build && cd build
cmake ..
make
ctest --output-on-failure

Documentation

The repository includes formal documentation suitable for certification evidence:

• CV-MATH-001.md — Mathematical specification (47KB)
• CV-STRUCT-001.md — Data structure specification
• SRS-001 through SRS-008 — Software Requirements Specifications

License

Dual licensed under GPLv3 (open source) and commercial terms for proprietary safety-critical systems. The implementation builds on the Murray Deterministic Computing Platform (UK Patent GB2521625.0).

For teams building safety-critical ML systems, certifiable-verify provides the formal rigour that certification demands. As with any architectural approach, suitability depends on system requirements, risk classification, and regulatory context.

View on GitHub · Request Technical Brief