Inside Core: 2,900+ operations across 12 backends
What an operation count tells you
Matrix multiplication sounds like a single task. Its implementation depends on what the values mean, how they are stored, how partial results are accumulated and which hardware executes the work. A packed binary matrix and a floating-point matrix can share an abstract operation while requiring different numerical rules and different code.
Core is Dweve's compute foundation for training and inference. Its public catalogue covers hundreds of thousands of hand-tuned kernels across 2,900+ operations in 76 categories, 25 numeric formats and 12 backends. Those figures describe different parts of the system. An operation names the calculation. A numeric format defines the representation. A backend identifies an execution target. A kernel implements a particular combination of choices.
Understanding that distinction matters more than treating the catalogue as one large feature total. A developer needs to know whether the required combination exists and what contract it follows.
The calculation and its representation belong together
Consider a reduction: take a collection of values and combine them into a result. The word “sum” leaves several questions unanswered. Are the inputs signed integers, fixed-point values or floating-point values? What representation holds the accumulated result? What happens when that representation cannot hold the next value?
Core keeps these choices attached to the operation. Its execution contract includes the datatype, width, packing, accumulator, backend, instruction set, dispatch policy and determinism mode. Changing one of these can change the meaning of the calculation, even when the operation has the same name.
The 25 numeric formats include binary, ternary, integer, fixed-point, adaptive and floating-point families. A family name is the starting point for describing the arithmetic. Width, signedness, scale and storage layout still matter. The catalogue should therefore be read as a collection of supported combinations, rather than a promise that every operation exists in every conceivable format on every target.
This is also why an interchange format cannot settle every execution question. ONNX describes a computation graph with typed inputs, outputs and operators. That gives systems a shared model description; the runtime still has to implement those operators. The ONNX concepts documentation explains that distinction between graph representation and execution.
12 backends, explicit execution choices
Core's 12 backends span scalar execution, CPU instruction sets and GPU and portable targets. The public target set includes Scalar, SSE2, AVX2, AVX-512, NEON, SVE2, CUDA, ROCm, Metal, Vulkan, WebGPU and WASM. These names describe execution paths within Core, rather than separate versions of a model.
Dispatch selects a supported implementation for the operation and its execution contract on the current host. The selected path is recorded with its execution cell, host and reason. A run can therefore be inspected through the choices it actually made.
Portability still has boundaries. WebAssembly's documentation, for example, distinguishes a portable binary format from the APIs supplied by a host environment. Browser execution and execution outside the browser can expose different interfaces. WebAssembly's portability documentation is useful context for that distinction. A backend label alone does not explain an application's operating environment.
Where Core sits in Dweve
The primitives library is used by Core for foundational operations. Core brings those foundations into the compute system. Loom is built on Core and uses the solvers library for its reasoning work. These relationships give each part a clear responsibility: primitives provide basic operations, Core executes computation, and Loom builds reasoning on that foundation.
Dweve is the service. Fabric is its API and portal, through which people and applications access the service. Fabric does not replace Core's compute role or Loom's reasoning role. The interface and the systems behind it serve different purposes.
Start with the execution you need
When assessing a compute system, start with a concrete calculation and the representation it requires. Then ask which backend will execute it, which accumulator and packing rules apply, and what replay contract is declared. Those questions turn a catalogue into something a team can use.
Core's public figures describe the breadth of that catalogue. The execution contract explains how to read it. Both belong in the same conversation: what work the system covers, and what a particular implementation means when you use it.