When a lab publishes a trained model or a curated training dataset as a research output, two separate infrastructure questions come up immediately: how do you give it a persistent identifier someone can cite, and how do you document what it actually is so the identifier resolves to something usable rather than a bare file dump? This is distinct from whether the training data was lawfully obtained or how copyright/text-and-data-mining exceptions apply — see CASRAI’s AI training data provenance, copyright, and TDM exceptions guide for that question. This guide covers the identifier and citation mechanics: minting a DOI for a model or dataset, what a model card needs to contain to make that DOI meaningful, and why research administration should treat both as first-class metadata, not an afterthought.
Why a model or dataset needs a persistent identifier at all
A trained model or a training dataset is a research output in the same sense a journal article or a repository-hosted dataset is: something other researchers need to find, cite, verify, and build on. CASRAI’s Dictionary already treats both as distinct output types — see Model (as output) and Dataset (as output) — precisely because a URL to a GitHub repo or a Hugging Face page is not a stable citation target. Repos get renamed, moved, or taken down; a persistent identifier (PID) is a commitment that the reference will keep resolving, and that the object it resolves to is versioned rather than silently mutable.
This matters more for AI outputs than for most other research outputs for a specific reason: models are frequently updated in place. A provider can retrain, fine-tune, or quantize a model and publish it under the same nominal name, so “the model I used” can mean different underlying weights depending on when you ran it. CASRAI’s Model versioning term covers the reproducibility problem this creates directly. A PID system that mints a new identifier per version, rather than one identifier for a moving target, is the actual fix — not a nice-to-have.
How a DOI actually gets minted for a model or dataset
DataCite — the DOI Registration Agency that already serves research data, software, and other non-article outputs (see CASRAI’s DataCite DOI term) — includes Model as one of its controlled resourceTypeGeneral values in the current DataCite Metadata Schema (4.7, released March 3, 2026), defined as “an abstract, conceptual, graphical, mathematical or visualization model that represents empirical objects, phenomena, or physical processes.” That definition predates the current wave of large ML models and wasn’t written with them specifically in mind, but it applies cleanly: a trained model is exactly this kind of representation, and datasets already have their own dedicated Dataset type in the same schema. There is no separate, AI-specific DOI mechanism required — the existing DataCite infrastructure already accommodates both.
The most concrete real-world implementation of this is Hugging Face Hub’s DOI feature, which is worth walking through because it makes the abstract minting process tangible. From a model or dataset’s settings page, a maintainer can generate a DOI directly; doing so registers metadata (title, author list, version, creation date) with DataCite, Hugging Face’s registration partner, and a citable identifier and tag are added to the repository. Two operational details carry directly over to any DataCite-backed PID workflow, not just Hugging Face’s implementation:
- Versioning is identifier-level, not metadata-level. When the underlying model or dataset changes, a new DOI is generated for the new revision rather than the existing DOI being edited in place; the previous DOI stays resolvable but is marked as superseded. This is the practical answer to the model-versioning reproducibility problem above.
- A DOI is a persistence commitment. Once assigned, the object it identifies is expected to keep resolving — Hugging Face specifically restricts deleting, renaming, or changing the visibility of a DOI-assigned repository without going through a support request. The same principle applies generally: don’t mint a PID for something you might quietly withdraw.
Institutional or lab-run repositories that already mint DataCite DOIs for datasets (Dryad, Harvard Dataverse, and institutional repositories generally) can register a model or dataset the same way they register any other output — by supplying resourceTypeGeneral: Model or Dataset and the standard mandatory DataCite properties (creator, title, publisher, publication year, resource type). See CASRAI’s How to Cite a Dataset guide for the citation-formatting side of this once the DOI exists, and the DataCite metadata schema term for the underlying property list.
Model cards: the documentation a DOI alone doesn’t provide
A DOI gets you a stable pointer and the bibliographic minimum (who, what, when, where). It does not, on its own, tell a downstream user what the model was trained on, how it performs across different populations or conditions, or what it should not be used for. That documentation layer is the model card — a short, structured document, introduced by Mitchell et al. in 2019 specifically to close the information gap between the people who build a model and the people who reuse it downstream, covering intended use, training data, evaluation methodology, and performance broken out across relevant sub-groups, plus known limitations. CASRAI’s Dictionary entry for the term has the full operational definition and worked examples; this guide doesn’t restate it, only the citation-and-identifier implication of it.
The practical convention that has emerged since 2019 is the Hugging Face Hub README-based model card format, which functions as the de facto standard for the large majority of publicly hosted open-source models — a model page’s README is its model card, rendered directly on the page. For datasets, the equivalent documentation practice is the “datasheet for datasets” (see CASRAI’s Datasheet for datasets term), and increasingly, machine-readable dataset metadata via Croissant — an open metadata format for ML-ready datasets, developed under MLCommons and extending schema.org vocabulary, now used to describe over 700,000 datasets across Hugging Face, Kaggle, and OpenML. Croissant 1.1 (announced February 2026) added machine-actionable provenance tracking and structured usage-policy fields, moving the format closer to something a CRIS or repository can ingest programmatically rather than just display to a human reader.
The operational point for research administration: a model card or datasheet is what a DOI’s metadata record should link to or embed — the DOI is the stable citation anchor, the card is the substance a citation is standing in for. A DOI with no accompanying documentation is citable but not really reusable; a well-documented model with no PID is reusable but not reliably citable or trackable. Both halves are needed, and neither is a substitute for the other.
Recording model and dataset identity in CRIS and institutional metadata
Once a model or dataset has a DOI, the identifier-crosswalk logic CASRAI already documents for other research outputs applies unchanged: a current research information system (CRIS) records the output alongside the researchers (via ORCID iD), their institution (via ROR), and the funded project, using the CERIF data model’s extensible research output entity — the same entity type used for articles and datasets, not a new category. See CASRAI’s Persistent Identifiers & Research Information Systems pillar for the full crosswalk model. Practically, this means a model or dataset DOI should be entered into the institutional CRIS the same way any other output DOI is: linked to the producing researchers’ ORCID records and the funding project record, not left to live only on a third-party hosting platform’s own page.
This also connects to authorship and credit conventions research administrators already manage. Where a model or dataset has multiple contributors with different roles (data collection, training, evaluation, documentation), the same CRediT-style contribution logic used for articles applies — see CASRAI’s CRediT taxonomy overview — and the citable author list on a model’s DOI record should reflect that division of labor rather than defaulting to whoever happened to click “generate DOI.”
Why this matters for research administration specifically
Three concrete administrative consequences follow from treating models and datasets as properly identified, documented outputs rather than informal artifacts:
- Provenance and reproducibility. A versioned DOI plus a model card is what makes “which model did this paper actually use” an answerable question months or years later, even if the hosting platform’s “latest” tag has since moved on to a different version.
- Research credit and reporting. A model or dataset with its own DOI can be tracked as a distinct output in institutional reporting, grant final reports, and researcher profiles (ORCID works, CRIS output records) — the same credit infrastructure that already exists for datasets and software, applied without modification to AI outputs, rather than a new bespoke tracking mechanism.
- Regulatory documentation overlap. Where an institution or research group is itself a provider of a general-purpose AI model under the EU AI Act, Article 53 requires technical documentation to a specific template (Annex XI) — general description, intended tasks, architecture, training process. That obligation is separate from, and stricter than, a voluntary model card, but a well-maintained model card is a genuine head start toward it rather than duplicate work. See CASRAI’s EU AI Act guide for who this actually applies to — most individual research groups fall under the Article 2(6) scientific research exemption and won’t need Annex XI documentation, but the model-card habit is worth keeping regardless.
None of this substitutes for the legal/provenance question of whether the training data was lawfully used in the first place, which is the separate, dedicated topic of CASRAI’s AI training data provenance, copyright, and TDM exceptions guide. The two are complementary: that guide is about what you were allowed to train on and how to document the chain of rights; this one is about how to make the resulting model or dataset findable, versioned, citable, and properly credited once it exists.
Frequently asked questions
Do I need a DOI for every model checkpoint I produce during training?
No — a DOI is a citation and persistence commitment, not a build artifact. Mint one for a release you intend others to find, cite, and reuse (a public model release, a dataset release accompanying a publication), not for every intermediate checkpoint saved during training. CASRAI’s Model checkpoint term distinguishes intermediate checkpoints from citable releases.
Can I cite a model that never had a DOI assigned, only a repository URL?
Yes, but it’s a weaker citation — a bare URL has no persistence guarantee and no fixed version unless the hosting platform provides its own commit-hash or tag mechanism. If the model is one you or a collaborator control, minting a DOI retroactively (most DataCite-backed platforms support this) is worth doing before the citation appears in a publication.
Does a model card need to follow a single standardized template?
No single template is mandatory. Mitchell et al.’s 2019 proposal established the core sections (intended use, training data, evaluation, limitations), and the Hugging Face Hub README format is the most widely adopted practical convention, but institutions and platforms vary in exact structure. What matters operationally is that the sections Mitchell et al. specified are present and the card is linked from the DOI’s metadata record, not that it matches a specific layout byte-for-byte.
Is Croissant the same thing as a model card?
No — Croissant is a machine-readable metadata format for describing a dataset’s structure and provenance (built for programmatic ingestion by ML tooling), while a model card or datasheet is a human-readable documentation practice. They’re complementary: a dataset can have both a Croissant metadata file and a datasheet-style narrative description, serving different consumers of the same underlying facts.
Related CASRAI resources
- AI Training Data Provenance, Copyright, and TDM Exceptions for Research — the legal/rights side of training data, distinct from the identifier/citation mechanics covered here
- How to Cite a Dataset: A Practical Guide with Real Examples
- EU AI Act: Obligations and Exemptions for Research Organizations
- Persistent Identifiers & Research Information Systems
- Model card · Datasheet for datasets · DataCite DOI · Model versioning
