Glaas minimal logo, light

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 requirementAI-BOM field
Training datasets usedcomponents[*] with BLAKE3 content hashes
Data origin and traceabilitydependencies, formulation[*].tasks[*].inputs
Training pipeline / development processformulation[*].workflows[*].tasks
Tooling usedmetadata.tools.components (roar + GLaaS)
Component version identitycomponents[*].version (artifact hash)
Supplier / manufacturermetadata.supplier, metadata.manufacturer
Lifecycle changesregistering 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 (Feb 2026), CISA 2025 SBOM Minimum Elements, and NTIA (2021). Fields are grouped into five categories (each with a maximum point allocation):

CategoryMax ptsWhat it covers
Required Fields20BOM format, spec version, serial number, document version
Metadata20Timestamp, tools, supplier, manufacturer, root component
Component Basics20Name, type, version, hashes, description, licenses
Lineage & Provenance30Workflow formulation, dependency graph, git context, I/O mappings
External References10VCS 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 keyCycloneDX field
license.idcomponents[*].licenses[0].license.id
license.namecomponents[*].licenses[0].license.name
descriptioncomponents[*].description
documentation.urlcomponents[*].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