Earlier technical work. This page records research that can support the current Ashiba compute-buying practice. It is not the current offer. See current Ashiba work →

Ashiba Compute

Workload route-fit, compute evidence, and kernel correctness.

Numerical failures can waste expensive training time. A test must state its workload, tolerance, reference, and result before a buyer can use it to compare deployments.

Kernel Contracts (April 2026) presents one method for stating those limits. The paper is public research. It does not certify a provider or deployment.

Async Workload Test
One workload · current route vs one candidate route · one week

This earlier test compared one expensive async AI workload on its current route and one candidate route. The present Ashiba offer starts with the buyer's requirements and a live provider offer.

Research — April 2026
Kernel Contracts: A Specification Language for ML Kernel Correctness Across Heterogeneous Silicon

The compressible abstraction

Every kernel ships with an implicit contract about what it computes — numerical tolerance, determinism, shape limits, composition semantics. Until Kernel Contracts, those contracts were never written down. When two implementations disagreed, nothing in the software stack arbitrated which was right.

The contract object closes that gap. Eight parts: identifier, scope, precondition, postcondition, tolerance, reference oracle, measurement protocol, violation signature. Twelve contract classes group under three physically-grounded failure primitives: path dependence, domain violation, resource contention. The taxonomy is small enough for a kernel author to internalize in an afternoon and rich enough to express the failure modes documented across forty years of silicon-test engineering.

That is the compressible abstraction Ashiba Compute contributes to the substrate problem: a formal artifact silicon vendors and frontier training operators can share with each other as evidence, rather than re-arguing every numerical disagreement from first principles.

The reference verifier

ashiba-verify is an experimental reference implementation of selected checks from the paper. Its local benchmark results depend on the device, matrix size, precision, backend, warm-up, and timing method. Ashiba does not claim one general overhead percentage.

Technical novelty did not delay this work. The algorithm is forty-six years old. The work ported it from theoretical computer science to production ML kernels and defined the contract semantics.

The public source release is under review. The paper remains the stable public reference.

Programs and adjacent work

Methodology
Eight-part contract object · three failure primitives · twelve contract classes · derivation from silicon-test lineage

The detailed framework covers contract anatomy, a failure taxonomy, a test protocol, and prior work. Read the methodology →

Current use
Technical evidence for a compute-buying decision

Ashiba can use bounded workload tests and compute evidence when they help a buyer compare or accept an offered deployment. These methods are supporting tools. See current Ashiba work →

Claim boundary
Test evidence, not certification

Kernel Contracts can define a bounded measurement and result. It does not certify a provider, deployment, chip, or workload unless an authorized certification program states that it does.

Earlier research context
Preserved as technical history

Earlier Ashiba programs explored verification across heterogeneous compute. They remain public as research history. They are not separate current offers.

Public tools

scanprobe v0 alpha  ·  tiny read-only first-pass GPU evidence scan
v0 · alpha · NVIDIA local evidence only · no daemon · no telemetry · no mutation

A small helper for the first few minutes of GPU troubleshooting. It gathers limited local evidence. It does not replace DCGM, confirm hardware health, or approve a rerun. Read the evidence limits →

Resources