Element Specs

September 11, 2026 ยท View on GitHub

Helpers for building element specs and for checking data against them.

Two descriptions of the same data are kept apart:

HelperDescribesA host float64 array with x64 off
array_to_spec, array_to_spec_strip_leadingThe data exactly as given, from array metadata, with no copyfloat64
device_specThe same data once converted to JAX arraysfloat32

A source declares the records its batches carry. MemorySource converts its stored data to JAX arrays in get_batch_at, so it declares device_spec of its storage. A streaming source that emits host arrays declares them as they are.

Checking batches

import jax
import jax.numpy as jnp
import numpy as np

from datarax.core.spec import SpecMismatchError, validate_batch

element_spec = {"image": jax.ShapeDtypeStruct((28, 28), jnp.float32)}
batch = {"image": np.zeros((32, 28, 28), dtype=np.float64)}

try:
    validate_batch(batch, element_spec, batch_size=32)
except SpecMismatchError as error:
    print(error.problems)  # ("['image']: dtype float64 != expected float32",)

validate_batch checks tree structure, per-element shapes, dtypes and one shared record count, and reports every problem with its field path. With batch_size, a short final batch passes. It reads only shapes and dtypes, so it never copies or casts data, and it can run inside jax.jit while tracing without adding anything to the compiled graph.

Pipeline runs this check on every batch a streaming source emits, before the batch reaches the DAG. When a pass starts it also calls validate_device_dtypes on the declared spec, so a declared float64 field is refused while jax_enable_x64 is off instead of being narrowed silently. The pipeline reads element_spec() once per source and x64 setting, because a streaming source may open its backend to answer it, so a source's declaration must not change after construction.

See Also


::: datarax.core.spec