🤖 machine learning

Kernel Contracts: A Specification Language for ML Kernel Correctness Across Heterogeneous Silicon

The paper proposes a formal specification language called "Kernel Contracts" to define, measure, and arbitrate discrepancies in machine learning kernel behavior across different hardware platforms by providing a standardized framework for identifying precision, ordering, and memory errors.

Original authors: Cooper Veit

Published 2026-04-27

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Cooper Veit

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a massive, high-tech skyscraper using thousands of different specialized robots. Some robots are experts at laying bricks, some at installing glass, and others at wiring electricity.

To get the building finished, you assume every robot follows the same basic rules of physics. But in the world of Artificial Intelligence (AI), these "robots" are actually tiny pieces of software called kernels, and the "physics" they follow is actually math.

The Problem: The "Silent Liar"

Here is the scary part: In AI, these math robots are "silent liars."

If a construction robot accidentally places a brick two inches to the left, you’ll see it immediately. But if an AI math robot makes a tiny, microscopic error in a calculation—say, it rounds a number slightly differently than it was supposed to—the building doesn't fall down right away. Instead, the skyscraper looks perfect on the outside, but deep inside the foundation, the math is slightly "off."

As you keep building higher and higher, those tiny errors stack up. Eventually, the whole building (your AI model) starts to lean, or the elevators stop working, or it behaves in ways no one can explain.

Currently, when an AI model fails, engineers spend weeks arguing: "Was it the NVIDIA robot's fault? Or the AMD robot? Did the math robot just get tired, or was it programmed incorrectly?" There is no "rulebook" to settle the argument.

The Solution: The "Contract"

This paper proposes a way to stop the arguing by giving every math robot a written contract before it ever starts working.

Think of it like a legal contract for a freelance contractor. Instead of just saying, "Hey, go build a wall," the contract says:

The Scope: "You are building a wall exactly 10 feet high."
The Precision: "You must use high-grade cement, not the cheap stuff."
The Tolerance: "If a brick is off by more than a hair, you must flag it. If it's off by a centimeter, you've broken the contract."
The Penalty (The Signature): "If you fail, we will know exactly how you failed (e.g., 'the wall is too wobbly' or 'the color is wrong')."

The Four Families of "Broken Promises"

The paper identifies four main ways these math robots "break" their contracts:

The Precision Cheat (Family A): The robot promises to use a high-powered calculator but secretly uses a cheap, basic one to save time. This makes the math "blurry."
The Order Chaos (Family B): In math, $2 + 3 + 4$ is the same as $4 + 3 + 2$ . But in high-speed AI math, the order in which you add numbers can change the tiny decimals at the end. This robot promises a consistent result but gives a different one every time you ask.
The Compiler Confusion (Family C): This is like a manager giving a robot a set of instructions, but the manager's translator accidentally changes "turn left" to "turn right." The robot does exactly what it was told, but the instruction itself was mutated.
The "Oops" Handling (Family D): What happens if the robot is asked to do something impossible, like "divide by zero"? Some robots scream for help (Raise an error), some pretend nothing happened (Silent failure), and some just guess. The contract forces them to declare exactly which one they will do.

Why does this matter?

As we build bigger and bigger AI (like ChatGPT or the next generation of super-intelligent models), we are using more and more different types of computer chips from different companies (NVIDIA, AMD, Intel, Apple).

Without these Kernel Contracts, we are building the future of intelligence on a foundation of "silent lies." This paper provides the blueprint for a "Quality Control Department" for AI, ensuring that no matter which chip you use, the math is honest, documented, and—most importantly—predictable.

Technical Summary: Kernel Contracts: A Specification Language for ML Kernel Correctness Across Heterogeneous Silicon

Author: Cooper Veit (Ashiba Research)
Date: April 2026

1. The Problem: The "Claim-Scope Gap"

In modern machine learning, ML kernels (low-level GPU/accelerator code) are expected to perform specific mathematical operations (e.g., MatMul, FlashAttention). However, these kernels often operate with implicit contracts. A vendor might claim a kernel "supports FP8," but they rarely specify the accumulator precision, softmax stabilization method, shape constraints, or error tolerances.

