Certifiable Deploy

You’ve trained a model deterministically. You’ve quantized it with formal error bounds. Now you need to deploy it to production hardware. How do you prove the deployed model matches what was certified? How do you verify weights haven’t been tampered with? How do you maintain cryptographic provenance from training to deployment?

For safety-critical systems, “trust me, it’s the right model” is not certifiable.

certifiable-deploy implements the “Execution ⇒ Verification” invariant: the inference API is enabled only after measured hashes of weights and kernels match the certificate claims and attestation root.

View on GitHub

The Problem

Deploying ML models to safety-critical systems faces fundamental challenges:

1. Provenance: How do you prove the deployed model matches what was certified?
2. Integrity: How do you verify weights haven’t been tampered with in transit or at rest?
3. Binding: How do you ensure the model runs only on approved hardware?
4. Auditability: How do you maintain cryptographic proof linking deployment back to training?

Standard deployment pipelines—containers, model registries, package managers—assume trust. They provide checksums for convenience, not for certification. When a regulator asks “prove this is the model you certified,” a Docker image hash doesn’t satisfy DO-178C.

The Solution

certifiable-deploy provides five core components that work together to create a verifiable deployment chain.

1. Canonical Bundle Format (CBF v1)

A deterministic container with no ambient metadata. Payloads, table of contents, and attestation in a single verifiable package:

┌─────────────────────────────────────┐
│           Global Header             │
│  magic(4) | version(4) | offsets    │
├─────────────────────────────────────┤
│          File Payloads              │
│  (raw bytes, no metadata)           │
├─────────────────────────────────────┤
│        Table of Contents            │
│  entry_count | entries[]            │
│  (sorted by normalized path)        │
├─────────────────────────────────────┤
│             Footer                  │
│  merkle_root | signature | magic    │
└─────────────────────────────────────┘

No timestamps. No filesystem metadata. No ambient authority. The same content produces the same bundle produces the same hash, forever.

2. Merkle Attestation

A 4-leaf Merkle tree binds manifest, weights, certificates, and inference artifacts into a single attestation root:

        R (root)
       / \
      R₁  R₂
     / \  / \
    L_M L_W L_C L_I

Where:

• L_M = domain hash of manifest
• L_W = domain hash of weights
• L_C = domain hash of certificate chain
• L_I = domain hash of inference kernels

The root R is what gets signed. Tampering with any leaf changes the root.

3. JCS Manifest (RFC 8785)

The manifest uses JSON Canonicalization Scheme for deterministic serialization. Same content = same bytes = same hash:

cdm_builder_t mb;
cdm_builder_init(&mb);
cdm_set_mode(&mb, "deterministic");
cdm_set_created_at(&mb, 0);  // No timestamps
cdm_set_target(&mb, &target);
cdm_set_weights_hash(&mb, &h_weights);
cdm_set_certs_hash(&mb, &h_certs);
cdm_set_inference_hash(&mb, &h_inference);

uint8_t manifest_json[4096];
size_t manifest_len = sizeof(manifest_json);
cdm_finalize_jcs(&mb, manifest_json, &manifest_len);

JCS ensures key ordering and numeric representation are canonical. No “semantically equivalent but different bytes” ambiguity.

4. Target Binding

Lock bundles to specific platforms with target tuples:

arch-vendor-device-abi

Examples:

• riscv64-tenstorrent-p150-lp64d
• x86_64-intel-xeon-sysv
• aarch64-nvidia-orin-lp64

Wildcards (generic) allow bundles to match multiple devices while maintaining architecture/ABI safety. A bundle built for x86_64-generic-cpu-sysv runs on any x86_64 SYSV system. A bundle built for riscv64-tenstorrent-p150-lp64d runs only on that specific accelerator.

5. Runtime Loader (CD-LOAD)

The loader implements a fail-closed state machine. JIT hash verification at every stage:

INIT → HEADER_READ → TOC_READ → MANIFEST_VERIFIED →
WEIGHTS_STREAMING → WEIGHTS_VERIFIED →
INFERENCE_STREAMING → INFERENCE_VERIFIED →
CHAIN_VERIFIED → ENABLED

Any State --[error]--> FAILED (terminal)

