Add an optional causal incident graph profile for reconstructable, mechanically verifiable SAFE findings
Summary
SAFE already asks members to preserve incident evidence, analyze control failures, record containment and recovery, and publish reproducible verification methods.
I propose an optional causal incident graph profile that connects those elements into a machine-readable state-transition model so a finding can answer a concrete forensic question:
Why was ACTION X possible?
The profile is experimental and is not intended to replace SAFE's exchange model or OpenTelemetry.
SAFE remains the incident-learning / findings layer; OpenTelemetry can remain the runtime evidence transport; the proposed graph is a semantic and verification layer over preserved evidence.
Gap this addresses
The current RFC has the right evidence and review surfaces, but the relationships between them are mostly narrative:
- which pre-state enabled an action;
- which control was expected to prevent it;
- which transition actually occurred;
- which invariant held or was violated;
- which causes enabled or failed to prevent the transition;
- what containment changed;
- what recovery restored;
- and what verification proves that the unsafe transition is no longer reachable.
For cross-organization incident learning, those relationships matter because two reports may contain similar logs while representing very different causal failures.
Proposed canonical model
actor
→ action
→ pre_state
→ control
→ transition
→ post_state
→ invariant
→ violation
→ cause
→ containment
→ recovery
→ verification
→ evidence
Relevant objects can additionally carry or reference:
phase + time + provenance + trace_reference + evidence_reference + confidence
A minimal transition can be expressed as:
(pre_state, action, conditions) -> post_state
with typed causal relations such as:
enabled_by
required
triggered
bypassed
failed_to_prevent
amplified
masked
recovered_by
verified_by
Why recovery and verification are explicit
A configuration or code change is not, by itself, evidence that remediation succeeded.
The stronger pattern is:
previous failing path
→ replay or equivalent test
→ unsafe transition is no longer reachable
→ invariant holds
→ evidence preserved
This also keeps containment distinct from recovery.
Blocking egress may contain an incident while credentials, permissions, or unsafe state still require recovery.
A near-miss can therefore produce a compact verdict such as:
INV-CRED-001 VIOLATED
INV-NET-001 HELD
CONTAINMENT PASSED
RECOVERY PASSED
VERIFICATION PASSED
Relationship to existing SAFE discussions
I see this as complementary to directions already raised in this repository:
The goal is not to absorb those proposals, but to provide a common causal structure in which their evidence can be connected.
Reference implementation
I implemented an experimental SAFE Causal Incident Graph (SCIG) v0.1 profile in safal207/ProofPath.
It has been merged to main after passing the repository's full Rust CI.
Reference materials in safal207/ProofPath:
docs/safe-causal-incident-graph/SAFE_CAUSAL_INCIDENT_GRAPH.md
schemas/safe-causal-incident-graph-v0.1.schema.json
examples/safe-near-miss.json
crates/proofpath-verifier/src/bin/proofpath-scig.rs
Implementation:
The reference verifier checks transition references, invariant results, causal-edge types, lifecycle state, evidence references, and a basic rule that verification cannot pass unless recovery passed and expected/observed outcomes agree.
Suggested integration path
Rather than expanding every SAFE record with mandatory fields, I suggest treating this as an optional profile / extension for findings where causal reconstruction and remediation verification are useful.
If the working group finds the direction useful, I would be happy to submit a small PR against rfc-safe-proposal.md that:
- adds a short optional causal-profile appendix;
- maps the profile to the existing Evidence Preservation, Review Framework, and From Lessons to Controls sections;
- keeps OpenTelemetry as the evidence transport rather than defining a competing telemetry schema; and
- includes a sanitized near-miss example demonstrating containment → recovery → verification.
Question for the working group
Would SAFE consider an optional causal state-transition profile for findings and near misses, specifically to make control failure, containment, recovery, and remediation verification mechanically reconstructable from preserved evidence?
Disclosure: I maintain ProofPath, the experimental reference implementation described above. SCIG v0.1 is a community proposal and is not presented as an official SAFE specification.
Add an optional causal incident graph profile for reconstructable, mechanically verifiable SAFE findings
Summary
SAFE already asks members to preserve incident evidence, analyze control failures, record containment and recovery, and publish reproducible verification methods.
I propose an optional causal incident graph profile that connects those elements into a machine-readable state-transition model so a finding can answer a concrete forensic question:
The profile is experimental and is not intended to replace SAFE's exchange model or OpenTelemetry.
SAFE remains the incident-learning / findings layer; OpenTelemetry can remain the runtime evidence transport; the proposed graph is a semantic and verification layer over preserved evidence.
Gap this addresses
The current RFC has the right evidence and review surfaces, but the relationships between them are mostly narrative:
For cross-organization incident learning, those relationships matter because two reports may contain similar logs while representing very different causal failures.
Proposed canonical model
Relevant objects can additionally carry or reference:
A minimal transition can be expressed as:
with typed causal relations such as:
Why recovery and verification are explicit
A configuration or code change is not, by itself, evidence that remediation succeeded.
The stronger pattern is:
This also keeps containment distinct from recovery.
Blocking egress may contain an incident while credentials, permissions, or unsafe state still require recovery.
A near-miss can therefore produce a compact verdict such as:
Relationship to existing SAFE discussions
I see this as complementary to directions already raised in this repository:
design_coverage/design_referencescan attach design-time lineage to a control or invariant node.The goal is not to absorb those proposals, but to provide a common causal structure in which their evidence can be connected.
Reference implementation
I implemented an experimental SAFE Causal Incident Graph (SCIG) v0.1 profile in
safal207/ProofPath.It has been merged to
mainafter passing the repository's full Rust CI.Reference materials in
safal207/ProofPath:Implementation:
The reference verifier checks transition references, invariant results, causal-edge types, lifecycle state, evidence references, and a basic rule that verification cannot pass unless recovery passed and expected/observed outcomes agree.
Suggested integration path
Rather than expanding every SAFE record with mandatory fields, I suggest treating this as an optional profile / extension for findings where causal reconstruction and remediation verification are useful.
If the working group finds the direction useful, I would be happy to submit a small PR against
rfc-safe-proposal.mdthat:Question for the working group
Would SAFE consider an optional causal state-transition profile for findings and near misses, specifically to make control failure, containment, recovery, and remediation verification mechanically reconstructable from preserved evidence?
Disclosure: I maintain ProofPath, the experimental reference implementation described above. SCIG v0.1 is a community proposal and is not presented as an official SAFE specification.