input_spec

Every model card carries an input_spec: the exact description of what the model needs its observations to be. It is served with the model and enforced on every submission, and a field that differs between your input and the spec is refused with input_spec_mismatch, naming the field.

Field	Always present	Shape
encoder	yes	object with gate, hf_repo, license, revision
patch_um	yes	number
resize_px	yes	integer
mean	yes	array of number
std	yes	array of number
pooling	yes	one of cls, mean_patch_tokens, cls_plus_mean, token_grid
dim	yes	integer
dtype	yes	one of float16, float32, bfloat16
coord_frame	yes	one of px_col_px_row_fullres
qc	yes	object with blur_laplacian_var, foreground_ratio, hsv_tissue_ratio

Read it, do not guess it

The spec exists because the failure it prevents is silent. A model trained on tiles of one physical size, normalised one way, will happily consume tiles of another physical size normalised another way and return numbers with the same shape and the same apparent confidence. Nothing about the output says it was computed from an input the model has never seen.

So the fields are not advisory:

• patch_um is the physical edge of a patch in micrometres at the slide's native resolution — not a pixel count. Pixels are a consequence of it and of your slide's own resolution.
• resize_px is the pixel size the patch is resampled to before the encoder sees it.
• mean and std are the channel normalisation. They are part of the model, not a convention.
• pooling is how per-patch tokens become the vector the model reads. A vector pooled a different way is a different vector.
• encoder pins the encoder, its revision, its licence and whether access to it is gated. Two revisions of one encoder do not produce interchangeable embeddings.
• dim and dtype are the shape and precision of a row.
• coord_frame says which coordinate frame the positions are in, so a prediction can be laid back over the tissue.
• qc are the quality floors, so the tiles you keep are the tiles the model was trained to see.

If you submit embeddings

Then every field above is yours to satisfy, and the check is quantitative: the calibration vector in your archive is compared against the reference for that encoder and revision. This is the one place where "I used DINOv2" is not enough information — which revision, at which pooling, at which patch size, normalised how.

If you submit patches

Then the service computes the representation and most of the spec is satisfied for you. Two fields still are not: patch_um, because it depends on the resolution you cut at, and qc, because you chose which tiles to keep. The package reads both from the card so that neither has to be re-typed.