This lack of formal specification leads to the "claim-scope gap": a state where two different hardware implementations (e.g., NVIDIA vs. AMD vs. Huawei) can both be "correct" according to their own undocumented assumptions while producing numerically divergent results. This results in:

Silent Failures: Kernels that complete without error but produce mathematically incorrect tensors.
Numerical Divergence: Model-level accuracy loss caused by floating-point non-associativity or silent precision coercion.
Unresolvable Disputes: No formal artifact exists to arbitrate whether a numerical disagreement is a software bug, a hardware limitation, or a legitimate divergence within acceptable bounds.

2. Methodology: The Kernel Contract Framework

The paper proposes moving from implicit assertions to explicit, written contracts. The methodology is built on three pillars:

A. A Formal Specification Language
The author introduces a structured, eight-part language designed for ML engineers. A contract consists of:

Identifier: Unique ID (e.g., C-PRC-01).
Scope: The operation class (e.g., fused_attention).
Precondition: Constraints on inputs (precision, shape, value range).
Postcondition: The required relationship between output and a reference.
Tolerance: The permitted divergence (absolute, relative, or ULP).
Reference Oracle: The "ground truth" (e.g., a higher-precision FP64 implementation).
Measurement Protocol: A reproducible testing procedure.
Violation Signature: The empirical pattern that identifies the specific failure mode.

B. Taxonomy of Twelve Contract Classes
The paper categorizes silent failures into four families:

Precision Regimes (PRC): Issues like silent downcasting or catastrophic cancellation.
Ordering & Determinism (ORD): Non-determinism in reductions or communication overlaps.
Compiler-Induced (CMP): Numerical drift caused by operator fusion or autotuning.
Exceptional Values (EXC): Undocumented handling of NaNs, Infs, or out-of-bounds (OOB) memory access.

C. Three-State Calibration
To ensure a contract is actually testable, the author adapts a requirement that every test environment must include:

A Baseline (fails everything).
A "Bad" implementation (passes basic tests but violates the specific contract).
A "Good" implementation (conforms to the contract).

3. Key Contributions

Formal Language: A grammar for defining kernel correctness that is readable by engineers but structured enough for automation.
Taxonomy: A systematic classification of the most common ways ML kernels fail silently.
Case Study Mapping: The paper demonstrates that real-world incidents (e.g., Huawei's silent precision coercion, Sakana AI's "reward hacking" of benchmarks, and AMD's silent OOB acceptance) can be precisely mapped to specific contract violations.
Verification Architecture: A practical approach to testing, including a "batched" Freivalds algorithm implementation that allows for high-speed, low-overhead (sub-1%) probabilistic verification of MatMuls.

4. Results and Empirical Validation

The paper validates the framework through several technical demonstrations:

Verification Overhead: Using a batched Freivalds algorithm, the author shows that verification can be performed with <1% overhead for large matrices on NVIDIA H100 and AMD MI300X, making it viable for production.
Sensitivity Analysis: The framework can distinguish between "numerical noise" and "contract violations" by establishing a clear detection curve based on the magnitude of the error relative to the tolerance.
Cross-Silicon Baseline: The paper establishes that the "natural" divergence between different high-end GPUs (e.g., H100 vs. MI300X) is bounded by $O(n \cdot \epsilon)$ , providing a baseline for what a contract must tolerate to avoid being over-specified.

5. Significance and Industry Impact

The paper argues that kernel contracts are the missing link in the ML Silicon Certification ecosystem.

By providing a normative reference, the framework enables a transition from "trusting the vendor" to "verifying the conformance." The author suggests that this could lead to a certification model similar to ISASecure (for industrial control systems) or ISO 26262 (for automotive safety), where hyperscalers and enterprise users can purchase hardware based on audited, contract-compliant kernel suites. This is particularly critical as the industry moves toward massive-scale training where "Silent Data Corruption" (SDC) can invalidate weeks of expensive computation.