WIP: Proposed CycloneDX v2.0 additions to the AI/ML property Taxonomy

[mrutkows]

See proposed CycloneDX v2.0 AI/ML JSON schema (proposed): CycloneDX/specification#948

[jkowalleck]

why is cdx:ai-ml:model:tokenizer under cdx:ai-ml:model:language Namespace Taxonomy ?
It is supposed to be under cdx:ai-ml:model Namespace Taxonomy

[mrutkows]

Good catch Jan, I broke it back out as its own property table (as it appeared before this PR) and added an example as well.

[jkowalleck]

This property MAY appear multiple times.
and
This property MAY occur multiple times.

this are duplicates

[mrutkows]

Pushed commit to fix

[JunHwan-Kwon]

@mrutkows Thank you for the overview in today's working group meeting and for adding the affine quantization vocabulary and worked examples so quickly. I reviewed the affine additions in this PR.

The direction aligns well with the use case I raised. To clarify its scope, I was proposing the optional recording of affine mapping parameters for each schema-addressable external input or output of a hash-identified model artifact. I was not proposing the enumeration of every internal layer or weight tensor.

I have one structural concern with the current worked examples, together with several localized wording and example points. Concretely, the main change I am suggesting is to move the external-interface quantization properties from the aggregate modelParameters.properties array to the sibling properties array of the relevant named input or output. The remaining items are localized corrections to the new table wording and examples.

Parameter binding

My main concern is the placement of the worked examples. Both currently place their quantization properties under modelCard.modelParameters.properties. At that level, the values are not bound to a particular named input or output.

Different external tensors may use the same integer dataType while having different scale and zeroPoint values. An aggregate model-level property set therefore loses the distinction needed to compare the affine mapping used by a preprocessing or runtime harness with the mapping declared for a named model input or output.

The evidence I shared in CycloneDX/specification#948 is not limited to the MobileNetV2 example. In a predeclared, SHA-256-pinned corpus of 50 public TFLite artifacts spanning four quantization-focused subcohorts, 62 of 114 external parameter instances across 32 artifacts carried complete affine mappings, and 30 artifacts contained more than one distinct complete external affine contract.

All 114 interface records, including the affine fields of the 62 quantized parameters, were independently cross-checked against the ai-edge-litert 2.1.4 Interpreter metadata API with zero mismatches. The corpus, artifact identities, and verification scripts are available in the public evidence repository.

These figures are exact measurements of the defined corpus and are not intended as an estimate of ecosystem prevalence. The broader point is structural: LiteRT and ONNX both associate affine quantization parameters with a particular tensor. An aggregate model-level property set therefore cannot preserve the mapping when multiple named parameters carry distinct affine values.

MobileNetV2 was simply a compact worked example in which the uint8 input and output used different scale and zero-point values.

Given a declared preprocessing or runtime harness contract, a consumer can statically compare it with the affine mapping recorded for the named model parameter and flag an affine-contract mismatch at the deployment boundary without running inference.

From a medical-device AI perspective, this is a narrow but concrete example of how parameter-bound metadata could support deployment-assurance and threat-modeling workflows for a hash-identified model artifact used within a separately documented validated deployment configuration. This check detects inconsistency between declared affine mappings; it does not by itself establish that the deployed harness implements the declared contract or validate the full preprocessing pipeline.

Could the properties in the external-interface example therefore be placed in the properties array of the relevant named modelParameters.inputs[] or modelParameters.outputs[] entry? That would preserve the parameter binding while keeping format.dataType as the declared integer representation.

The required parameter-level extension point is already present in the current JSON draft in CycloneDX/specification#990. For the JSON representation, this placement therefore appears achievable through taxonomy wording and worked-example updates without introducing a new schema field.

For example, the relevant named-parameter fragment for the per-tensor case could be expressed along these lines:

{
  "modelParameters": {
    "inputs": [
      {
        "name": "image",
        "modality": "image",
        "format": {
          "dataType": "uint8",
          "encoding": "raw"
        },
        "properties": [
          {
            "name": "cdx:ai-ml:model:parameter:quantization:scheme",
            "value": "affine_asymmetric"
          },
          {
            "name": "cdx:ai-ml:model:parameter:quantization:granularity",
            "value": "per-tensor"
          },
          {
            "name": "cdx:ai-ml:model:parameter:quantization:scale",
            "value": "0.0078125"
          },
          {
            "name": "cdx:ai-ml:model:parameter:quantization:zeroPoint",
            "value": "128"
          }
        ],
        "shape": [1, 224, 224, 3]
      }
    ]
  }
}

Localized wording and example points

1. The per-tensor example is described as TFLite-style INT8 but uses a zeroPoint of 128. That value is outside the signed int8 range. The example should either declare dataType: "uint8" and describe the representation as UINT8, as above, or use a zero point representable by signed int8.

2. The scheme description should say that it "MUST be present whenever any other quantization sub-property is used," rather than that it "MUST be set before." Consumers should not depend on the order of entries in the properties array. The description should also refer to the scheme applied to the named parameter or tensor rather than to the model as a whole.

3. For per-axis quantization, "ordered by axis index" is misleading. The axis value selects one tensor dimension, and element i of the scale or zero-point vector applies to slice i along that dimension. When that dimension is static, the vector cardinality should equal shape[axis]. This is consistent with the per-axis semantics specified by LiteRT and ONNX QuantizeLinear. The per-axis worked example already describes this correctly as "one element per slice along the quantized axis," so the property-table wording could be aligned with that explanation.

4. The per-axis example refers to an internal weight tensor but does not identify that tensor. Since internal tensor enumeration was not part of the original use case, deferring this example appears to be the safer option unless a real schema-addressable external per-axis parameter is available for the worked example.

5. The affine_symmetric description could be narrowed. For the current signed INT8 weight example, a zero point of 0 is appropriate. The LiteRT int8 specification represents weights over [-127, 127] with zero point 0, which removes one integer code rather than half of the range. For a framework-neutral taxonomy, the general scheme description should either qualify the zero-point rule by dataType or state explicitly that it is limited to zero-centered signed storage. PyTorch MinMaxObserver, for example, defines the symmetric zero point as 0 for qint8 and 128 for quint8.

6. If affine_asymmetric is intended to describe affine quantization without a symmetry constraint, it should not require a non-zero zeroPoint. The LiteRT int8 specification permits activation zero points anywhere in [-128, 127], which includes 0. If the scheme is instead intended to classify representations according to the resulting zero-point value, that classification rule could be stated explicitly.

With the parameter binding clarified and these localized points addressed, the affine additions would align well with the use case I raised.

Given the August 20 timeline, the highest-value low-impact changes for 2.0 seem to be the parameter-bound per-tensor example and the localized table corrections that require no new JSON schema field. If helpful, I would be happy to prepare the exact Markdown patch or a focused PR for those items in whichever contribution form is most convenient. If the internal per-axis tensor example is better handled after the cutoff, deferring that part would be completely reasonable.

Thank you again for moving this forward so quickly.

[JunHwan-Kwon]

A short addendum on placement: the affine sketch in CycloneDX/specification#948 already preserved named-parameter binding under format.properties. I noticed that this later extension is not currently present in the successor branch behind CycloneDX/specification#990, so I have asked there whether format.properties or the sibling modelParameter.properties array is intended to be the final parameter-level extension point.

My main point here is unchanged and does not depend on that choice: the affine properties should be bound to the relevant named parameter rather than placed at the aggregate modelParameters level.