Clean check-in of AI/ML. Supersedes #948.

[stevespringett]

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

[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...

[HesAnEasyCoder]

Why is this repeated when already listed above? Why is this repeated when already listed above? Maybe take away the "Learning Type" above?

[HesAnEasyCoder]

Why is this repeated when already listed above? Maybe take away the "task" above?