In SPDX 3.0.1, an AIPackage record must have eight fields: creationInfo, downloadLocation, name, packageVersion, primaryPurpose, releaseTime, spdxId and suppliedBy. The AI profile also expects one declared license and one concluded license relationship. Everything else, such as training and safety notes, is optional.
What an AIPackage is
SPDX 3.0 added profiles, and the AI profile is for describing AI applications and trained models. Its main class, AIPackage, extends the ordinary software Package class. The spec describes it as specifying an AI package and its associated information. Because it inherits from Package, it carries the usual package fields, and then adds AI specific ones.
The version here is the 3.0.1 specification page. If you target a different release, check the field list again.
The required fields
The cardinality tables mark these as required, with a minimum count of one:
| Field | What to put in it |
|---|---|
| spdxId | A unique identifier for this element in your document |
| name | The model name as a user would search for it |
| packageVersion | A version or a full commit hash |
| downloadLocation | Where the exact artifact can be fetched |
| primaryPurpose | What the package is for |
| suppliedBy | The agent that supplies it |
| releaseTime | When the package was released |
| creationInfo | Who created this SPDX element, and when |
The profile page also says every AIPackage must have exactly one concluded license and one declared license relationship, each pointing to a license value. If you do not know, say so with a value that expresses unknown rather than leaving it out.
Optional AI fields worth adding
The spec lists many optional properties. For a security and procurement reader, these carry the most weight:
- informationAboutTraining: how the model was trained.
- modelDataPreprocessing: what happened to the data first.
- limitation: known constraints.
- safetyRiskAssessment: the assessed risk level.
- domain and primaryPurpose: where it is meant to be used.
- typeOfModel: the kind of model.
- useSensitivePersonalInformation: whether sensitive personal data is involved.
- energyConsumption and the related training and inference fields.
- verifiedUsing: integrity methods used to verify the package, such as a digest.
- standardCompliance: standards the package claims to meet.
I read these names from the spec's property list. The page gives types and cardinality but not full definitions, so read the definitions in the spec before you depend on them.
How to start
- Create the eight required fields for each model you run.
- Put the full commit hash in packageVersion and the exact URL in downloadLocation.
- Add a digest through verifiedUsing.
- Add the two license relationships.
- Add training and limitation notes when the model card supplies them, and mark them as publisher stated.
A record that is honest about gaps beats a complete looking record built from guesses. For a field by field view across formats, see what goes in an ML BOM for a model.
Quick check
Do I have to fill in every AI field?
No. Only the required fields and the license relationships are mandatory. Add the optional ones where you have reliable information.
Is SPDX the only format for this?
No. CycloneDX has its own ML BOM capability for models, datasets and configurations. Pick the one your customers and tools accept.
Safeguard scans dependencies and generates SBOMs for your repositories. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
