GLaaS generates an **AI Bill of Materials (AI-BOM)** — a machine-readable inventory of everything that went into producing an AI artifact: the pipeline steps, input datasets, model files, cryptographic hashes, and provenance metadata. The output follows the [CycloneDX 1.7](https://cyclonedx.org/docs/1.7/) standard for ML systems.

## Why an AI-BOM matters

Software BOMs are increasingly required by procurement rules and regulation. For AI systems specifically, the demand comes from two directions:

**Supply chain transparency** — regulators and buyers want to know what data, models, and tools a system was built from, under what conditions, and by whom. A hash-grounded BOM is the only credible answer: it can be verified, not just claimed.

**Regulatory compliance** — the EU AI Act and equivalent frameworks are operationalizing this demand into documentation obligations.

## EU AI Act — Annex IV Technical Documentation

The [EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689) (Regulation (EU) 2024/1689, in force August 2024) requires providers of high-risk AI systems to maintain **Annex IV Technical Documentation** before placing a system on the EU market. High-risk systems are those listed in Annex III — which includes AI used in employment, education, critical infrastructure, law enforcement, migration, and administration of justice.

Annex IV §2 specifically requires:

- A detailed description of the **training methodology and techniques**
- The **datasets used**, including their origin, scope, and characteristics
- The **architecture** of the model and its components
- A description of any **changes made through the system's lifecycle**

An AI-BOM generated from GLaaS lineage data directly addresses these requirements:

| Annex IV §2 requirement | AI-BOM field |
|---|---|
| Training datasets used | `components[*]` with BLAKE3 content hashes |
| Data origin and traceability | `dependencies`, `formulation[*].tasks[*].inputs` |
| Training pipeline / development process | `formulation[*].workflows[*].tasks` |
| Tooling used | `metadata.tools.components` (roar + GLaaS) |
| Component version identity | `components[*].version` (artifact hash) |
| Supplier / manufacturer | `metadata.supplier`, `metadata.manufacturer` |
| Lifecycle changes | registering successive sessions builds a versioned audit trail |

The BOM is a **point-in-time snapshot** of one registered session. For an Annex IV Technical File you would typically collect BOMs across the development lifecycle — training runs, evaluation runs, fine-tuning runs — to build up the full change history.

> The EU AI Act does not mandate CycloneDX specifically. It mandates the *information*. CycloneDX 1.7 is the most widely adopted machine-readable format for AI component documentation, and is referenced by both the G7 SBOM-for-AI Minimum Elements (Feb 2026) and CISA 2025 SBOM Minimum Elements.

## Generating the AI-BOM

The Audit page is available for sessions registered under an **organization scope**.

1. Register a session: `roar register <hash>` with `roar scope use <org>`
2. Open the DAG on glaas.ai and click **Audit (AI-BOM)** in the navigation
3. Review the completeness score and field checklist
4. Click **Download** to export the CycloneDX 1.7 JSON file

The BOM is generated on demand from the lineage already stored in GLaaS — no separate tooling or pipeline changes required.

## Completeness scoring

Every BOM is scored against a checklist for a set of fields derived from the [G7 SBOM-for-AI Minimum Elements](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf) (Feb 2026), [CISA 2025 SBOM Minimum Elements](https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom), and [NTIA (2021)](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf). Fields are grouped into five categories (each with a maximum point allocation):

| Category | Max pts | What it covers |
|---|---|---|
| Required Fields | 20 | BOM format, spec version, serial number, document version |
| Metadata | 20 | Timestamp, tools, supplier, manufacturer, root component |
| Component Basics | 20 | Name, type, version, hashes, description, licenses |
| Lineage & Provenance | 30 | Workflow formulation, dependency graph, git context, I/O mappings |
| External References | 10 | VCS URL, download location, documentation URL, label properties |

A GLaaS-generated BOM for a typical registered session with git context will score in the **Standard** range (≥ 70). The fields most likely to be missing are licenses, component descriptions, and documentation URLs — all of which can be supplied via roar labels (see below).

## Improving completeness with labels

GLaaS auto-populates everything it can observe from the pipeline. Fields that require human knowledge — licenses, narrative descriptions, external references — are populated from **artifact and session labels**.

### Artifact-level fields

Set these on any artifact before or after the run:

```bash
# License information
roar label set artifact model.pt \
  license.id=Apache-2.0

# Or with a full name if no SPDX identifier applies
roar label set artifact dataset.parquet \
  license.id=CC-BY-4.0 \
  license.name="Creative Commons Attribution 4.0"

# Human-readable description
roar label set artifact model.pt \
  description="ResNet-50 fine-tuned on internal validation set v3"

# Link to paper, model card, or documentation
roar label set artifact model.pt \
  documentation.url=https://huggingface.co/your-org/your-model
```

These keys map directly to first-class CycloneDX fields on the component:

| Label key | CycloneDX field |
|---|---|
| `license.id` | `components[*].licenses[0].license.id` |
| `license.name` | `components[*].licenses[0].license.name` |
| `description` | `components[*].description` |
| `documentation.url` | `components[*].externalReferences[type=documentation]` |

Any other label keys you set on an artifact are included as `glaas:label:*` properties on the component, so no metadata is lost — it just doesn't map to a standard BOM field.

### Session-level fields

Labels on the DAG/session itself appear as properties on `metadata.component` in the BOM — the root component representing the AI system as a whole. These are a good place for experiment-level context:

```bash
roar label set dag current \
  project=image-classifier \
  experiment=ablation-v2 \
  owner=ml-team
```