Audit
On this page
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 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 (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.
- Register a session:
roar register <hash>withroar scope use <org> - Open the DAG on glaas.ai and click Audit (AI-BOM) in the navigation
- Review the completeness score and field checklist
- 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 (Feb 2026), CISA 2025 SBOM Minimum Elements, and NTIA (2021). 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:
# 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:
roar label set dag current \
project=image-classifier \
experiment=ablation-v2 \
owner=ml-team