Skip to content

SpeyTech/certifiable-deploy

BranchesTags

Repository files navigation

certifiable-deploy

Build Status Tests License Platform

Deterministic model packaging and cryptographic attestation for safety-critical ML deployment.

Pure C99. Zero dynamic allocation. Certifiable for DO-178C, IEC 62304, and ISO 26262.

The Problem

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

  • How do you prove the deployed model matches what was certified?
  • How do you verify weights haven't been tampered with?
  • How do you bind inference artifacts to specific hardware?
  • How do you maintain cryptographic provenance from training to deployment?

For safety-critical systems, "trust me, it's the right model" is not certifiable.

Read more:

The Solution

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.

Core Components

1. Canonical Bundle Format (CBF v1) Deterministic container with no ambient metadata. Payloads, TOC, and attestation in a single verifiable package.

2. Merkle Attestation 4-leaf Merkle tree binding manifest, weights, certificates, and inference artifacts:

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

3. JCS Manifest (RFC 8785) Canonical JSON manifest with deterministic serialization. Same content = same bytes = same hash.

4. Target Binding Lock bundles to specific platforms: arch-vendor-device-abi

5. Runtime Loader (CD-LOAD) JIT hash verification with fail-closed state machine. No execution without verification.

Read more: From Proofs to Code: Mathematical Transcription in C

Status

All modules complete — 7/7 test suites passing.

Module Description Status
Audit SHA-256 + domain-separated hashing ✅
Attest Merkle tree construction + attestation ✅
Bundle CBF v1 builder and reader ✅
Manifest JCS canonical JSON (RFC 8785) ✅
Target Platform tuple parse/encode/match ✅
Verify Offline bundle verification ✅
Loader Runtime JIT verification (CD-LOAD) ✅

Quick Start

Build

mkdir build && cd build
cmake ..
make
make test-all  # Run all 7 test suites

Expected Output

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

Create a Bundle

#include "cd_bundle.h"
#include "cd_manifest.h"
#include "cd_attest.h"

// Build manifest
cdm_builder_t mb;
cdm_builder_init(&mb);
cdm_set_mode(&mb, "deterministic");
cdm_set_created_at(&mb, 0);
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);

// Compute attestation
cd_attestation_t att;
cda_init(&att);
cda_compute_merkle(&att, &h_manifest, &h_weights, &h_certs, &h_inference, NULL);

cd_hash_t merkle_root;
cda_get_root(&att, &merkle_root);

// Build bundle
cd_builder_ctx_t ctx;
cd_builder_init(&ctx, output_file);
cd_builder_add_file(&ctx, "manifest.json", manifest_json, manifest_len, &h_manifest);
cd_builder_add_file(&ctx, "weights.bin", weights_data, weights_len, &h_weights);
cd_builder_finalize(&ctx, &merkle_root, false, NULL);

Load and Verify at Runtime

#include "cd_loader.h"

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
uint8_t *weights = allocate_weights_buffer(weights_size);
cdl_load_weights(&ctx, weights, weights_size);

// Load inference kernels with JIT hash verification
uint8_t *kernels = allocate_kernel_buffer(kernel_size);
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);
}

Architecture

Domain-Separated Hashing

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

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

Domain tags:

  • 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

CBF v1 Format

┌─────────────────────────────────────┐
│           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    │
└─────────────────────────────────────┘

CD-LOAD State Machine

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

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

Fail-Closed: Any verification failure immediately transitions to FAILED state, which cannot be exited.

Target Tuple

Format: arch-vendor-device-abi

Examples:

  • riscv64-tenstorrent-p150-lp64d
  • x86_64-generic-cpu-sysv
  • aarch64-nvidia-orin-lp64

Wildcards (generic) allow bundles to match multiple devices while maintaining architecture/ABI safety.

Integration Points

These interfaces are designed for third-party integration:

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 (certifiable-quant, certifiable-training, certifiable-data).

Documentation

  • CD-MATH-001.md — Mathematical foundations
  • CD-STRUCT-001.md — Data structure specifications
  • docs/requirements/ — SRS documents with full traceability:
    • 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

Related Projects

Project Description
certifiable-data Deterministic data pipeline
certifiable-training Deterministic training engine
certifiable-quant Deterministic quantization
certifiable-inference Deterministic inference engine

Together, these projects provide a complete deterministic ML pipeline for safety-critical systems:

certifiable-data → certifiable-training → certifiable-quant → certifiable-deploy → certifiable-inference

Why This Matters

Medical Devices

IEC 62304 Class C requires traceable, reproducible software. Model deployment must be verifiable.

Read more: IEC 62304 Class C: What Medical Device Software Actually Requires

Autonomous Vehicles

ISO 26262 ASIL-D demands provable behavior. Deployed models must match certified models.

Read more: ISO 26262 and ASIL-D: The Role of Determinism

Aerospace

DO-178C Level A requires complete requirements traceability. "We deployed the model" is not certifiable — cryptographic proof is required.

Read more: DO-178C Level A Certification: How Deterministic Execution Can Streamline Certification Effort

Compliance Support

This implementation is designed to support certification under:

  • DO-178C (Aerospace software)
  • IEC 62304 (Medical device software)
  • ISO 26262 (Automotive functional safety)
  • IEC 61508 (Industrial safety systems)

For compliance packages and certification assistance, contact below.

Deep Dives

Want to understand the engineering principles behind certifiable-deploy?

Cryptographic Verification:

Certification Standards:

Safety-Critical Foundations:

Production ML Architecture:

Contributing

We welcome contributions from systems engineers working in safety-critical domains. See CONTRIBUTING.md.

Important: All contributors must sign a Contributor License Agreement.

License

Dual Licensed:

  • Open Source: GNU General Public License v3.0 (GPLv3)
  • Commercial: Available for proprietary use in safety-critical systems

For commercial licensing and compliance documentation packages, contact below.

Patent Protection

This implementation is built on the Murray Deterministic Computing Platform (MDCP), protected by UK Patent GB2521625.0.

MDCP defines a deterministic computing architecture for safety-critical systems, providing:

  • Provable execution bounds
  • Resource-deterministic operation
  • Certification-ready patterns
  • Platform-independent behavior

Read more: MDCP vs. Conventional RTOS

For commercial licensing inquiries: william@fstopify.com

About

Built by SpeyTech in the Scottish Highlands.

30 years of UNIX infrastructure experience applied to deterministic computing for safety-critical systems.

Patent: UK GB2521625.0 - Murray Deterministic Computing Platform (MDCP)

Contact: William Murray
william@fstopify.com
speytech.com

More from SpeyTech:

Building deterministic AI systems for when lives depend on the answer.

Copyright © 2026 The Murray Family Innovation Trust. All rights reserved.

About

Deterministic model packaging and cryptographic attestation for safety-critical ML deployment

speytech.com/

Topics

machine-learning cryptography deployment c99 deployments fixed-point merkle-tree deterministic do-178c attestation safety-critical iec-62304 iso-26262

Resources

Readme

License

GPL-3.0 license

Contributing

Contributing
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases 1

Deterministic model packaging and cryptographic attestation for safety-critical ML deployment Latest
Jan 18, 2026

Packages

No packages published

Languages