Most inference systems log which GPU or accelerator performed a computation. They record it in an observability dashboard, maybe a structured log line, sometimes a billing metadata field. The information exists, but it exists as operational telemetry—useful for capacity planning, irrelevant for verification.
An equipment profile is something different. It is a structured record of the hardware and software environment that performed the inference, bound into the cryptographic receipt alongside the model configuration, routing decisions, and input-output relationship. It is not telemetry that you happen to collect. It is evidence that you commit to.
What an Equipment Profile Contains
At minimum, an equipment profile identifies the processor, the inference framework version, and any hardware-specific accelerator revisions that affect computation. On Apple Silicon, this means the chip identifier (M3, M3 Pro, M3 Max, M3 Ultra, M4, and so on), the Apple Neural Engine revision, and the MLX framework version. On NVIDIA hardware, it would mean the GPU model, driver version, and CUDA toolkit version.
These identifiers are not decorative. Each one constrains the set of computational behaviors the hardware can produce. A matrix multiplication on an M3 Max may produce a different floating-point result than the same operation on an M4 Pro, even with identical inputs and identical software, because the underlying hardware units have different microarchitectures, different rounding behaviors, and different levels of fusion for fused multiply-add operations. The MLX framework version determines which kernel implementations are available and which algorithmic strategies are used for operations like attention and layer normalization.
Recording these identifiers in the receipt makes the hardware environment a verifiable fact rather than an assumed constant.
Why Hardware Identity Matters for Reproducibility
If you claim that an inference run is reproducible, you implicitly claim that running the same model on the same input with the same configuration will produce the same output. But "the same configuration" includes the hardware. Two machines with different chips, running identical software and identical models, may produce slightly different outputs due to floating-point implementation differences at the hardware level.
This is not a defect. It is an inherent property of floating-point computation on different microarchitectures, and pretending it does not exist serves no one. The honest approach is to document the hardware environment in the receipt so that a verifier knows what "reproducible" means in context: reproducible on this specific hardware configuration, or reproducible across hardware configurations with variance bounded by the system's determinism policy.
An equipment profile makes this distinction explicit. A receipt produced on an M3 Ultra with MLX 0.23.1 is reproducible on another M3 Ultra with MLX 0.23.1. Whether it is reproducible on an M4 Pro with MLX 0.24.0 depends on whether the computation crosses the Q15 commit boundary identically on both platforms, which is a question the receipt's determinism policy and routing digest can answer. But the question can only be asked if the hardware identifiers are present.
The Verification Use Case
Consider a regulated deployment where multiple inference nodes process documents across a fleet of machines. An auditor reviews a specific inference result and wants to verify it. Without an equipment profile, the auditor must determine which machine produced the result (from operational logs), hope the machine is still available (it may have been redeployed or decommissioned), and replay the inference on that specific machine to check the result.
With an equipment profile in the receipt, the auditor knows exactly which hardware environment produced the result. If the organization maintains multiple machines with the same configuration, any of them can serve as a verification target. If the hardware has changed, the auditor knows this and can account for potential floating-point variation in their assessment.
This matters for fleet management in ways that are easy to overlook. Organizations that operate inference hardware across multiple sites, multiple hardware generations, or rolling upgrade cycles need to know which hardware produced which results. When a new chip revision is deployed and inference outputs shift slightly, the equipment profiles in the receipts identify exactly which results were produced on the old hardware and which on the new, without requiring any additional logging infrastructure.
Framework Version as a First-Class Identifier
The inference framework version deserves special attention because it changes more frequently than hardware and its effects are less predictable. A framework update may introduce new kernel implementations, change default algorithmic strategies, modify numerical precision handling, or fix bugs that previously produced incorrect but consistent results.
When a framework update changes inference behavior, the equipment profile in the receipt pinpoints the change. Receipts produced before and after the update carry different framework version identifiers, making it straightforward to attribute behavioral changes to the correct cause. Without this identifier, attributing a change in inference behavior to a framework update versus a model update versus a configuration change requires forensic analysis of deployment logs and release timelines.
For organizations operating in environments where software updates require change control processes—and this includes most regulated industries—the framework version in the equipment profile provides the documentation that change control boards require. The receipt proves not just that the inference was performed correctly, but that it was performed with an approved software version.
The Digest
The equipment profile is hashed into a single digest that becomes one component of the overall receipt digest. This means that any change to any hardware or software identifier in the profile produces a different receipt, even if everything else—model, input, output, routing—is identical. The receipt is a commitment to the entire execution environment, not just the logical computation.
This compositional hashing has a useful property: you can verify the equipment profile independently of the other receipt components. A hardware auditor who cares about whether approved equipment was used does not need to understand the model configuration or the routing decisions. They verify the equipment profile digest against a list of approved configurations. A model auditor who cares about the routing decisions does not need to understand the hardware. Each component of the receipt can be verified by the party with the relevant expertise, without requiring every verifier to understand every component.