Numerical Oracle

The numerical oracle is the gatekeeper for all kernel admission in Tribunus Compute. Every kernel — whether handwritten in Metal Shading Language, generated by Triton, or lowered from a oneDNN primitive descriptor — must pass through the oracle before it can be deployed. The oracle enforces strict per-element accuracy thresholds against a golden reference, and rejects any candidate that fails to meet them.

The 4-Tier Oracle

The oracle establishes ground truth through a fallback hierarchy of four tiers, tested in descending order of priority:

1. Apple Silicon FP32 — highest-priority reference. Apple Silicon’s IEEE 754-compliant FP32 pipeline produces deterministic, correctly-rounded results for every operation.
2. CUDA FP32 — used when Apple Silicon hardware is unavailable or the operation is NVIDIA-specific (e.g., CUDA tensor core operations with no Metal equivalent).
3. Vulkan FP32 — portable fallback for operations that run on Vulkan-capable hardware. Conformance-tested against the Khronos FP32 specification.
4. Theoretical bound — the computed result that an infinitely-precision arithmetic unit would produce, rounded to FP32. Used only when hardware precision is insufficient (e.g., denormal flushing underflows).

The highest available tier certifies pass or fail. If Apple Silicon FP32 is available, it is authoritative. If only Vulkan hardware is present, the oracle falls back to that tier, and the admission record notes the tier used.

Per-Op Tolerance Matrix

Each operation type has a published tolerance in the governance specification. Tolerances are measured in Units in the Last Place (ULP) relative to the golden reference:

Operation	Max ULP	Rationale
matmul	1 ULP	FMA accumulation must match reference to the last bit
softmax	2 ULP	Exponent summation may round differently across backends
layer_norm	1 ULP	Reduce-add chain must be reproducible
rms_norm	1 ULP	Same constraint as layer_norm
silu/gelu	2 ULP	Piecewise polynomial approximation across backends
add/concat	0 ULP	Bit-exact identity required

The tolerance matrix is published in the governance spec and audited in CI. Any backend whose kernel exceeds tolerance is rejected, even if it would compile and run.

Autotuning Cache

The oracle’s results — both accuracy and performance — are cached by a 6-tier composite key:

backend x op x dtype x shape x batch x quant

Each tier of the key constrains the expected behavior: a change in backend (Metal to CUDA), operation type, data type, tensor shape, batch size, or quantization scheme produces a different cache entry. A cache hit means the candidate’s behavior was previously certified for the exact same parameters. A cache miss triggers full re-evaluation: compile the candidate, run it against the oracle, measure performance, and record the result.

The cache is stored alongside the compute image and distributed to every deployment target. This means that if a kernel combination was certified on one machine, every other machine with the same backend x op x dtype x shape x batch x quant key inherits the certification without re-running the oracle. The cache-key check (one of the six admission gates) validates that the deployment’s parameters match the cache entry before trusting it.