MIND Core v1 Cookbook

A collection of short, practical recipes demonstrating how to use Core v1 in real workflows.

Recipe 1 — Compile and emit the canonical artifact

fn main() -> f64 {
    let x: f64 = 2.0;
    let y: f64 = x * x + 1.0;
    return y;
}

--emit-ir is a lossy dataflow summary for reading; --emit-mic3 is the canonical, exhaustive binary artifact. Note that emission is selected by an --emit-*flag that names its own output path — there is no -o.

mindc scale.mind --verify-only          # type-check only
mindc scale.mind --emit-ir              # human-readable summary
mindc scale.mind --emit-mic3 scale.mic3 # canonical mic@3 binary

Recipe 2 — Autodiff of a loss function

Autodiff is feature-gated and entered through a single-output main. The flag pair is --autodiff --emit-grad-ir; a build without the feature fails loud (E4003) rather than skipping the request.

cargo run --features autodiff --bin mindc -- loss.mind --func main --autodiff --emit-grad-ir

Recipe 3 — MLIR lowering

Requires the mlir-lowering feature. MLIR text goes to stdout.

mindc scale.mind --func main --emit-mlir

Recipe 4 — GPU target: correct error handling

The open-source build ships no GPU backend. Asking for the GPU target is a structured failure, never a panic and never a silent fallback to CPU — and that explicit backend-selection error is itself part of the Core v1 GPU profile, so it is preserved across compatible releases.

mindc main.mind --target gpu
error[backend][E5001]: no backend available for target gpu

Recipe 4b — Emit and verify an evidence chain

mindc scale.mind --emit-evidence scale.ev
mindc verify scale.ev

A plain verify reports; add --require-strict-fp, --require-deterministic, or --require-signed to fail closed instead. mindc inspect scale.ev decodes the artifact and prints a structural summary alongside the canonical IR. See the determinism contract.

Recipe 5 — Host embedding via the runtime API

let rt = MindRuntime::new_cpu()?;
let inp = rt.allocate(&tensor_desc_f32(&[2]))?;
rt.write_tensor(inp, &[1.0, 3.0])?;

let out = rt.allocate(&tensor_desc_f32(&[1]))?;
rt.run_op("sum", &[inp], &[out])?;

let result = rt.read_tensor(out)?;

Output: 4.0.

Recipe 6 — Running the official conformance suite

CPU baseline:

mindc conformance --profile cpu

GPU profile:

mindc conformance --profile gpu

Recipe 7 — Using the pure-MIND standard library (RFC 0005)

std.vec, std.string, std.map, and std.io are bundled into mindc since v0.4.2 — a project that says use std.vecresolves with zero external file dependency. The std-surface feature is the shipped default (since v0.7.1); enable cross-module-imports to resolve cross-module use paths:

# cross-module-imports is the only extra gate needed; std-surface ships by default.
cargo run --features "cross-module-imports" --bin mindc -- demo.mind --emit-ir

A minimal demo.mind exercising std.vec:

use std.vec;

fn main() -> i64 {
    let v = vec_new();
    let v = vec_push(v, 10);
    let v = vec_push(v, 20);
    let v = vec_push(v, 30);

    let n = vec_len(v);          // 3
    let x = vec_get(v, 1);       // 20

    vec_free(v);
    return x;
}

Every operation returns the (possibly reallocated) Vechandle — there is no hidden mutation. Modules are resolved last-write-wins, so a user crate MAY define its own std.vec to shadow the bundled one.

See the per-module pages for the full API: std.vec, std.string, std.map, std.io. The seven host-interface core intrinsics they bottom out in (__mind_alloc, __mind_realloc, __mind_free, __mind_load_i64, __mind_store_i64, __mind_read, __mind_write) are ratified by mind-spec v1.0 (stdlib.md).

Beyond std — crypto & protocol primitives

The source tree also carries a pure-MIND cryptography and protocol primitive library: AES-128-GCM, ChaCha20-Poly1305, SHA-256, SHA-512/384, HKDF, X25519, SHA-3/SHAKE (FIPS 202), RSA-PSS, ECDSA-P256, ML-KEM-768 (FIPS 203), the X25519MLKEM768 hybrid key exchange, X.509 parsing and verification, the TLS 1.3 key schedule, record layer, Finished MAC and handshake crypto (verified by RFC 8448 replay), HPACK (RFC 7541), and HTTP/2 framing (RFC 9113). Every primitive is verified against RFC and NIST known-answer tests.

Honest scope: this is a verified primitive library, not a working TLS client or server — there is no socket-driven handshake state machine yet, certificate-chain path validation is not implemented, and HPACK is decode-only. The primitives are correctness-first, not speed-optimized.