# Determinism: why the outputs are byte-identical, and where that stops

The engine reproduces the release's arithmetic, not just its results. Each piece below is pinned for a measured
reason; `docs/TESTING.md` lists the checks that hold it in place, and `tests/test_matrix.py` runs the same 39 files
under changing conditions (each GPU alone and all of them together, 1 to 64 threads, 1 to 64 files at once, other arrival orders,
a warm repeat, a fresh process with every BLAS thread variable at 64): every record and RTTM identical in all of them.

## The networks (GPU)

- **Same code and weights.** The release's own model classes (DiariZen and its pyannote fork at commit 844f555), the
  bundle's weights, built the way `load_bundle` builds them.
- **Same numeric flags, set after the imports.** FP32, TF32 off, deterministic algorithms, cuDNN benchmark off,
  `CUBLAS_WORKSPACE_CONFIG=:4096:8`. Importing DiariZen switches TF32 on for the whole process, so the flags are
  set after it, as `load_bundle` does, and re-asserted before every network call.
- **Same kernels.** torch 2.1.1+cu121, its cuDNN 8.9.2, and cuBLAS 12.1.0.26 (`env/canonical.sh` loads it from a
  CUDA 12.1 installation; the cu121 Triton image carries the same files and searches them first).
- **Same batch shapes.** Segmentation: batches of 8, the remainder, the zero-padded last window alone (other sizes
  change bits). Voiceprints: the trunk once per window in batches of 8, pooling and the last layer at the release's
  rows (identical bits), the odd last window as the release runs it.
- **One CUDA stream per GPU.** Every GPU of a kind gives the same bits as the others, but two streams sharing one
  model on one GPU changed about 1 batch in 1,000. Locally there is one worker thread per GPU; on Triton one process
  per GPU.
- **Models never cross GPUs.** Moving several model copies from GPU to GPU in one process gave all-NaN weights on
  one GPU; copies go through host memory, and every Triton instance sees only its own GPU.
- **Checked before use.** Every backend runs every batch shape at start-up and compares with the release's own
  outputs (`assets/nn_golden.json`, written from `load_bundle`): identical bytes where the setup is reproduced;
  otherwise the outputs must stay within fixed near-identical bounds of `assets/nn_reference.npz` (or, in strict
  mode, the backend stops).

## Everything else (CPU, Rust)

- **numpy, scipy, pyannote and CPython reproduced operation by operation** (crate `diar-exact`): pairwise
  summation with numpy's 8 accumulators and 8,192-element buffers, numpy's BLAS dispatch (gemm / gemv / dot) with
  numpy's own OpenBLAS binary at one thread, glibc's `exp`/`log`, introsort tie order, scipy's centroid linkage and
  heap, cosine distance with its two-lane sum, rectangular assignment, pyannote's sliding-window arithmetic and
  aggregation, CPython's `round`, `sum`, string sort and `.3f` formatting.
- **Parallel only where each element's arithmetic is unchanged.** Distances by row, VBx products by blocks of
  result rows (each its own single-threaded OpenBLAS call; tested bitwise against the one-call product), VBx and
  aggregation by rows or output frames with every element's terms in the release's order.
- **The engine's OpenBLAS is private** (its own linker namespace) and pinned to one thread whatever the environment
  says.
- **Decoding** is libsndfile 1.2.2, the binary soundfile loads, called in soundfile's order; non-16 kHz audio is
  resampled by the release's own torchaudio resampler (copied unchanged into `anuvani_diar.nn.resample`) with 2
  threads.

## Where the guarantee stops

- Identical bytes need the same software (`env/canonical.sh`) on the same kind of GPU as the release's outputs were
  produced with. Another GPU model, or another PyTorch, CUDA or cuDNN version, picks other kernels whose last bits
  differ: the start-up check then measures the networks against the release's outputs and runs only if they stay
  within the near-identical bounds (maximum posterior difference 0.25, frame decisions at least 99% equal, voiceprint
  cosine at least 0.995), and says so; strict mode refuses to run instead.
- The CPU side is pinned to AVX2 code paths by `env/canonical.sh` (numpy, ATen and oneDNN features, and
  `OPENBLAS_CORETYPE=Zen`). The engine's private OpenBLAS no longer depends on that variable: it sets
  `OPENBLAS_CORETYPE=Zen` (and one thread) itself for its own load when the CPU reports AVX2 and FMA, checks that it
  runs core Zen, and refuses to run otherwise (`docs/WHEEL.md`). On an AVX2 CPU the pins change nothing; on a CPU
  with AVX-512, running without them could select other kernels in numpy, ATen and oneDNN.
- Inputs the release itself would treat differently (a different bundle, batch size or package versions) are
  outside the contract.