From 60f1386b3ed8a4100679a842ad4c0c264fe15c41 Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 08:49:00 -0700 Subject: [PATCH 1/8] docs: add safety traceability use cases --- srac/docs/safety-traceability-use-cases.md | 179 +++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 srac/docs/safety-traceability-use-cases.md diff --git a/srac/docs/safety-traceability-use-cases.md b/srac/docs/safety-traceability-use-cases.md new file mode 100644 index 00000000000..d2aaffbdbe8 --- /dev/null +++ b/srac/docs/safety-traceability-use-cases.md @@ -0,0 +1,179 @@ +# Policy-Aware Safety Traceability and Evidence Exchange Use Cases + +## Purpose + +This document defines use cases for maintaining machine-verifiable safety +traceability across software changes and transfers of responsibility. The goal +is to preserve authoritative engineering evidence while minimizing unnecessary +manual checkpoints during routine feature development. + +The intended approach is to: + +- evaluate the affected portion of the traceability graph for each change; +- periodically perform a full re-evaluation to confirm completeness; +- preserve authoritative sources, provenance, and approval responsibility; +- activate policy checks according to product context, jurisdiction, legal + entity, and lifecycle stage; +- require human checkpoints when defined safety, organizational, or regulatory + boundaries are crossed; and +- package the resulting traceability and evidence for downstream assessment. + +Success should be measured using: + +- the percentage of changes completed without a human checkpoint; +- the time required to identify affected artifacts; +- false-negative and false-positive impact-analysis results; +- stale or unresolved evidence detected before release; and +- the time required to assemble assessment evidence. + +## Responsibility boundary + +The originating engineering and safety lifecycle remains authoritative. An +exporter creates a deterministic projection of those records; it does not make +or approve a safety decision. Receiving tools may validate, correlate, query, +and display the supplied context, but they do not become the safety authority. + +An SPDX, CycloneDX, or SRAC artifact demonstrates what was exported, from which +source revision, and under which mapping and policy versions. The artifact does +not independently certify the software. + +## Use-case matrix + +| Use case | Trigger | Responsible parties | Applicable policy context | Automated support | Human checkpoint | Generated evidence | +| --- | --- | --- | --- | --- | --- | --- | +| Tier 1 to OEM to independent assessor or approval authority | Component release, version update, changed assumption, vulnerability, or safety finding | The Tier 1 provides component evidence; the OEM performs the contextual assessment; an independent assessor reviews the safety case; an approval authority acts where regulatory approval applies | Supplier and OEM policies, the product safety process, and applicable regulatory requirements | Verify schema, provenance, digest, component identity, assumption coverage, traceability completeness, and stale evidence | OEM safety approval, independent assessment, and any applicable regulatory approval | Supplier evidence, OEM impact analysis, decisions, approvals, and a safety-case or assessment evidence package | +| Internal feature development | Code, architecture, requirement, or configuration change | Developer, component owner, feature team, and safety authority | Engineering, safety, release, and product-specific policies | Traverse the affected graph and check linked requirements, tests, inspections, evidence, and approvals | Required when a safety boundary, baseline, assumption, or required evidence changes | Impact analysis, changed requirements and tests, verification results, and decisions | +| Internal responsibility transfer | Responsibility moves between teams, repositories, or legal entities | Outgoing owner, incoming owner, and approving authority | Organizational ownership, engineering, and release policies | Check baseline completeness, provenance, unresolved obligations, and accepted evidence | The incoming owner formally accepts the baseline and open obligations | Handover record, accepted baseline, unresolved-obligation list, and approval | +| Country, jurisdiction, or legal-entity transfer | Software deployment, maintenance, or responsibility moves to another jurisdiction or entity | Product owner and legal, compliance, security, and safety representatives | Potentially applicable laws, regulations, and organizational policies, identified by jurisdiction, entity, product, lifecycle stage, and effective date | Propose potentially applicable policies for legal or compliance confirmation and identify additional checks or controls | Legal or compliance confirms applicability; the relevant safety or regulatory authority approves where required | Confirmed applicability decision, control results, exceptions, and accountable-party approval | +| OSS component intake | A new or updated OSS component enters a safety-related product | The OSS project is not a responsible supplier and has no contractual obligation to provide safety evidence; the OEM or integrator assumes responsibility for assessment and use | OEM or integrator intake, security, licensing, and safety policies | Correlate the component, identify available upstream information, and evaluate assumptions and evidence gaps | The OEM or integrator determines whether additional analysis, controls, or evidence are required | Undetermined upstream state, OEM assessment, compensating evidence, and contextual decision | + +## Checkpoint triggers + +A human checkpoint is required when: + +- safety relevance or an assurance level changes; +- an assumption of use becomes invalid; +- ownership or legal responsibility changes; +- deployment jurisdiction changes; +- a candidate legal or regulatory requirement may become applicable; +- required evidence is missing, stale, contradictory, or invalid; +- the computed impact boundary is incomplete or ambiguous; +- a certification or assessment baseline changes; or +- a vulnerability or security finding affects a safety-relevant component. + +Automated tools may identify candidate policy applicability, but legal and +compliance representatives confirm whether a law or regulation applies. + +## Completeness and tool confidence + +Incremental analysis must include transitive dependencies rather than only +directly linked elements. An incomplete or ambiguous impact boundary is itself +a checkpoint condition. + +A full re-evaluation is required periodically and when: + +- the assessment baseline changes; +- the metamodel or a mapping overlay changes; +- an applicable policy version changes; +- a release reaches a defined assurance milestone; or +- incremental and baseline results disagree. + +Every automated result records the tool name, tool version, configuration, +input digest, mapping version, and policy version. The adopter evaluates tool +confidence for the intended use and determines whether qualification or other +confidence measures are required. + +## Packaging concept + +```text +Authoritative engineering sources + | + v +Versioned metamodel, mapping overlays, and policy references + | + v +Incremental checks and periodic full re-evaluation + | + v +Portable SRAC / SPDX / CycloneDX projection + | + v +Digest verification (signature where available) + | + v +OEM contextual decisions +(identity, policy version, provenance, and digest) + | + v +Safety-case or assessment evidence package + | + v +Independent assessment +(and regulatory approval where applicable) +``` + +The metamodel rules and relationship constraints are maintained in one +versioned source. Source-specific systems, such as Sphinx-Needs, Dependable +Elements, or TRLC/Lobster, use mapping overlays to project their records into a +common graph. Exporters consume that graph rather than reimplementing the +rules. + +Producer-side automation validates schema conformance, references, +traceability, mapping coverage, source digests, and reproducibility. +Receiver-side automation verifies the artifact digest or signature, +provenance, and deterministic correlation with SBOM components. Neither side +autonomously creates or approves a safety decision. + +OEM decisions and approvals are recorded with the responsible identity, +timestamp, policy version, source references, and digest before the evidence +package is assembled. + +## End-to-end demonstrator + +The initial demonstrator should exercise the Tier 1, OEM, and independent +assessment flow: + +1. A Tier 1 supplies a component SBOM and a component-level safety manifest. +2. The OEM verifies the package and deterministically correlates it with the + component used in a product. +3. The OEM maps the supplied evidence into the product and system context. +4. One supplier assumption is satisfied and another requires additional + evidence. +5. An OEM policy activates a human safety checkpoint. +6. The OEM records its contextual decision with identity, policy version, + provenance, and digest. +7. The supplier-to-OEM evidence chain is packaged for independent assessment. +8. A later component update marks the affected decision and evidence as stale. +9. A tampered package or mismatched digest is rejected without importing its + assertions. +10. A baseline-triggered full evaluation confirms that the incremental result + is contained within the complete affected set. + +## Demonstrator acceptance criteria + +The demonstrator passes when: + +- every component reference resolves deterministically without name-only + matching; +- all required traceability edges are complete; +- supplier and OEM assertions and decisions remain distinguishable; +- candidate policy applicability remains provisional until confirmed by an + authorized person; +- an invalid digest, invalid signature, or invalid provenance fails closed; +- stale evidence is detected after the component update; +- the incremental affected set is contained within the full evaluation result; +- every automated result identifies its tool, configuration, mapping, policy, + and input versions; and +- no exporter or receiving tool autonomously creates or approves a safety + decision. + +## Open design questions + +- What is the minimum common set of node, relationship, provenance, and + constraint types required by all supported source models? +- Which policies are enforceable automated checks, and which are advisory + candidates requiring human confirmation? +- Which events require a full evaluation rather than an incremental one? +- How are mapping and policy versions selected, distributed, and retired? +- What evidence is required at each responsibility-transfer boundary? +- Which tool-confidence measures are required for each intended safety use? From 00771999af8b46b28796acf43a3b79d309e20401 Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 09:15:50 -0700 Subject: [PATCH 2/8] fix: refresh SRAC pilot integrity artifacts --- .../persistency-kvs/output/persistency-kvs.srac-report.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json index 67b7b9cc781..8e9a7b255d0 100644 --- a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json +++ b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json @@ -34,7 +34,7 @@ "algorithm": "SHA-256", "assertionSha256": "a00f1b98762fa848d00d3c9718f9a219b710fdf019d435f51d75fdd0d7993c56", "sbomSha256": "e147f5db23d35c97c8c779c217d6edb9977d01cddf7683e2c46d45cf09737243", - "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c" + "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4" }, "bindingEvidence": { "strategy": "score-known-good", From 275fc05aa6b8936ad196ce30e6dd032e996ceee3 Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 09:15:54 -0700 Subject: [PATCH 3/8] fix: refresh SRAC pilot integrity artifacts --- .../persistency-kvs/output/persistency-kvs.srac-report.sha256 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 index c3e10620114..dffbdd73969 100644 --- a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 +++ b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 @@ -1 +1 @@ -6b7c4687dadf661dd40ec42ed7a94d4e3e42a1f5b88ddd15a6a2900aab491074 persistency-kvs.srac-report.json +1f821286a5066707d08644c5d71a1c9bcdf258352e94b1c54b41476fbeb85128 persistency-kvs.srac-report.json From 85b8928875aaa87bbf887edd8f8fe7f9a20e981f Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 09:15:59 -0700 Subject: [PATCH 4/8] fix: refresh SRAC pilot integrity artifacts --- srac/pilot/persistency-kvs/provenance.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/srac/pilot/persistency-kvs/provenance.json b/srac/pilot/persistency-kvs/provenance.json index ba0099cff58..9314100d0dc 100644 --- a/srac/pilot/persistency-kvs/provenance.json +++ b/srac/pilot/persistency-kvs/provenance.json @@ -11,8 +11,8 @@ "packageCount": 162, "integrity": { "assertionSha256": "a00f1b98762fa848d00d3c9718f9a219b710fdf019d435f51d75fdd0d7993c56", - "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c", - "reportSha256": "6b7c4687dadf661dd40ec42ed7a94d4e3e42a1f5b88ddd15a6a2900aab491074" + "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4", + "reportSha256": "1f821286a5066707d08644c5d71a1c9bcdf258352e94b1c54b41476fbeb85128" }, "persistencyBinding": { "sbomName": "score_persistency", From ea490e888c122b7e09ce3d7f0689071a5df37daa Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 09:16:03 -0700 Subject: [PATCH 5/8] fix: refresh SRAC pilot integrity artifacts --- .../output/current-product.srac-report.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json index e527d1f13fe..c52c749fd68 100644 --- a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json +++ b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json @@ -26,6 +26,6 @@ "algorithm": "SHA-256", "assertionSha256": "8e6773518b2be6030ffab73d94095c241fc48f1cff9e60ce0f418be4c5bce6e4", "sbomSha256": "e147f5db23d35c97c8c779c217d6edb9977d01cddf7683e2c46d45cf09737243", - "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c" + "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4" } } From 97cce456020508598eb2f21f570aee22c438a1b9 Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 09:16:08 -0700 Subject: [PATCH 6/8] fix: refresh SRAC pilot integrity artifacts --- .../output/current-product.srac-report.sha256 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 index 7fa111953ac..25d2f614c02 100644 --- a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 +++ b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 @@ -1 +1 @@ -78f3413c7d41cf4533cdac7f2f4252d3eb7da1c68c32aa5d05993979f7c4a4af current-product.srac-report.json +e60408151afc3220a6e6b6cb2b8b7ce8a6c4237f825be8726377e4a7219f8e15 current-product.srac-report.json From ba7f9cff34ec2e20de89177a47d3e74dfe82438c Mon Sep 17 00:00:00 2001 From: devashridatta-dotcom Date: Thu, 8 Oct 2026 09:16:13 -0700 Subject: [PATCH 7/8] fix: refresh SRAC pilot integrity artifacts --- srac/pilot/lifecycle-health-monitor/provenance.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/srac/pilot/lifecycle-health-monitor/provenance.json b/srac/pilot/lifecycle-health-monitor/provenance.json index 1698c1209aa..43f650bf213 100644 --- a/srac/pilot/lifecycle-health-monitor/provenance.json +++ b/srac/pilot/lifecycle-health-monitor/provenance.json @@ -10,7 +10,7 @@ "integrity": { "assertionSha256": "8e6773518b2be6030ffab73d94095c241fc48f1cff9e60ce0f418be4c5bce6e4", "sbomSha256": "e147f5db23d35c97c8c779c217d6edb9977d01cddf7683e2c46d45cf09737243", - "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c", - "reportSha256": "78f3413c7d41cf4533cdac7f2f4252d3eb7da1c68c32aa5d05993979f7c4a4af" + "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4", + "reportSha256": "e60408151afc3220a6e6b6cb2b8b7ce8a6c4237f825be8726377e4a7219f8e15" } } From 381acf72b6754e36123cf1b55206717c7a6968c4 Mon Sep 17 00:00:00 2001 From: Devashri Datta Date: Thu, 8 Oct 2026 10:49:11 -0700 Subject: [PATCH 8/8] docs: keep use-case PR documentation-only --- .../output/current-product.srac-report.json | 2 +- .../output/current-product.srac-report.sha256 | 2 +- srac/pilot/lifecycle-health-monitor/provenance.json | 4 ++-- .../persistency-kvs/output/persistency-kvs.srac-report.json | 2 +- .../persistency-kvs/output/persistency-kvs.srac-report.sha256 | 2 +- srac/pilot/persistency-kvs/provenance.json | 4 ++-- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json index c52c749fd68..e527d1f13fe 100644 --- a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json +++ b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.json @@ -26,6 +26,6 @@ "algorithm": "SHA-256", "assertionSha256": "8e6773518b2be6030ffab73d94095c241fc48f1cff9e60ce0f418be4c5bce6e4", "sbomSha256": "e147f5db23d35c97c8c779c217d6edb9977d01cddf7683e2c46d45cf09737243", - "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4" + "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c" } } diff --git a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 index 25d2f614c02..7fa111953ac 100644 --- a/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 +++ b/srac/pilot/lifecycle-health-monitor/output/current-product.srac-report.sha256 @@ -1 +1 @@ -e60408151afc3220a6e6b6cb2b8b7ce8a6c4237f825be8726377e4a7219f8e15 current-product.srac-report.json +78f3413c7d41cf4533cdac7f2f4252d3eb7da1c68c32aa5d05993979f7c4a4af current-product.srac-report.json diff --git a/srac/pilot/lifecycle-health-monitor/provenance.json b/srac/pilot/lifecycle-health-monitor/provenance.json index 43f650bf213..1698c1209aa 100644 --- a/srac/pilot/lifecycle-health-monitor/provenance.json +++ b/srac/pilot/lifecycle-health-monitor/provenance.json @@ -10,7 +10,7 @@ "integrity": { "assertionSha256": "8e6773518b2be6030ffab73d94095c241fc48f1cff9e60ce0f418be4c5bce6e4", "sbomSha256": "e147f5db23d35c97c8c779c217d6edb9977d01cddf7683e2c46d45cf09737243", - "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4", - "reportSha256": "e60408151afc3220a6e6b6cb2b8b7ce8a6c4237f825be8726377e4a7219f8e15" + "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c", + "reportSha256": "78f3413c7d41cf4533cdac7f2f4252d3eb7da1c68c32aa5d05993979f7c4a4af" } } diff --git a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json index 8e9a7b255d0..67b7b9cc781 100644 --- a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json +++ b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.json @@ -34,7 +34,7 @@ "algorithm": "SHA-256", "assertionSha256": "a00f1b98762fa848d00d3c9718f9a219b710fdf019d435f51d75fdd0d7993c56", "sbomSha256": "e147f5db23d35c97c8c779c217d6edb9977d01cddf7683e2c46d45cf09737243", - "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4" + "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c" }, "bindingEvidence": { "strategy": "score-known-good", diff --git a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 index dffbdd73969..c3e10620114 100644 --- a/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 +++ b/srac/pilot/persistency-kvs/output/persistency-kvs.srac-report.sha256 @@ -1 +1 @@ -1f821286a5066707d08644c5d71a1c9bcdf258352e94b1c54b41476fbeb85128 persistency-kvs.srac-report.json +6b7c4687dadf661dd40ec42ed7a94d4e3e42a1f5b88ddd15a6a2900aab491074 persistency-kvs.srac-report.json diff --git a/srac/pilot/persistency-kvs/provenance.json b/srac/pilot/persistency-kvs/provenance.json index 9314100d0dc..ba0099cff58 100644 --- a/srac/pilot/persistency-kvs/provenance.json +++ b/srac/pilot/persistency-kvs/provenance.json @@ -11,8 +11,8 @@ "packageCount": 162, "integrity": { "assertionSha256": "a00f1b98762fa848d00d3c9718f9a219b710fdf019d435f51d75fdd0d7993c56", - "knownGoodSha256": "c9fb107684a721e36f1f4a94f34da862955c88b0b519843cd8c5db8814fe36d4", - "reportSha256": "1f821286a5066707d08644c5d71a1c9bcdf258352e94b1c54b41476fbeb85128" + "knownGoodSha256": "b0c70e4e1ceb3afa820406c0fea20b915cd65a204c9feb7366749a6d2cca4c5c", + "reportSha256": "6b7c4687dadf661dd40ec42ed7a94d4e3e42a1f5b88ddd15a6a2900aab491074" }, "persistencyBinding": { "sbomName": "score_persistency",