Strong proposal. One structural question from a practitioner perspective.
Several parts of the RFC depend on being able to reference an AI system precisely: the Evidence Preservation section requires model and safeguard versions, third-party dependencies, and agent and workload identities; rapid alerts share "affected patterns" that members need to match against their own environments; and weekly updates are required to be machine-readable.
The RFC does not yet specify how an incident report should identify the affected system. Without a common identifier scheme, three problems follow:
- Reports about the same model, tool, or vendor component cannot be correlated across members.
- Members receiving a rapid alert cannot programmatically check whether they run the affected component.
- Evidence preservation assumes organizations already track model versions and dependencies before the incident. In practice, many do not, which means the required evidence will often not exist at incident time.
Suggestion: SAFE incident reports and machine-readable updates should reference affected systems using existing component identifier standards, for example CycloneDX ML-BOM or SPDX AI profile identifiers, rather than inventing a new scheme. This would let members map alerts against their own AI inventories where those exist, and would give the "affected patterns" concept a concrete, queryable form.
This would complement #5: OpenTelemetry conventions describe what happened during a run, while a BOM identifier describes what the system is. An incident report likely needs both.
Happy to draft a short proposed section if useful.
Strong proposal. One structural question from a practitioner perspective.
Several parts of the RFC depend on being able to reference an AI system precisely: the Evidence Preservation section requires model and safeguard versions, third-party dependencies, and agent and workload identities; rapid alerts share "affected patterns" that members need to match against their own environments; and weekly updates are required to be machine-readable.
The RFC does not yet specify how an incident report should identify the affected system. Without a common identifier scheme, three problems follow:
Suggestion: SAFE incident reports and machine-readable updates should reference affected systems using existing component identifier standards, for example CycloneDX ML-BOM or SPDX AI profile identifiers, rather than inventing a new scheme. This would let members map alerts against their own AI inventories where those exist, and would give the "affected patterns" concept a concrete, queryable form.
This would complement #5: OpenTelemetry conventions describe what happened during a run, while a BOM identifier describes what the system is. An incident report likely needs both.
Happy to draft a short proposed section if useful.