Tensor Cards

Where a Model Card would describe a whole checkpoint, a Tensor Card is the same idea at finer grain: structured provenance for one specific tensor - where it came from, what's been done to it, and what it's derived from.

What's already trackable, per tensor, today

Several confirmed pieces of Tensormorph's design already amount to per-tensor provenance, even without a unified "card" object pulling them together:

• Lob's commit pin (see Versions and Branches) - which commit a tensor's containing checkpoint was materialized from.
• A morph's recipe.json (see Model Morphing) - if a tensor is the output of a morph, the recipe that produced it.
• Quantization metadata (see Dtype and Quantization) - scale, zero-point, and granularity, wherever a tensor is quantized.
• Format-native metadata - whatever the source format itself carries (see Model Cards).

What a card would add

A Tensor Card would plausibly present these together as one readable summary attached to a specific tensor's Inspector panel entry, rather than requiring you to separately check the commit history, the recipe file, and the format metadata to reconstruct a tensor's story. That presentation layer isn't confirmed to exist yet - the underlying data it would draw from largely already does.

Related resources

• Model Cards - the whole-checkpoint counterpart to this page.
• Model Morphing - recipe.json, one of the confirmed provenance sources above.
• Scalar Inspector - where a tensor's confirmed metadata is visible today.