Model Cards
What's confirmed today
Every checkpoint format Tensormorph reads carries some baseline, format-native metadata - ONNX's doc_string/producer_name/model_version/metadata_props is the clearest confirmed example, and safetensors' optional __metadata__ block is another. Tensormorph reads whatever's present into a model's provenance fields, but treats none of it as required - shape, dtype, and byte offsets are the only fields any format guarantees.
What a fuller card would add
A model card, in the sense Hugging Face and similar hubs use the term, is a much richer structured-plus-freeform document: intended use, training data description, evaluation results, license, and so on - attached to a model rather than embedded inside the checkpoint file itself. Tensormorph doesn't currently define this as a first-class object; if you need this level of documentation for a model today, the checkpoint's originating source (a Hugging Face Hub repository, for instance - see Hugging Face Models) is the confirmed place it lives.
The likely relationship to Tensor Cards
Where a model card would describe a whole checkpoint, a Tensor Card would describe a single tensor's provenance - which morph produced it, its quantization scheme, its lineage. The two are complementary in concept (whole-model narrative vs. per-tensor provenance) even though neither is a finalized Tensormorph feature yet.
Related resources
- Tensor Cards - the finer-grained, per-tensor counterpart to this page.
- ONNX and Safetensors - the confirmed minimal metadata layer today.
- Hugging Face Models - where a full model card already exists today, outside Tensormorph.