[stevespringett]

This PR supersedes #948, which introduced a number of unnecessary changed files and originated outside of the specification repo.

• closes Proposed 2.0 schema for AI/ML BOM #948

[stevespringett]

There are multiple things that are currently broken with #948 that this PR will attempt to resolve. This includes references to objects that no longer exist in 2.0, improper use of objects in 2.0, and lack of integration with the component model. This PR will also introduce the required test fixtures (valid / invalid) necessary for the RFC period.

[JunHwan-Kwon]

Thanks for moving the AI/ML work into a clean in-repository branch.

The tensor-level affine quantization gap I raised on #948 still seems to apply here. modelParameter.format is additionalProperties: false and defines dataType, encoding, and mimeType, with no typed representation for scale values, zero-points, or quantization axes. modelParameter.properties can hold those as strings, but the schema cannot validate a per-axis scale vector or check its cardinality against the corresponding tensor dimension.

The reproducible TFLite evidence, the ONNX correspondence (per-tensor, per-axis, and blocked granularity), and a proposed framework-neutral shape are all in that comment:
#948 (comment)

I understand that the draft is still being stabilized, so no response is needed at this stage. Once the structure and fixtures settle, I would be glad to help with the aligned JSON, XML, and protobuf definitions and the corresponding valid and invalid tests.

[JunHwan-Kwon]

@stevespringett @mrutkows One small integration check following my review on CycloneDX/cyclonedx-property-taxonomy#175.

After #990 was opened, commit mrutkows/specification@e1116c4 on #948 added a properties array inside modelParameter.format, and the affine example there used that extension point. In the current branch behind #990, format remains additionalProperties: false with dataType, encoding, and mimeType, while the sibling modelParameter.properties extension point is present.

Was the later format.properties addition intended to be carried forward into #990, or is the sibling modelParameter.properties array now the intended parameter-level extension point?

Either location would preserve named-parameter binding. I am asking only so that the quantization worked examples in CycloneDX/cyclonedx-property-taxonomy#175 use the intended canonical location.

[stevespringett]

@mrutkows can you please take a look and see if this PR matches your expectation of the way the new AI model should look. Also look at the test cases.

NOTE: This PR makes assumptions that other PRs (currently in the public RFC period and not yet approved by TC54) have received positive votes and have been merged.

[mrutkows]

@stevespringett Perhaps we should meet to review to assure this gets the dedicated time needed for closure.

Here are the summary of changes that need review:

1 · Core Concept Change
modelCard is renamed to modelProperties. The description makes the intent explicit: intrinsic/technical characteristics stay here; contextual, ethical, and fairness concerns are pushed to a separate risk model; audience-tailored views (model cards) are expressed via perspectives. This is a clean separation-of-concerns aligned with v2.0 architecture.

Matt: modelCard is an industry term and IMO we would regret not adopting the term as a grouping (despite alternate "views" being possible via CDX) and taking a stand on the elements that make up a modelCard.

2 · Architecture Definitions Refactored

The nested structural { primary, secondary, topologyType } object inside modelArchitecture is replaced by three standalone top-level definitions: architectureFamily, architectureFeature, and architectureTopology. Each uses a oneOf (predefined enum | custom extension object), which is cleaner than the old anyOf with regex patterns.

Matt: Nesting of the 3 elements of a model arch. seemed cleaner...

3 · Risk/Ethics Definitions Removed
riskGroup, consideration, fairnessAssessments, ethicalConsiderations, designConsiderations are all gone — deferred to cyclonedx-risk-2.0.schema.json. ⚠️ That file is currently untracked.

Matt: Assume these are moved elsewhere?

4 · modelParameter Massively Enriched
The old parameter had only name, format, description. Steve adds: modality, dataType, mimeType, quantization, shape, processingStage, required, defaultValue, and constraints.

Matt: I believe that aligned with the additions proposed in the other PR... have to verify 1-by-1

5 · Measure Types Moved to Common Schema
timeUnits, energyUnits, co2Units, measure, energyMeasure, co2Measure are all removed from this file and now referenced from cyclonedx-common-2.0.schema.json.

Matt: assume these was moved elsewhere as you conveyed the last few months...

