What exactly stays the same.
A backend can change only after graph, numbers, order, bounds, and failure behavior are already explicit. The result is exact authoritative identity—not numerical proximity.
One canonical graph
A typed Flow lowers to one canonical Kernel graph and Program. Backend selection is a physical execution choice below that identity; it does not produce a second algorithm or graph authority.
Numbers are part of admission
Public Compute scalar values are signed and unsigned 32- and 64-bit integers plus admitted 32- and 64-bit Fixed values. Width, rounding, overflow, and quantization are explicit.
The broader evidence model can describe strict floating-point policy, but the current public Compute language does not admit floating-point inputs. Diagnostic and presentation floating point cannot feed authoritative state.
Order is observable state
Scheduler-visible work, reductions, conflicting writes, publication, and replay observation are assigned deterministic identity and order. A physical optimization may change placement or submission shape, but not canonical ordering or output.
- Batching does not reorder jobs.
- Fusion does not reassociate a reduction.
- Resident execution does not retain hidden result state.
- Logical bounds and capacities fail instead of silently clamping.
An explicit backend or a typed failure
If the selected target is unsupported or unavailable, execution reports a typed failure. It does not retry on CPU, select another device, or reinterpret the Flow under a weaker contract.
requested backend
├─ admitted + available → execute canonical graph
└─ unavailable → typed Unsupported / Unavailable
(no silent fallback)Proof surfaces, not a universal proof claim
Installed contracts compare graph fingerprint and exact raw output across available backends. A checked 32/64-bit Fixed witness exercises 1,536 nodes across the current CPU, Metal, and Vulkan paths. This is strong executable evidence, not a formal proof of every possible workload.
State hashes, replay checkpoints, telemetry, and release provenance extend that evidence to application and artifact boundaries.
Where the guarantee begins
Host observations become deterministic after admission into the canonical input stream. runD does not make wall-clock timing, native ready-list arrival order, arbitrary host code, or unconstrained floating point deterministic.
| Inside the guarantee | Outside until admitted |
|---|---|
| Canonical Flow graph and fingerprint | Arbitrary runtime C++ callbacks |
| Admitted integer/Fixed operations and policy | Unconstrained floating point |
| Defined reduction, conflict, publication, and replay order | Wall-clock timing and native ready-list arrival |
| Exact output bytes and typed failure | Application inputs that were never canonically admitted |
Continue to Numerics to choose a value surface, or inspect the optional engineering numeric policy source ↗.