Context
Eclipse SCORE needs change impact analysis (docs-as-code #314, process_description #535) to answer: "if I change this requirement, what downstream artifacts are affected?" They're waiting on upstream sphinx-needs to implement hash-based versioned links.
Problem
When an artifact changes (title, description, fields, links), all downstream artifacts that depend on it may need review. Currently there's no automated way to:
- Detect which artifacts changed between two baselines/commits
- Compute the transitive impact set via the link graph
- Flag downstream artifacts as "needs review"
Rivet already has rivet diff for structural comparison and petgraph for reachability — combining them solves this.
Proposed approach
- Content hashing: compute a stable hash of each artifact's content (title + description + fields + links)
- Stored hashes: optional
rivet.lock or per-artifact hash field for baseline comparison
- Impact command:
rivet impact --since <commit|tag> that:
- Diffs current artifacts against the baseline
- For each changed artifact, walks the link graph to find all transitively dependent artifacts
- Reports the impact set grouped by depth (direct dependents, transitive)
- Dashboard integration: highlight impacted artifacts in the graph/matrix views
Rivet artifacts
References
Context
Eclipse SCORE needs change impact analysis (docs-as-code #314, process_description #535) to answer: "if I change this requirement, what downstream artifacts are affected?" They're waiting on upstream sphinx-needs to implement hash-based versioned links.
Problem
When an artifact changes (title, description, fields, links), all downstream artifacts that depend on it may need review. Currently there's no automated way to:
Rivet already has
rivet difffor structural comparison and petgraph for reachability — combining them solves this.Proposed approach
rivet.lockor per-artifact hash field for baseline comparisonrivet impact --since <commit|tag>that:Rivet artifacts
References