What is the minimal viable schema for an Artificial Intelligence bill of…

What is the minimal viable schema for an Artificial Intelligence bill of materials for prompt, retrieval, memory, and tool-using AI systems, how should it align with CycloneDX and Software Package Data Exchange (SPDX) standards, and what new property types are required?

2026-05-06 · agentic-ai governance-policy rag-retrieval tools-infrastructure security-risk · medium · source → · wiki →

key claims

A minimal viable AIBOM for agentic workloads can stay CycloneDX-aligned today by reusing `component`, `service`, `dependency`, and `formulation` objects and by adding namespaced properties rather than requiring a new core component type immediatelyCycloneDX (2025)CycloneDX (2026)
SPDX 3.0.1 already provides strong package-level coverage for models and datasets, but a complete agentic AIBOM still needs an extension profile because prompt, orchestration, and memory-schema artefacts are not first-class classes in the current AI profileSPDX (2024)SPDX (2024)SPDX (2024)
CycloneDX's own open issues show unresolved AI service, model dependency, fixed hyperparameter, and future agent-card questions, which indicates that current agentic schema semantics are still incomplete rather than fully settledRutkows (2025)Rutkows (2023)Bardenstein (2023)
The minimal agentic extension should add only behaviour-shaping artefacts that can be stably identified at design time, model, prompt or instruction, retrieval snapshot, memory schema, tool manifest, and orchestration config, because that preserves NTIA-style practicality while closing the most important conceptual gapsAdministration (2021)Mitchell (2026)
Mutability and fingerprinting should reuse existing hash, version, external-reference, and signature fields wherever possible, while a new `snapshotStrategy` property records whether an artefact is pinned by content hash, Merkle-tree digest, schema version, or external snapshot identifierCycloneDX (2025)Mitchell (2026)
Memory state and live retrieval results should not be part of the minimal declared AIBOM, because they are runtime-evidence surfaces, but the memory schema and retrieval snapshot policy must be declared so the runtime object can later be compared against approved design intentMitchell (2026)Mitchell (2026)
Execution binding is a first-class design concern, so a minimal AIBOM must declare whether each tool or context surface is identity-bound, policy-bound, or ambient, and it must reference the approval scope that constrains the declared tool pathMitchell (2026)Mitchell (2026)
The most adoption-realistic path is a two-step standardization strategy, ship a CycloneDX 1.7 profile today with a lightweight AIBOM property taxonomy, then upstream the same semantics into an SPDX AIBOM extension profile as current AIBOM working-group efforts matureProject (2026)Suriyawongkul et al. (2025)Rajbahadur et al. (2026)

Research Question

What is the minimal viable set of schema properties required to describe Artificial Intelligence (AI) system dependencies for systems that use prompts, retrieval knowledge bases, memory, and tools in a useful, standards-aligned AI bill of materials, specifically, how should existing CycloneDX Machine Learning Bill of Materials (ML-BOM) and Software Package Data Exchange (SPDX) 3.0 AI profile schema be extended to represent deterministic versus non-deterministic components, mutable versus immutable dependencies, prompts, retrieval indexes, memory, and identity-bound versus ambient execution contexts?

Findings

Executive Summary

A minimal viable AIBOM for agentic workloads should reuse CycloneDX and SPDX for core inventory structure and add only a small extension layer for agentic artefacts and control semantics, rather than introducing a separate bill-of-materials standard. CycloneDX is the better immediate serialization target because its existing component, service, dependency, formulation, and property surfaces can already express the minimal schema without waiting for a new release. SPDX should be the long-term formalization target through an AIBOM extension profile, because current AI and Dataset profiles remain package-centric and do not yet make prompt, orchestration, or memory-schema artefacts first-class. The minimum new property set is six fields, semantic class, mutability, determinism, context binding, snapshot strategy, and approval-scope reference, because those six cover the design-time semantics that standard SBOM fields and current AI profiles still miss.

Key Findings

