docs: propose portable safety traceability and SBOM exchange

[devashridatta-dotcom]

Summary

Proposes an integration decision for transporting safety traceability metadata without creating a second source of truth.

The decision recommends a source-neutral canonical projection with reviewed mapping overlays from authoritative lifecycle sources, followed by deterministic SRAC packaging and SPDX/CycloneDX references.

Repository ownership and handoff

This revision reflects the proposed S-CORE integration boundary:

• eclipse-score/docs-as-code produces the optional, source-neutral export, stacked on the metamodel export in feat: add metamodel schema export tools docs-as-code#878.
• eclipse-score/cicd-workflows exposes a generic opt-in metadata-export target without changing default documentation builds.
• eclipse-score/sbom-tool validates and consumes the versioned export package during Bazel SBOM generation.
• eclipse-score/reference_integration remains the adopter and end-to-end demonstrator.
• S-CORE integration governance owns the canonical mapping contract and compatibility rules, while lifecycle owners remain authoritative for safety decisions.

The format-neutral handoff contract includes:

• srac.json
• manifest.json
• contract and schema version
• source identity, revision and digest
• exporter identity and version
• stable product, system and component identities
• requirement, evidence, decision and approval references
• review and analysis-closure state
• digests for all packaged files

Scope

The proposed decision covers:

• Tier 1 or internal supplier to OEM to independent-assessment handover
• internal development, responsibility transfer, jurisdiction and OSS-intake scenarios
• Sphinx-Needs, Dependable Element and TRLC/Lobster mapping boundaries
• producer validation and receiver-side revalidation
• integrity, provenance, analysis completeness and human-approval boundaries
• tool-confidence considerations
• current SPDX 2.3 and CycloneDX 1.x reference paths
• migration to native SPDX 3.1 FunctionalSafety and future CycloneDX safety support
• ownership across docs-as-code, cicd-workflows, sbom-tool and reference_integration
• staged implementation with objective demonstrator acceptance criteria

This PR is documentation-only. It does not authorize a production implementation.

Standards status

SPDX 3.1 RC1 contains the foundational FunctionalSafety profile. SPDX PR #1436, adding SafetyContextRelationship and SafetyIntegrityLevelType, was merged after RC1 and is present in the current development model.

Native SPDX 3.1 output remains dependent on the final specification and supporting S-CORE libraries. Native CycloneDX safety output remains dependent on adoption of the proposed safety model.

Related work

• Proposal: Define a minimum SRAC profile for an S-CORE pilot #3282
• feat: add SRAC sidecar proof of concept reference_integration#370
• docs: define policy-aware safety traceability use cases reference_integration#393
• feat: add metamodel schema export tools docs-as-code#878
• Metamodel drift detector between docs-as-code metamodel and dependable elements tooling#502
• Metamodel flow checking metamodel checks in agent flows mcp-servers#22
• [FuSa] Add SafetyContextRelationship and SafetyIntegrityLevelType spdx/spdx-3-model#1436
• [FuSa] Add AnalysisTrigger and SystemImpactAnalysis for system impact analysis spdx/spdx-3-model#1442
• [FuSa] Add SRAC system impact analysis examples spdx/spdx-3-model#1443
• [Core] Add reusable Decision model spdx/spdx-3-model#1458
• Added RDX risk alignment. Add safety. Minor refactor CycloneDX/specification#1120

[github-actions]

Documentation preview for this pull request is available at:
pr-3318: https://eclipse-score.github.io/score/pr-3318/

[devashridatta-dotcom]

The DR has been updated following the architecture discussion with Frank.

The decision requested from the infrastructure group is agreement on:

1. docs-as-code owning the optional exporter;
2. cicd-workflows providing a generic opt-in export trigger;
3. sbom-tool consuming and validating the versioned SRAC package during Bazel SBOM generation;
4. reference_integration remaining the adopter and demonstrator; and
5. S-CORE integration governance owning the canonical mapping and compatibility contract.

The PR does not request approval of a production implementation. Once the ownership and handoff contract are agreed, the implementation can be split into separately reviewable PRs.

All current Documentation, PR Checks, Eclipse ECA and FEP/FCP checks pass.