At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Expected retained record | Resolve it by governed identity | Available, missing, or unavailable state | Availability does not prove correctness |
| Recorded source location | Compare current and frozen identity | Moved, deleted, or stale state | Source access and retained evidence are different checks |
| Recorded hash | Recalculate canonical evidence | Matching or corrupted state | Hash checks only the recorded bytes |
| Trace link | Resolve its governed target | Valid or dangling state | Candidate links remain outside governed evidence |
| Searchable evidence | Check the deposited index | Indexed or unindexed state | Search is not arbitrary full-text search |
How it works
- Open Enterprise evidence workspace.
- Select the deposited baseline.
- Review Coverage blockers.
- Select Run verification when persisted verification inputs are available.
- Filter results by availability or conformance state.
- Open the affected evidence and resolve the specific failure.
Example
A requirement still exists in retained evidence, but its live source page moved. The workspace can preserve the frozen revision while reporting the source movement separately. If a linked test target is absent, that relationship is dangling instead. These states require different actions and remain distinct in the evidence record.
What this does not mean
A visible failure state does not repair the source or approve a replacement. It preserves the difference between integrity, availability, freshness, linkage, and indexing. Administrators still decide how to correct live content and when to create a later baseline.
Related questions
Next step
Resolve each evidence state according to its cause before using the package.
View on Atlassian Marketplace