Activities / CycloneDX

ACTIVITIES.md in a CycloneDX bill of materials

CycloneDX attaches a model card to a machine-learning component to say what the model is. An activity declaration is the same idea for what a component does: which legal activities its code performs or enables. This page sets out how the record in an ACTIVITIES.md travels in any CycloneDX document a product already builds, through the lexlint property namespace.

These names are LexLint's proposal. The lexlint namespace is not yet registered in the CycloneDX property taxonomy, and this page is the documentation the taxonomy asks a namespace to publish.

The property names

Every name is in the lexlint namespace, follows the taxonomy's grammar (segments of letters, digits, hyphens and underscores, separated by colons), and takes a string value. An <id> is an activity id from the registry, written as it is there.

Name	On	Value
`lexlint:registry`	`metadata`	The registry the ids come from, as its versioned address: `https://lexlint.io/activities/v1`.
`lexlint:declared`	`metadata`	The day the declaration was last reviewed: a four-digit year, the month and the day, joined by hyphens.
`lexlint:declared_by`	`metadata`	Who reviewed it, when the file names them.
`lexlint:activity:<id>`	a component	`performs` or `enables`: the file's `mentioned`.
`lexlint:activity:<id>:enabled`	a component	`by_default`, `requires_configuration`, `requires_dependency` or `requires_environment`.
`lexlint:not:<id>`	a component	The reason the maintainers rule the activity out.
`lexlint:required`	a service	`true` when the component cannot do its documented job without this counterparty, `false` for a default the deployer can change.

Where each part of the file goes

In ACTIVITIES.md	In CycloneDX 1.6 and 1.7	Note
a component (`purl`, `shape`)	`components[]` with `purl`, `bom-ref` and `type`	An exact fit.
an activity	two properties on the component	The formal form is a claim in `declarations.claims[]` whose target is the component's `bom-ref`, with the note as its reasoning.
`where`	`evidence.occurrences[]` with `location` and `symbol`	`additionalContext` names the activity property the occurrence carries.
`not`	a `lexlint:not:<id>` property	Or a claim that the component does not perform it.
`talks_to`	`services[]` with `endpoints` and `x-trust-boundary`, and a `dependencies` edge from the component	`lexlint:required` on the service.
`aggregate`	`compositions[]` with `aggregate` and `assemblies` naming the component	The same three values.
`since`, `until`	not carried	A bill of materials describes one version, so an activity's presence in that version's document is the statement.

An example

The library in the registry's example, as CycloneDX 1.6.

{ "bomFormat": "CycloneDX", "specVersion": "1.6", "metadata": { "properties": [ {"name": "lexlint:registry", "value": "https://lexlint.io/activities/v1"}, {"name": "lexlint:declared", "value": "2026-10-16"} ] }, "components": [{ "type": "library", "bom-ref": "pennant-outreach", "name": "@pennant/outreach", "version": "1.4.0", "purl": "pkg:npm/%40pennant/outreach@1.4.0", "properties": [ {"name": "lexlint:activity:automated_outreach", "value": "performs"}, {"name": "lexlint:activity:automated_outreach:enabled", "value": "by_default"}, {"name": "lexlint:not:tracks_devices", "value": "Sets no cookie and sends no telemetry."} ], "evidence": {"occurrences": [ {"location": "src/send.ts", "symbol": "send", "additionalContext": "lexlint:activity:automated_outreach"} ]} }], "services": [{ "bom-ref": "sms-gateway", "name": "Example SMS gateway", "endpoints": ["https://api.sms-gateway.example"], "x-trust-boundary": true, "properties": [{"name": "lexlint:required", "value": "true"}] }], "dependencies": [ {"ref": "pennant-outreach", "dependsOn": ["sms-gateway"]} ], "compositions": [ {"aggregate": "complete", "assemblies": ["pennant-outreach"]} ] }

Proposed for CycloneDX 2.0: an activity card

Properties carry the record today without any change to the standard. The shape LexLint proposes for the next major version is an activityCard on a component, the model card's sibling, holding activities[] (each with its id, registry, mentioned, enabled, since and until), notPerformed[] and counterparties[]. What a product does with a component's activities, and whether each one applies to it, is a separate document shaped like a vulnerability exploitability statement, and is not part of this record.