AIBOM validation: schema, policy and provenance checks

A valid AIBOM is one that parses, meets your required-field policy, agrees with itself and describes the artefacts you actually run. These are four layers of checks, and schema validation covers only the first.

Four layers of validation

1. Schema validation

For CycloneDX, the CycloneDX CLI's validate command checks documents against specification versions 1.0 to 1.7 ^[1]. ML-specific structures such as modelCard are defined in the schema, and the specification says a model card should be specified only for components of type machine-learning-model ^[2].

For SPDX 3, the project recommends two checks: JSON Schema for structure and SHACL for semantics, noting that each catches different errors ^[3]. spdx3-validate runs both ^[4].

2. Policy validation

A schema-valid AIBOM can still be nearly empty, because most AI fields are optional in both formats. Policy validation applies your required elements. Common baselines are:

• CERT-In Table 10: model name, version, type, developer, licensing, software dependencies, ML models and algorithms, performance metrics, data source and data-set information ^[5].
• G7 SBOM for AI clusters: metadata, system-level properties, models, dataset properties, key performance indicators, infrastructure and security properties ^[6].
• Internal rules: for example, every production model has an artefact hash, a pinned revision, an owner and an approval record.

Report policy failures per field and per component, so owners know exactly what to fix.

3. Consistency checks

• Every dataset referenced by a model exists as a component in the document or in a linked AIBOM.
• Base-model and adapter relationships point to real components.
• Licence identifiers are valid expressions, and licence conflicts between model, datasets and dependencies are flagged.
• Version and timestamp values are in the expected formats and are not older than the artefact they describe.

4. Provenance and integrity

The final question is whether the AIBOM matches reality. Compare listed hashes with the artefacts in your registry and deployment. Where models are signed, verify signatures: Sigstore's model_signing lets verifiers confirm a model has not been tampered with since signing ^[7]. OWASP lists weak model provenance as a supply-chain risk for LLM applications, which makes this check more than a formality ^[8].

Scoring completeness

Some teams score AIBOMs rather than pass or fail them. The OWASP AIBOM Generator, for example, calculates a completeness score with recommendations for the AIBOMs it generates ^[9]. Scores help prioritise, but a production gate should still use explicit required fields.

Where validation runs

• In CI, when a model is registered or promoted.
• At intake, when a supplier delivers an AIBOM (AI procurement requirements).
• On a schedule, to catch drift between the AIBOM and deployed artefacts.

For a step-by-step procedure, see How to validate an AIBOM.

Handling failures

Decide in advance what a failure means. A schema error should block publication, because downstream tools cannot read the file. A missing required field on a production model should block promotion until fixed or formally waived, with the waiver recorded against the AIBOM version. Consistency and provenance failures deserve investigation before anything else: a hash that does not match the deployed artefact may be a process error, or it may mean the model was changed outside the approved workflow.

How IntelliXBOM helps

IntelliXBOM validates CycloneDX and SPDX AIBOMs against required-field policies, including the CERT-In AIBOM elements, and reports gaps per component. Version history and diffs show when a field went missing, and results are kept as timestamped evidence.