# AI Bill of Materials: [AI system or product name] [version]

> An AI Bill of Materials (AI-BOM) is a machine-readable and human-readable
> inventory of everything an AI system is built from: models, datasets,
> software dependencies, agents, tools, prompts, training and evaluation
> configuration, lineage and known risks. This template describes the
> inventory and maps each field to CycloneDX 1.7 (standardised by Ecma
> International as ECMA-424, 2nd edition, December 2025) machine learning
> BOM (ML-BOM) objects and to the AI and Dataset profiles of SPDX 3.0.1.
> Replace every `[bracketed]` value and every row marked *Example*.
> Worked examples use a customer support assistant built on a fine-tuned
> language model with retrieval and tool access.

<!--
Guidance: How to use this template
- Treat this document as the readable companion of the machine-readable
  BOM files. The JSON (CycloneDX) or JSON-LD (SPDX) files are the record;
  this document explains scope, decisions, gaps and sharing rules.
- Generate the machine-readable BOM in the build and release pipeline,
  never by hand. Use this document to define what the pipeline must emit.
- Fill sections 1 and 2 first (purpose and scope), then the inventories
  in sections 3 to 7, then lineage and risk in sections 8 and 9. Section
  10 (format mapping) is the contract for the BOM generator.
- Record every gap honestly. "Unknown" with a reason is better than a
  guessed licence or a missing dataset.
- Link the model card, datasheets, software SBOM and vulnerability
  records instead of copying them.
-->

## Document control

<!-- Guidance: Identify exactly which system release this AI-BOM describes. A BOM that cannot be tied to a released artefact digest has little value. -->

| Field | Value |
|---|---|
| Document ID | [AIBOM-SUP-001] |
| AI system and version | [Name] [version] |
| Release artefact | [Container image digest, package ID or deployment ID] |
| BOM serial number | [urn:uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx] |
| Machine-readable formats | *Example:* CycloneDX 1.7 JSON (primary); SPDX 3.0.1 JSON-LD (on request) |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@ai-platform-owner] |
| Approvers / reviewers | [@security-lead], [@legal-licensing], [@ml-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential / Shareable under NDA / Public] |
| Related documents | [Model card], [Datasheets for datasets], [Software SBOM], [Supply chain security assessment], [AI Act technical documentation] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| AI platform owner | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |
| Licensing or legal counsel | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer (if personal data in datasets) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline for release 2.3.0 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added retrieval index and embedding model after architecture change |

## Contents

