At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Governed artifact | Select Reverse provenance | Ordered upstream evidence hops | The start node must exist in the deposited graph |
| Imported or approved edge | Traverse toward its source | Typed requirement or decision path | Candidate and rejected links are excluded |
| Retained evidence ID | Select Open evidence | Frozen supporting record | Some hops can report unavailable evidence |
| Broken or moved endpoint | Preserve its state | Visible provenance gap | The app does not repair external sources |
How it works
- Open Enterprise evidence workspace.
- Search for the implementation artifact.
- Open its retained revision.
- Select Reverse provenance.
- Follow the typed links toward the root reason.
- Open evidence at every retained hop.
Example
An investigator starts with a GitHub code revision. Reverse provenance follows an approved implementation link to a component requirement. Further links connect it to a system requirement and a business decision. Each retained hop exposes its evidence. An unavailable record stays visible instead of disappearing from the path.
What this does not mean
Reverse traceability reports the governed graph that was deposited. It does not infer undocumented reasons or approve suggested links. A complete-looking path is only as reliable as its approved links, retained evidence, and coverage state.
Related questions
Next step
Use reverse provenance when leadership needs the recorded reason behind an implementation.
View on Atlassian Marketplace