6 · Bug Fixes
Multiple broken $ref paths corrected (missing $ in #/defs/, wrong path separators, #/definitions/ → #/$defs/).

TYVM

Key Discussion Points:

1. behavioralParadigm and specializedProcessing removed with no replacement

Matt: Discuss if this really disappeared?

3. performanceMetric.type changed from a 23-value enum to an open string — less validation enforcement

Matt: Discuss? enum. may be too untenable, but CDX property perhaps?

5. Custom cdx: unit extension pattern removed from performanceMeasure

Matt: Was really hoping to go in this direction to assure we limit property values to those property names that match (to encourage correctness of information); otherwise any URN value works and prevents at some validation of correctness. Understand that this is a new precedent...

7. Dependency on common schema definitions that need to be verified as present.

Matt: I have no idea how to contain this other than a full review once we have most of 2.0 schema finalized...

[mrutkows]

Another "Advisor" reiterated the points of discussion:

1. Confirm the risk model / perspectives concepts exist (or are landing) in core v2.0, and whether they actually cover groups-at-risk, harms/benefits, and fairness assessments at the granularity your consideration object had — that's the one change with real content-loss risk if those core objects turn out thinner than what you removed.

2. Confirm modelProperties (no bom-ref) vs. your modelCard (had a bom-ref) is intentional given the new xxxProperties convention — if some other part of the spec still expects an addressable model card, that's a breaking change worth surfacing now.

3. Whether dropping the curated benchmark/metric enum is a considered tradeoff (open strings avoid taxonomy drift) or an oversight from schema simplification.

[mrutkows]

Would like to discuss the comments I added in the PR's conversation...

[stevespringett]

This branch has been synced with 2.0-dev now that many other development branches have been approved and merged into it.

[taleodor]

I share Matt's concern about losing "Model Card" as the industry-adopted term. That's usually the first thing that comes up in relevant conversations.

Question / suggestion - would it be possible to add optional type parameter (enum) to perspective, where initial value could be "model-card". And additionally, can we bake such model-card perspective into the spec? Somewhat similar to #960, but with the addition of type.

P.s. AI found a reference to modelCard in perspective schema here -

specification/schema/2.0/model/cyclonedx-perspective-2.0.schema.json

Line 84 in c257f85

"$.components[?(@.type=='machine-learning-model')].modelCard",

Probably should be updated.

[jkowalleck]

there are some conflicts that require fixing.

[jkowalleck]

@stevespringett could you fix these merge conflicts, before we do a review on this?

[jkowalleck]

RFC notice sent on September 16, 2026.
Public RFC period ends October 14, 2026.

[glenmessenger]

We operate k8s-aibom, an open-source Kubernetes controller that emits CycloneDX 1.6 ML-BOMs for AI workloads at runtime, and since v1.5.0 it cryptographically verifies model signature claims (Sigstore/OMS bundles verified against configurable trust roots, with Rekor transparency-log inclusion). Reading this PR's evidence model against that implementation, we hit one gap we couldn't express:

There is no analysis technique for cryptographic signature verification as identity evidence. The existing signature technique is defined as byte/code pattern matching and is excluded from identificationMethod; attestation is a party assertion rather than direct analysis; hash-comparison is a bare digest check. But "this model's identity was established by verifying a signature chain against an operator-configured trust root, with transparency-log inclusion" is direct analysis, is an identification method, and in practice is the strongest identity evidence an ML-BOM can carry — model files otherwise carry no intrinsic identity (no manifest, no package coordinates), which makes this vocabulary gap more consequential for AI/ML components than for software packages.

Proposal: add a signature-verification technique (meta:enum along the lines of "Cryptographic verification of a signature over the subject against a trust root, including any transparency-log inclusion check, that binds an asserted identity to the subject's content") and permit it in identificationMethod. We'd suggest its value carry the verified signer identity, since that's what a downstream consumer needs to act on.

Happy to contribute worked examples from production output if useful — we currently express these facts as custom properties for exactly this reason, and would much rather emit them in the specification's own vocabulary.

[glenmessenger]

A second, smaller question from the same implementation experience: the new AI/ML schema describes the model thoroughly (architecture, quantization, training, metrics) but has no integrity or identity surface of its own — presumably by design, with model-as-component composing with componentEvidence/componentIdentityEvidence for identity, confidence, and occurrences. If that's the intent, could the model README or an example make the composition explicit (a model component whose identity carries evidence with per-technique confidence)? In our experience producing runtime ML-BOMs, identity confidence is the field auditors interrogate first — a canonical example would keep the ecosystem's ML tooling from treating the AI/ML schema as self-contained and skipping evidence entirely.

Relatedly, is the intent that as-deployed vs. as-trained context be carried by the perspectives work (#1067)? Runtime-generated ML-BOMs need somewhere to say "this describes what is serving, not what was built," and we'd rather align with the intended mechanism than invent one.

[taleodor]

Relatedly, is the intent that as-deployed vs. as-trained context be carried by the perspectives work (#1067)? Runtime-generated ML-BOMs need somewhere to say "this describes what is serving, not what was built," and we'd rather align with the intended mechanism than invent one.

I don't think perspectives covers this. Perspectives are used to define fields needed for specific purposes (i.e., what information is needed in a cdx document to express a model card). I believe what you're asking here can be expressed by lifecycle in metadata. More specifically, as-deployed and as-trained are separate documents with different lifecycle values.

[glenmessenger]

Thanks, that settles it. We'll emit metadata.lifecycles on every runtime document and leave as-trained to whoever produced the model, since we only observe serving. One check on the reading: for inventory observed from the Kubernetes API, we take operations as the correct phase rather than discovery, which reads as network discovery.

Shout if you'd put it the other way.