<!-- Guidance: Keep the order: scope first, inventories next, then lineage, risk, format mapping and process. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [System overview](#2-system-overview)
3. [Model inventory](#3-model-inventory)
4. [Dataset inventory](#4-dataset-inventory)
5. [Software dependencies](#5-software-dependencies)
6. [Agents, tools and prompts](#6-agents-tools-and-prompts)
7. [Training and evaluation configuration](#7-training-and-evaluation-configuration)
8. [Model lineage](#8-model-lineage)
9. [Vulnerability and risk annotations](#9-vulnerability-and-risk-annotations)
10. [Distribution format mapping](#10-distribution-format-mapping)
11. [Example machine-readable excerpt](#11-example-machine-readable-excerpt)
12. [Generation and update process](#12-generation-and-update-process)
13. [Consumers and sharing policy](#13-consumers-and-sharing-policy)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Say why this AI-BOM exists and who needs it. Typical drivers: customer due diligence, supply chain security, licence compliance, regulatory documentation (EU AI Act, Cyber Resilience Act), incident response. Pitfall: a scope so broad that the BOM is never complete, or so narrow that it omits the base model. -->

### 1.1 Purpose

[State the purpose. Example: "This AI-BOM records every model, dataset,
software component, tool and prompt that the Support Assistant 2.3
depends on, so that security, licensing and compliance teams can answer
three questions quickly: what is inside, where did it come from, and is
any part of it affected by a known vulnerability or restriction."]

### 1.2 Drivers

| Driver | What the BOM must support |
|---|---|
| *Example:* Supply chain security | Fast lookup of affected releases when a model, library or dataset is reported as compromised |
| *Example:* Licence compliance | Proof that model weights and datasets are used within their licence terms |
| *Example:* Customer due diligence | A shareable subset for enterprise customers under NDA |
| *Example:* Regulatory documentation | Evidence for technical documentation under the EU AI Act and the software bill of materials required by the Cyber Resilience Act |
| [Driver] | [Need] |

### 1.3 Scope

| In scope | Out of scope |
|---|---|
| *Example:* All models loaded at runtime, including third-party hosted models called through an API | Models used only by individual developers for experiments |
| *Example:* Datasets used to train, fine-tune, evaluate or index retrieval | Raw production logs not used for training |
| *Example:* Runtime software of the inference service and agent runtime | Corporate IT tooling |
| *Example:* System prompts, tool definitions and agent configuration | User prompts at runtime |
| [Item] | [Item] |

### 1.4 Depth and completeness

State how deep the inventory goes and what "complete" means for this
release. Software dependencies follow the depth of the software SBOM
(normally all transitive dependencies). For models, list every model
that executes in the request path plus every model whose output was
used to build an artefact that executes (for example a teacher model
used for distillation, or a model used to label training data). For
datasets, list every dataset that influenced weights, thresholds or a
retrieval index.

| Inventory | Completeness target | Known gaps |
|---|---|---|
| Models | *Example:* All runtime models and all direct ancestors | Training data of the third-party base model is only partly disclosed by its supplier |
| Datasets | *Example:* All training, evaluation and retrieval datasets | None |
| Software | *Example:* All transitive dependencies of the inference image | GPU driver version taken from the host, not the image |
| Agents, tools, prompts | *Example:* All tools registered with the agent runtime | [Gap] |

## 2. System overview

<!-- Guidance: Give just enough architecture for a reader to understand why each inventory item is there. Link the full architecture document. -->

[Describe the system in two or three sentences. Example: "Support
Assistant answers customer questions in the help centre. A router model
classifies intent, a fine-tuned chat model generates answers grounded in
a retrieval index of help articles, and an agent runtime can call three
tools: order lookup, refund request and ticket creation."]

```mermaid
flowchart LR
  user["Customer"] --> api["Assistant API"]
  api --> router["Intent router model"]
  router --> agent["Agent runtime"]
  agent --> llm["Fine-tuned chat model"]
  agent --> rag["Retrieval service"]
  rag --> emb["Embedding model"]
  rag --> idx[("Help article index")]
  agent --> tools["Tools: order lookup, refund, ticket"]
  llm --> guard["Output guardrail classifier"]
  guard --> api
```

| Component | BOM entries it introduces |
|---|---|
| *Example:* Intent router | MDL-002, DS-003 |
| *Example:* Chat model | MDL-001, MDL-004 (base), DS-001, DS-002 |
| *Example:* Retrieval | MDL-003, DS-004 |
| *Example:* Agent runtime | AGT-001, TOOL-001 to TOOL-003, PRM-001 |
| *Example:* Output guardrail | MDL-005, PRM-002 |
| [Component] | [Entries] |

## 3. Model inventory

<!-- Guidance: One row per model artefact, including third-party models called over an API. Record provenance and integrity so that the exact weights can be identified later. Pitfall: recording "latest" or a marketing name instead of an immutable version or snapshot identifier. -->

### 3.1 Models

| ID | Name and version | Type and task | Supplier and provenance | Licence | Hash (algorithm: value) | Location | Model card |
|---|---|---|---|---|---|---|---|
| MDL-001 *(Example)* | support-chat-ft 2026.09 | Generative language model; chat | In-house fine-tune of MDL-004 | Inherits MDL-004 licence terms | SHA-256: [hex] | Internal model registry | MC-SUP-001 |
| MDL-002 *(Example)* | intent-router 1.4.0 | Encoder classifier; text classification | In-house, trained from scratch on DS-003 | Proprietary | SHA-256: [hex] | Internal model registry | MC-SUP-002 |
| MDL-003 *(Example)* | [embedding model] [version] | Embedding model; sentence embeddings | Third party, downloaded from [hub] at revision [commit] | Apache-2.0 | SHA-256: [hex] | Mirrored artefact store | Supplier card [link] |
| MDL-004 *(Example)* | [base model] [version] | Generative language model; base for MDL-001 | Third party, [supplier] | [Supplier licence name and URL] | SHA-256: [hex] | Mirrored artefact store | Supplier card [link] |
| MDL-005 *(Example)* | [moderation classifier] [snapshot] | Hosted API model; content safety | Third party, called over API | Commercial terms [contract ID] | Not available (hosted); snapshot ID recorded | Provider endpoint | Supplier documentation |
| [MDL-nnn] | [Name] [version] | [Type; task] | [Supplier; how obtained] | [SPDX licence ID or reference] | [alg: value] | [Location] | [Link] |

### 3.2 Model attributes

Record the attributes that a consumer needs to judge fitness and risk.
Keep detailed performance figures in the model card; record here only
what identifies and characterises the model.

| ID | Architecture family | Learning approach | Inputs / outputs | Parameter count | Quantisation or format | Autonomy | Sensitive personal data used |
|---|---|---|---|---|---|---|---|
| MDL-001 *(Example)* | Transformer, decoder-only | Self-supervised base, supervised fine-tune | Text / text | [n] | Safetensors, bf16 | Acts through tools with human confirmation for refunds | No |
| MDL-002 *(Example)* | Transformer, encoder-only | Supervised | Text / label | [n] | ONNX, int8 | None | No |
| [MDL-nnn] | [Family] | [Approach] | [In / out] | [n] | [Format] | [Autonomy] | [Yes / No / Unknown] |

### 3.3 Integrity and signing

[Describe how model artefacts are verified before load. Example: "Every
model file is pulled from the internal registry by digest; the registry
rejects artefacts without a valid signature from the release pipeline;
the inference service verifies the SHA-256 digest at start-up and refuses
to serve on mismatch. Formats that can execute code on load are not
accepted."]

## 4. Dataset inventory

<!-- Guidance: List every dataset that shaped weights, thresholds, evaluation results or retrieval content. For each, record source, licence, consent basis and processing. Pitfall: listing only the fine-tuning set and forgetting evaluation, labelling and retrieval data. -->

### 4.1 Datasets

| ID | Name and version | Purpose | Source and collection | Licence or terms | Personal data and legal basis | Size | Datasheet |
|---|---|---|---|---|---|---|---|
| DS-001 *(Example)* | support-dialogues 2026.08 | Fine-tuning MDL-001 | Resolved support chats, EU and UK customers, 2024 to 2026 | Proprietary, internal use | Pseudonymised; legitimate interest assessment LIA-07; opt-out honoured | [n] dialogues | DSH-SUP-001 |
| DS-002 *(Example)* | support-eval-gold 3.0 | Evaluation of MDL-001 | Curated by support experts, double-labelled | Proprietary | Synthetic and consented items only | [n] items | DSH-SUP-002 |
| DS-003 *(Example)* | intent-labels 1.4 | Training MDL-002 | Ticket subjects labelled by vendor [name] | Proprietary; vendor contract [ID] | Pseudonymised | [n] items | DSH-SUP-003 |
| DS-004 *(Example)* | help-articles index 2026-10-01 | Retrieval content | Public help centre articles | Own content | None | [n] chunks | DSH-SUP-004 |
| [DS-nnn] | [Name] [version] | [Purpose] | [Source] | [Licence] | [Basis] | [Size] | [Link] |

### 4.2 Processing and quality

| ID | Preprocessing | Anonymisation method | Known bias or noise | Update mechanism | Availability |
|---|---|---|---|---|---|
| DS-001 *(Example)* | Deduplication, language filter, removal of payment data by pattern and classifier | Named entity replacement; identifiers hashed with rotating salt | Under-represents non-English customers | Monthly snapshot, frozen per training run | Internal only |
| DS-004 *(Example)* | HTML stripped, chunked at heading boundaries | Not applicable | Articles may lag product changes by up to one release | Nightly rebuild | Public source |
| [DS-nnn] | [Steps] | [Method] | [Bias] | [Mechanism] | [Availability] |

### 4.3 Third-party and undisclosed training data

[Record what is known about the training data of third-party models.
Example: "The supplier of MDL-004 publishes a summary of training content
but not a dataset list. The summary is archived as evidence E-07. No
claim is made in this BOM about the composition of that data beyond what
the supplier states."]

## 5. Software dependencies

<!-- Guidance: Do not duplicate the software SBOM. Reference it by serial number and list only AI-specific runtime components a reviewer must see at a glance (inference server, ML frameworks, tokenisers, vector database, GPU runtime). -->

The full software inventory is the software SBOM [SBOM serial number],
produced by the release build as described in the supply chain security
assessment (`security/supply-chain-security`). This section highlights the
components that matter most for AI behaviour and AI-specific attacks.

| ID | Component | Version | Role | Package URL or identifier | Licence | Notes |
|---|---|---|---|---|---|---|
| SW-001 *(Example)* | [Inference server] | [x.y.z] | Serves MDL-001 | pkg:[type]/[name]@[version] | Apache-2.0 | Pinned by digest |
| SW-002 *(Example)* | [ML framework] | [x.y.z] | Runtime for MDL-002 | pkg:[type]/[name]@[version] | [Licence] | |
| SW-003 *(Example)* | [Tokeniser library] | [x.y.z] | Tokenisation for MDL-001 | pkg:[type]/[name]@[version] | [Licence] | Must match training tokeniser |
| SW-004 *(Example)* | [Vector database] | [x.y.z] | Stores DS-004 embeddings | pkg:[type]/[name]@[version] | [Licence] | |
| SW-005 *(Example)* | [GPU runtime] | [x.y] | Accelerator runtime | [Vendor identifier] | Proprietary | Host-provided, see 1.4 |
| [SW-nnn] | [Component] | [Version] | [Role] | [purl] | [Licence] | [Notes] |

## 6. Agents, tools and prompts

<!-- Guidance: Agentic systems change behaviour through configuration, not only through weights. Inventory agents, tools (including MCP servers), system prompts and policies with versions and hashes. Skip this section only if the system has no agent, tool or prompt layer, and say so. -->

### 6.1 Agents

| ID | Agent | Version | Model used | Tools allowed | Autonomy level | Specification |
|---|---|---|---|---|---|---|
| AGT-001 *(Example)* | support-agent | 2.3.0 | MDL-001 | TOOL-001, TOOL-002, TOOL-003 | Refunds require customer confirmation | AGENT-SPEC-SUP-001 |
| [AGT-nnn] | [Agent] | [Version] | [Model] | [Tools] | [Level] | [Link] |

### 6.2 Tools and servers

| ID | Tool | Provider | Interface | Version | Permissions | Data accessed |
|---|---|---|---|---|---|---|
| TOOL-001 *(Example)* | order_lookup | In-house | MCP server, revision 2026-07-28 | 1.2.0 | Read orders of the authenticated customer | Order history |
| TOOL-002 *(Example)* | refund_request | In-house | Internal REST API | 3.1.0 | Create refund up to [amount] after confirmation | Payment reference |
| TOOL-003 *(Example)* | create_ticket | Third party help desk | Vendor API | [API version] | Create ticket | Conversation summary |
| [TOOL-nnn] | [Tool] | [Provider] | [Interface] | [Version] | [Permissions] | [Data] |

### 6.3 Prompts and policies

| ID | Artefact | Version | Hash | Owner | Specification |
|---|---|---|---|---|---|
| PRM-001 *(Example)* | System prompt, support agent | 14 | SHA-256: [hex] | [@prompt-owner] | PROMPT-SPEC-SUP-001 |
| PRM-002 *(Example)* | Output guardrail policy | 6 | SHA-256: [hex] | [@safety-owner] | Guardrails specification GRD-SUP-001 |
| [PRM-nnn] | [Artefact] | [Version] | [Hash] | [@owner] | [Link] |

## 7. Training and evaluation configuration

<!-- Guidance: Record enough configuration to identify how each in-house model was produced: code commit, data snapshot, key hyperparameters, compute and evaluation set. Do not paste full config files; reference them by commit and hash. -->

| ID | Model produced | Code commit | Data inputs | Key hyperparameters | Compute and energy | Evaluation | Run record |
|---|---|---|---|---|---|---|---|
| TRN-001 *(Example)* | MDL-001 | [repo]@[commit] | DS-001 snapshot 2026-08-31 | LoRA rank [r], learning rate [lr], epochs [n] | [n] GPU hours; [n] kWh estimated | DS-002, report EVR-SUP-014 | Experiment [ID] |
| TRN-002 *(Example)* | MDL-002 | [repo]@[commit] | DS-003 1.4 | Batch [n], epochs [n] | [n] GPU hours | Hold-out split of DS-003 | Experiment [ID] |
| [TRN-nnn] | [Model] | [Commit] | [Data] | [Parameters] | [Compute] | [Evaluation] | [Link] |

Evaluation results that support release decisions are kept in the
evaluation plan and model validation report. The BOM records only which
evaluation datasets and harness versions were used, so that a consumer
can tell whether two releases were evaluated on the same basis.

| ID | Evaluation harness | Version | Datasets | Metrics recorded |
|---|---|---|---|---|
| EVL-001 *(Example)* | [Harness name] | [x.y.z] | DS-002 | Answer correctness, groundedness, refusal rate |
| [EVL-nnn] | [Harness] | [Version] | [Datasets] | [Metrics] |

## 8. Model lineage

<!-- Guidance: Show where every model came from: base models, fine-tunes, distillation, merges, quantisation, and the datasets used at each step. Lineage is what lets you answer "are we affected?" when an upstream model or dataset is withdrawn. -->

```mermaid
flowchart TB
  base["MDL-004 base model (third party)"] -->|fine-tuned with TRN-001| ft["MDL-001 support-chat-ft 2026.09"]
  ds1[("DS-001 support dialogues")] -->|trained on| ft
  ds2[("DS-002 eval gold set")] -.->|tested on| ft
  ds3[("DS-003 intent labels")] -->|trained on| router["MDL-002 intent-router 1.4.0"]
  emb["MDL-003 embedding model (third party)"] -->|embeds| ds4[("DS-004 help article index")]
  ft --> agent["AGT-001 support agent"]
  router --> agent
  ds4 --> agent
```

| Child | Relationship | Parent or input | Evidence |
|---|---|---|---|
| MDL-001 *(Example)* | Fine-tuned from | MDL-004 | TRN-001 run record |
| MDL-001 *(Example)* | Trained on | DS-001 | TRN-001 data manifest |
| MDL-001 *(Example)* | Tested on | DS-002 | EVR-SUP-014 |
| MDL-002 *(Example)* | Trained on | DS-003 | TRN-002 data manifest |
| DS-004 *(Example)* | Generated by | MDL-003 (embeddings) | Index build log |
| [Child] | [Relationship] | [Parent] | [Evidence] |

## 9. Vulnerability and risk annotations

<!-- Guidance: Attach known vulnerabilities, advisories, licence restrictions and AI-specific risks to the BOM entries they affect. Use VEX-style statuses so that "not affected" decisions are explicit. Pitfall: tracking CVEs for libraries but ignoring model-level issues such as a poisoned upstream checkpoint or a withdrawn dataset. -->

### 9.1 Vulnerabilities and advisories

| ID | Affects | Source | Description | Status | Justification or action | Date |
|---|---|---|---|---|---|---|
| VUL-001 *(Example)* | SW-003 | [CVE-YYYY-NNNNN] | Unsafe deserialisation in tokeniser loader | Not affected | Loader path not used; tokeniser shipped as plain JSON | YYYY-MM-DD |
| VUL-002 *(Example)* | MDL-003 | Supplier advisory [ID] | Revision [commit] withdrawn after report of tampered weights | Fixed | Pinned to clean revision; digest re-verified | YYYY-MM-DD |
| [VUL-nnn] | [Entry] | [Source] | [Description] | [Not affected / Affected / Fixed / Under investigation] | [Justification] | YYYY-MM-DD |

### 9.2 AI risk annotations

| ID | Affects | Risk | Rating | Control | Reference |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | DS-001 | Personal data memorisation in fine-tuned weights | Medium | Pseudonymisation, memorisation tests before release | Red team report RT-2026-004 |
| RSK-002 *(Example)* | MDL-004 | Upstream licence restricts some uses | Low | Use case reviewed against licence; record LIC-11 | Licence review LIC-11 |
| RSK-003 *(Example)* | TOOL-002 | Excessive agency through refund tool | High | Confirmation step, amount limit, rate limit | Agent specification AGENT-SPEC-SUP-001 |
| [RSK-nnn] | [Entry] | [Risk] | [Low / Medium / High / Serious] | [Control] | [Link] |

## 10. Distribution format mapping

<!-- Guidance: This section is the contract for the BOM generator. For each inventory field, name the CycloneDX 1.7 and SPDX 3.0.1 element that carries it. Check the current schema before changing the generator; field names here were checked against the published schemas when this template was written. -->

### 10.1 Format choice

| Format | Version | Serialisation | Use |
|---|---|---|---|
| CycloneDX | 1.7 (ECMA-424, 2nd edition) | JSON, schema `bom-1.7.schema.json` | *Example:* Primary format; attached to every release |
| SPDX | 3.0.1 with Core, Software, AI and Dataset profiles | JSON-LD | *Example:* Produced on customer request |

SPDX 3.1 was published as a release candidate in January 2026; do not
adopt it for distribution until a final release is announced at
spdx.dev, and record the decision in the revision history when you do.

### 10.2 Field mapping

| Inventory field | CycloneDX 1.7 | SPDX 3.0.1 |
|---|---|---|
| Model artefact | `components[]` with `type` `machine-learning-model` | `ai_AIPackage` (subclass of `software_Package`) |
| Dataset | `components[]` with `type` `data`, details in `data[]` (`componentData`, `type` `dataset`) | `dataset_DatasetPackage` |
| Name, version, supplier | `name`, `version`, `supplier` | `name`, `software_packageVersion`, `suppliedBy` |
| Hash | `hashes[]` (`alg`, `content`) | `verifiedUsing` with `Hash` (`algorithm`, `hashValue`) |
| Licence | `licenses[]` | `hasDeclaredLicense` and `hasConcludedLicense` relationships |
| Package URL | `purl` | `software_packageUrl` |
| Learning approach | `modelCard.modelParameters.approach.type` | `ai_typeOfModel`, `ai_informationAboutTraining` |
| Task, architecture | `modelCard.modelParameters.task`, `architectureFamily`, `modelArchitecture` | `ai_domain`, `ai_typeOfModel` |
| Inputs and outputs | `modelCard.modelParameters.inputs[]`, `outputs[]` (`format`) | `ai_informationAboutApplication` |
| Training datasets | `modelCard.modelParameters.datasets[]` (inline `componentData` or `ref`) | `trainedOn` relationship |
| Evaluation datasets | `modelCard.modelParameters.datasets[]` with a reference to the evaluation dataset | `testedOn` relationship |
| Performance metrics | `modelCard.quantitativeAnalysis.performanceMetrics[]` (`type`, `value`, `slice`, `confidenceInterval`) | `ai_metric`, `ai_metricDecisionThreshold` |
| Limitations and ethics | `modelCard.considerations` (`technicalLimitations`, `ethicalConsiderations`, `fairnessAssessments`) | `ai_limitation`, `ai_safetyRiskAssessment` |
| Energy use | `modelCard.considerations.environmentalConsiderations` | `ai_energyConsumption` |
| Hyperparameters | `formulation[]` or `properties[]` | `ai_hyperparameter` |
| Autonomy | `properties[]` (no dedicated field) | `ai_autonomyType` |
| Sensitive personal data | `data[].sensitiveData` (dataset), `properties[]` (model) | `ai_useSensitivePersonalInformation`, `dataset_hasSensitivePersonalInformation` |
| Dataset collection and processing | `data[].description`, `data[].governance` | `dataset_dataCollectionProcess`, `dataset_dataPreprocessing`, `dataset_anonymizationMethodUsed` |
| Dataset bias and noise | `data[].description` or `properties[]` | `dataset_knownBias`, `dataset_datasetNoise` |
| Dataset size and availability | `properties[]` | `dataset_datasetSize`, `dataset_datasetAvailability` |
| Data classification | `data[].classification` | `dataset_confidentialityLevel` |
| Lineage (base model) | `pedigree.ancestors[]`, `dependencies[]` | `ancestorOf` / `descendantOf` relationships |
| Runtime dependency | `dependencies[]` (`ref`, `dependsOn`) | `dependsOn` relationship |
| Tools and agents | `components[]` or `services[]` with `properties[]` | `software_Package` or `Element` with `usesTool` relationship |
| Model card link | `externalReferences[]` with `type` `model-card` | `externalRef` |
| Vulnerabilities | `vulnerabilities[]` with `analysis` (VEX state and justification) | Security profile vulnerability and VEX assessment relationships |

<!-- Guidance: SPDX 3.0.1 property names are shown with their profile prefix as used in the JSON-LD context (for example ai_typeOfModel). Confirm against the SPDX 3.0.1 model pages before generating files. -->

### 10.3 Properties used for gaps

When neither format has a dedicated field, use name-value properties
with a registered namespace so consumers can parse them.

| Property name | Meaning | Example value |
|---|---|---|
| `[org]:ai:autonomy` *(Example)* | Autonomy level of an agent | `confirm-before-act` |
| `[org]:ai:prompt-version` *(Example)* | Version of the system prompt bound to an agent | `14` |
| `[org]:ai:mcp-revision` *(Example)* | MCP specification revision of a tool server | `2026-07-28` |
| [Name] | [Meaning] | [Value] |

## 11. Example machine-readable excerpt

<!-- Guidance: Keep the excerpt short and valid. It shows reviewers the shape of the real file; it is not the real file. Field names below follow the CycloneDX 1.7 JSON schema. -->

The excerpt shows one model, one dataset and the dependency between them
in CycloneDX 1.7 JSON. Values are examples.

```json
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-01T09:00:00Z",
    "component": {
      "type": "application",
      "bom-ref": "app-support",
      "name": "support-assistant",
      "version": "2.3.0"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "MDL-002",
      "name": "intent-router",
      "version": "1.4.0",
      "hashes": [{ "alg": "SHA-256", "content": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08" }],
      "licenses": [{ "license": { "name": "Proprietary" } }],
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "task": "text-classification",
          "architectureFamily": "transformer",
          "modelArchitecture": "encoder-only",
          "datasets": [{ "ref": "DS-003" }],
          "inputs": [{ "format": "string" }],
          "outputs": [{ "format": "string" }]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [{ "type": "macro-F1", "value": "0.91", "slice": "all-languages" }]
        },
        "considerations": {
          "technicalLimitations": ["Lower accuracy for messages shorter than three words"]
        }
      }
    },
    {
      "type": "data",
      "bom-ref": "DS-003",
      "name": "intent-labels",
      "version": "1.4",
      "data": [
        {
          "type": "dataset",
          "name": "intent-labels",
          "classification": "confidential",
          "description": "Ticket subjects labelled by an external vendor; pseudonymised",
          "governance": { "owners": [{ "organization": { "name": "[Organisation]" } }] }
        }
      ]
    }
  ],
  "dependencies": [
    { "ref": "app-support", "dependsOn": ["MDL-002"] },
    { "ref": "MDL-002", "dependsOn": ["DS-003"] },
    { "ref": "DS-003", "dependsOn": [] }
  ]
}
```

## 12. Generation and update process

<!-- Guidance: Describe who and what produces the BOM, when it is regenerated, and how it is validated and signed. A BOM that is only refreshed before audits drifts from reality within weeks. -->

### 12.1 Generation

| Step | Owner | Tooling | Output |
|---|---|---|---|
| 1. Collect software SBOM from build | CI pipeline | *Example:* SBOM generator from the lockfile and image layers | Software SBOM |
| 2. Export model and dataset metadata | ML platform | *Example:* Registry export job reading model and dataset registries | Model and dataset fragments |
| 3. Export agent, tool and prompt registry | Agent platform | *Example:* Configuration export with hashes | Agent fragment |
| 4. Merge and resolve references | CI pipeline | *Example:* BOM merge tool | Combined AI-BOM |
| 5. Validate | CI pipeline | Schema validation against CycloneDX 1.7 and SPDX 3.0.1 | Validation report |
| 6. Sign and attach | Release pipeline | *Example:* Signed attestation bound to the release digest | Signed AI-BOM |
| 7. Publish | Release manager | Artefact store and trust portal | Published AI-BOM |

### 12.2 Update triggers

Regenerate the AI-BOM and increase its `version` on any of the following
events, and record the change in the revision history:

- a model, dataset, prompt, tool or agent configuration changes version;
- a dependency is added, removed or upgraded in the software SBOM;
- a vulnerability or risk annotation changes status;
- a supplier publishes new information about a third-party model or
  dataset (for example a revised training content summary or licence);
- a dataset is withdrawn or a data subject request changes its content.

### 12.3 Quality checks

| Check | Rule | Action on failure |
|---|---|---|
| *Example:* Every model has a hash or a hosted snapshot ID | 100% | Block release |
| *Example:* Every model has at least one training or provenance record | 100% for in-house models | Block release |
| *Example:* Every dataset has a licence or terms entry | 100% | Block release |
| *Example:* Every tool has a version and permission scope | 100% | Block release |
| *Example:* Unknown values carry a reason | 100% | Warn and assign owner |
| [Check] | [Rule] | [Action] |

## 13. Consumers and sharing policy

<!-- Guidance: Decide who receives which view of the BOM. Some details (dataset sources, prompts, tool permissions) can help an attacker or reveal trade secrets. Share a redacted view rather than refusing to share. -->

| Consumer | View | Channel | Conditions |
|---|---|---|---|
| *Example:* Internal security and incident response | Full | Artefact store | Role-based access |
| *Example:* Enterprise customers | Redacted: models, licences, dataset categories, vulnerabilities | Trust portal | NDA; on request |
| *Example:* Market surveillance or notified body | Full, on reasoned request | Secure transfer | Logged release |
| *Example:* Public | Summary: model names and suppliers, licences | Website | None |
| [Consumer] | [View] | [Channel] | [Conditions] |

| Element | Full | Redacted | Summary |
|---|---|---|---|
| Model names, versions, suppliers | Yes | Yes | Yes |
| Hashes | Yes | Yes | No |
| Dataset names and sources | Yes | Categories only | No |
| System prompts and guardrail policy | Hash only | No | No |
| Tool permissions | Yes | Scope summary | No |
| Vulnerability annotations | Yes | Yes | Fixed items only |

Retention: keep each published AI-BOM for as long as the release it
describes is supported, plus [n] years, and at least as long as any
technical documentation that references it.

## 14. Glossary and references

<!-- Guidance: Define the terms your readers may not share, and list the specifications with versions. -->

| Term | Meaning in this document |
|---|---|
| AI-BOM | Inventory of the models, data, software and configuration an AI system depends on |
| ML-BOM | CycloneDX term for a BOM that describes machine learning models and datasets |
| Lineage | The chain of models and datasets from which a model was derived |
| VEX | Vulnerability Exploitability eXchange: a statement of whether a product is affected by a vulnerability |
| Hosted model | A model run by a third party and reached through an API, whose weights are not available |
| Profile | In SPDX 3, a set of classes and properties for one domain, such as AI or Dataset |

References:

- CycloneDX 1.7 specification and JSON schema, https://cyclonedx.org/specification/overview/
- ECMA-424, 2nd edition (December 2025), https://ecma-international.org/publications-and-standards/standards/ecma-424/
- SPDX 3.0.1 specification, AI profile and Dataset profile, https://spdx.github.io/spdx-spec/v3.0.1/
- SPDX project news on 3.1 release candidates, https://spdx.dev/
- Related templates: `ai-data/model-card`, `ai-data/datasheet-for-datasets`, `security/supply-chain-security`, `ai-data/ai-act-technical-documentation`, `security/cra-vulnerability-handling`, `ai-data/guardrails-spec`

## Standard and licence note

Based on the CycloneDX 1.7 specification (OWASP CycloneDX, standardised
as ECMA-424, 2nd edition, December 2025) and the SPDX 3.0.1 specification
(Linux Foundation SPDX project), including its AI and Dataset profiles.
Field and property names are cited for interoperability; all explanatory
text is original and no specification text is reproduced. Both
specifications evolve: check the current versions at cyclonedx.org and
spdx.dev before changing a BOM generator. Template licence: MIT.