Compliance Banner

Compliance Toolkit

Automated compliance artifacts, deterministic builds with cryptographic proof, and regulatory checklists mapped to your framework. What PyTorch, JAX, and Mojo cannot offer.

What MIND provides

Deterministic Builds

Bit-identical output from identical source. SHA-256 verified at every stage: source, IR, binary.

Tamper-Evident Evidence Chains

Every compiled artifact carries a tamper-evident compile-time evidence chain (RFC 0016): determinism class, substrate, toolchain identity, and trace hash. Cryptographic signing has shipped and is opt-in (RFC 0016 Phase C). The target scheme is post-quantum: ML-DSA-87 (FIPS-204, lattice) and SLH-DSA-SHAKE-256s (FIPS-205, hash-based), both legs required to verify — two mathematically independent foundations, with a non-degradable verifier that fails closed rather than collapsing to a single leg. Ed25519 is deliberately excluded from that scheme; it survives only as a legacy interop tag and is not PQC-compliant. Signing is enabled only when you supply a key seed out-of-band; nothing is signed by default, and an unsigned artifact stays byte-identical. The post-quantum legs are compiled in via theevidence-mldsa and evidence-slhdsabuild features (off by default), and the verifier's trusted-signer allowlist is operator-supplied. Read this precisely: the signing capability ships, the release process does not yet use it. STARGA has not completed the operational last mile — no offline key ceremony, no published public key, no signed-reproduction CI gate — so published MIND releases are tamper-evident, not signed, and should not be evaluated as authenticated by a STARGA key. Signing today is a capability you operate with your own keys inside your own build pipeline; mindc verify --signer-pubkey pins a trusted-key allowlist and fails closed on an unknown signer. SLSA-format attestation export is in development.

SBOM Generation

Software Bill of Materials in SPDX and CycloneDX formats, with transitive dependencies and license classification. Toolkit in development.

Audit Log Exporter

Timestamped execution logs for regulatory traceability, shipping with the commercial runtime. Structured records of compilation, deployment, and inference events.

Audit trail in action

// Source: model.mind
@audit(level="full")
@provenance(slsa_level=3)
@sbom(format=["spdx-3.0", "cyclonedx-1.5"])

param weights: Tensor<f32, 784, 10>

fn forward(x: Tensor<f32, ?, 784>) -> Tensor<f32, ?, 10> {
    matmul(x, weights)  // Shape verified at compile time
}

// Build with full audit trail:
// $ mindc build model.mind --audit --provenance --sbom
//
// Generated artifacts:
//   model.bin          (compiled binary)
//   model.bin.sha256   (binary hash)
//   model.slsa.json    (SLSA v1.0 provenance)
//   model.spdx.json    (SPDX 3.0 SBOM)
//   model.cdx.json     (CycloneDX 1.5 SBOM)
//   model.audit.json   (execution audit log)

Toolkit preview: the audit / provenance / SBOM CLI surface shown above is in development. Shipping today: deterministic builds and the tamper-evident compile-time evidence chain (RFC 0016) embedded in every compiled artifact.

Regulatory framework checklists

For each framework, we show what MIND automatically satisfies, where it helps, and what your team still needs to provide.

FDA 510(k) / De Novo

IEC 62304, ISO 14971, ISO 13485

Auto-satisfied

  • Software verification (compile-time shape checks)
  • Configuration management (tamper-evident evidence chain, SHA-256)
  • Reproducible builds (deterministic execution)

MIND helps with

  • Cybersecurity (memory safety, supply chain)
  • Performance reporting (deterministic benchmarks)

You still need

  • Risk management process documentation
  • Clinical performance studies
  • Device labeling

EU AI Act

Regulation 2024/1689, Articles 9-17

Auto-satisfied

  • Record-keeping and logging (Article 12)
  • Build provenance and traceability

MIND helps with

  • Risk management system (Article 9)
  • Technical documentation (Article 11)
  • Transparency (Article 13)

You still need

  • Data governance (Article 10)
  • Human oversight mechanisms (Article 14)
  • Quality management system (Article 17)

ISO 26262

Parts 6, 8, 9, 11 (Functional Safety)

Auto-satisfied

  • Software unit design (compile-time guarantees)
  • Software unit verification (static analysis)

MIND helps with

  • Tool qualification evidence (Part 11)
  • Integration verification
  • Safety-critical runtime checks

You still need

  • ASIL classification and analysis (Part 9)
  • Software development plan (Part 6)
  • Hardware-software interface spec (Part 8)

Start a compliance pilot

Free 4-8 week pilot. Migrate one model, get full compliance artifacts, and see exactly what MIND automates for your regulatory framework.

Learn about the pilot