Any verification failure immediately transitions to FAILED, which cannot be exited. The inference API is unreachable without completing the full verification chain.

cd_load_ctx_t ctx;
cd_target_t device_target;

// Set device target
cdt_set(&device_target, CD_ARCH_X86_64, "intel", "xeon", CD_ABI_SYSV);

// Initialize loader
cdl_init(&ctx, &device_target);

// Open bundle (verifies header, TOC, manifest, target)
cdl_open_bundle(&ctx, bundle_data, bundle_len);

// Load weights with JIT hash verification
cdl_load_weights(&ctx, weights, weights_size);

// Load inference kernels with JIT hash verification
cdl_load_kernels(&ctx, kernels, kernel_size);

// Finalize (verifies Merkle root)
cdl_finalize(&ctx);

// Only now is execution permitted
if (cdl_is_enabled(&ctx)) {
    run_inference(weights, kernels);
}

Domain-Separated Hashing

All hashes use domain separation to prevent cross-protocol attacks:

DH(tag, payload) = SHA256(tag || LE64(|payload|) || payload)

Domain tags include:

• CD:MANIFEST:v1 — Manifest hash
• CD:WEIGHTS:v1 — Weights hash
• CD:CERTSET:v1 — Certificate chain hash
• CD:INFERSET:v1 — Inference set hash
• CD:LEAF:*:v1 — Merkle leaf hashes
• CD:MERKLENODE:v1 — Merkle internal nodes

A weights file cannot be substituted for a manifest, even if they happen to have the same content. The domain tag makes them cryptographically distinct.

What’s Implemented

All modules complete — 201 tests passing across 7 test suites:

The Complete Pipeline

certifiable-deploy bridges the gap between quantization and inference:

certifiable-data → certifiable-training → certifiable-quant → certifiable-deploy → certifiable-inference
     ↓                    ↓                     ↓                    ↓                      ↓
  Load data         Train model          Quantize model        Package bundle         Run inference
  Normalise         Merkle chain         Error bounds          Attestation            Bit-perfect
  Shuffle           Audit trail          Certificate           Target binding         execution

Each project maintains the same principles: pure C99, zero dynamic allocation, formal verification patterns, and cryptographic audit trails.

Why It Matters

Medical Devices

IEC 62304 Class C requires traceable, reproducible software. When a pacemaker’s ML model makes a decision, you need to prove it’s running exactly what was validated. certifiable-deploy provides cryptographic evidence linking the deployed binary to the certified source.

Autonomous Vehicles

ISO 26262 ASIL-D demands provable behaviour. The perception model that passed simulation must be bit-identical to the perception model in the vehicle. Target binding ensures the certified bundle only runs on approved hardware configurations.

Aerospace

DO-178C Level A requires complete requirements traceability. “We deployed the model” satisfies no one. The Merkle attestation provides cryptographic proof linking each deployment artifact back through quantization, training, and data preparation.

Integration Points

certifiable-deploy is designed for integration with existing security infrastructure:

Ed25519 Signing: The cda_sign() function provides the interface for signing attestation roots. Integrators provide their own Ed25519 implementation appropriate for their security requirements (HSM, libsodium, certified library).

Certificate Chain: Certificate parsing requires integration with the deployer’s PKI infrastructure. The certificate format is defined by the upstream certifiable-* pipeline.

Getting Started

git clone https://github.com/williamofai/certifiable-deploy
cd certifiable-deploy
mkdir build && cd build
cmake ..
make
make test-all

Expected output:

100% tests passed, 0 tests failed out of 7
Total Test time (real) = 0.02 sec

Documentation

The repository includes formal documentation suitable for certification evidence:

• CD-MATH-001.md — Mathematical foundations
• CD-STRUCT-001.md — Data structure specifications
• SRS documents — Software Requirements Specifications:
  • SRS-001-BUNDLE — CBF v1 format
  • SRS-002-ATTEST — Merkle attestation
  • SRS-003-TARGET — Target binding
  • SRS-004-MANIFEST — JCS canonicalization
  • SRS-005-VERIFY — Offline verification
  • SRS-006-LOADER — Runtime loader

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 deploying ML to safety-critical systems, certifiable-deploy provides the cryptographic 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