A minimal viable AIBOM for agentic workloads can stay CycloneDX-aligned today by reusing component, service, dependency, and formulation objects and by adding namespaced properties rather than requiring a new core component type immediately.
SPDX 3.0.1 already provides strong package-level coverage for models and datasets, but a complete agentic AIBOM still needs an extension profile because prompt, orchestration, and memory-schema artefacts are not first-class classes in the current AI profile.
CycloneDX's own open issues show unresolved AI service, model dependency, fixed hyperparameter, and future agent-card questions, which indicates that current agentic schema semantics are still incomplete rather than fully settled.
The minimal agentic extension should add only behaviour-shaping artefacts that can be stably identified at design time, model, prompt or instruction, retrieval snapshot, memory schema, tool manifest, and orchestration config, because that preserves NTIA-style practicality while closing the most important conceptual gaps.
Mutability and fingerprinting should reuse existing hash, version, external-reference, and signature fields wherever possible, while a new snapshotStrategy property records whether an artefact is pinned by content hash, Merkle-tree digest, schema version, or external snapshot identifier.
Memory state and live retrieval results should not be part of the minimal declared AIBOM, because they are runtime-evidence surfaces, but the memory schema and retrieval snapshot policy must be declared so the runtime object can later be compared against approved design intent.
Execution binding is a first-class design concern, so a minimal AIBOM must declare whether each tool or context surface is identity-bound, policy-bound, or ambient, and it must reference the approval scope that constrains the declared tool path.
The most adoption-realistic path is a two-step standardization strategy, ship a CycloneDX 1.7 profile today with a lightweight AIBOM property taxonomy, then upstream the same semantics into an SPDX AIBOM extension profile as current AIBOM working-group efforts mature.

Assumptions

Assumption: Producers can externalize prompt templates, tool manifests, and orchestration configurations into versioned artefacts rather than keeping them only as opaque application code. Justification: current AIBOM tooling and CycloneDX working-group discussions already assume extractable model and configuration metadata.
Assumption: Namespaced AIBOM properties are an acceptable interim serialization strategy before the semantics become part of a formal shared profile. Justification: both ecosystems expose explicit extension mechanisms for this style of incremental evolution.

Analysis

The evidence supports a minimum-viable design that preserves existing BOM identity and dependency semantics while adding only the smallest new agentic layer needed to classify semantically active artefacts and their control meaning. CycloneDX is operationally ahead for serialization flexibility, but SPDX is procedurally ahead for formal profile evolution, so the design should deliberately map one conceptual schema across both ecosystems rather than forcing one standard to behave like the other. A standalone AIBOM schema remains a plausible rival strategy, but current practice and current standards work both extend existing BOM ecosystems rather than replace them, so a standalone format would add adoption cost and duplicate validator and exporter effort without stronger near-term evidence. An SPDX-first strategy is also plausible because formal AIBOM work is already happening there, but CycloneDX is the better immediate serialization choice because its current reference schema already exposes services, formulation workflows, and flexible property arrays that can be emitted today. The core trade-off is between design-time stability and runtime completeness: the minimal declared schema must stop at artefacts that can be approved and versioned before execution, while leaving live context, memory state, and retrieval results to a linked runtime AIBOM rather than overloading one artefact with both purposes. The resulting design is minimal not because it is short, but because every retained field answers one of six concrete questions, what class of artefact is this, how stable is it, how deterministic is it, how is it pinned, how is it bound to authority, and which approved operations does it enable.

bomFormat: CycloneDX
specVersion: "1.7"
components:
  - bom-ref: model:gpt-4.1
    type: machine-learning-model
    name: gpt-4.1
    properties:
      - name: aibom:determinism
        value: stochastic
  - bom-ref: prompt:system
    type: data
    name: support-agent-system-prompt
    hashes:
      - alg: SHA-256
        content: 2b3f...deadbeef
    properties:
      - name: aibom:componentClass
        value: system-instruction
      - name: aibom:mutability
        value: versioned-mutable
      - name: aibom:snapshotStrategy
        value: content-hash
services:
  - bom-ref: service:crm
    name: crm-api
    properties:
      - name: aibom:contextBinding
        value: identity-bound
      - name: aibom:approvalScopeRef
        value: policy:crm-read-ticket-update
formulation:
  - workflows:
      - name: support-triage
        properties:
          - name: aibom:componentClass
            value: agent-configuration

Risks, Gaps, and Uncertainties

CycloneDX agent-card semantics are still open working-group territory, so any current aibom:componentClass=agent-configuration convention is an interim design rather than a ratified standard field.
SPDX extension mechanics are clear at the namespace level, but this item does not yet specify a fully formal AIBOM extension ontology with machine-readable class definitions.
Retrieval snapshot digest design remains partly unsettled because different vector stores and indexing pipelines expose different levels of reproducible corpus identity.
Practical tool support is currently model-centred, so prompt, memory-schema, and tool-manifest extraction workflows may lag the schema until practice implementations catch up.

Open Questions

Should future standards define a first-class agent-configuration object, or is a property-taxonomy approach sufficient if formulation workflows are already available?
What is the most reproducible digest method for heterogeneous RAG indexes that mix raw source files, chunking parameters, embeddings, and ranking metadata?
Should approval-scope references point to external policy objects only, or should BOM-native permission manifests become first-class cross-standard objects?